From pkoppula at openjdk.org  Thu Aug  1 04:18:08 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 1 Aug 2024 04:18:08 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name
Message-ID: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>

8329251: Print custom truststore/ keystore name

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

Commit messages:
 - JDK-8329251

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

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

From rgiulietti at openjdk.org  Thu Aug  1 09:15:42 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 1 Aug 2024 09:15:42 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v49]
In-Reply-To: <Rt0tuIfF8gAAK47YPmtnpSqrf10oZ-w5wJFr8y-UFeg=.83a3d015-2869-4874-9fae-2da9646daaf4@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <Rt0tuIfF8gAAK47YPmtnpSqrf10oZ-w5wJFr8y-UFeg=.83a3d015-2869-4874-9fae-2da9646daaf4@github.com>
Message-ID: <xEGIPaSLqkhF6eJrudyo_hKnVbeluizZvs7y35WbdWU=.eda157f9-b89b-417d-9f77-2ad0dac8566d@github.com>

On Wed, 31 Jul 2024 18:52:12 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:
> 
>   Memory usage optimization

The last small changes...

src/java.base/share/classes/java/math/MutableBigInteger.java line 1960:

> 1958:             sqrt.value[0] = (int) s;
> 1959: 
> 1960:             // The first invocation is never a base case, so the remainder is needed

This comment is confusing and contradicts the comment right at the beginning of the method.
I think it can be removed.

src/java.base/share/classes/java/math/MutableBigInteger.java line 1991:

> 1989:         if (needRemainder) {
> 1990:             rem = u;
> 1991:             if (rem.subtract(qSqr) == -1) {

For robustness, prefer
Suggestion:

            if (rem.subtract(qSqr) < 0) {

src/java.base/share/classes/java/math/MutableBigInteger.java line 1994:

> 1992:                 MutableBigInteger twiceSqrt = new MutableBigInteger(sqrt);
> 1993:                 twiceSqrt.leftShift(1);
> 1994: 

Maybe add a comment that, because of the way `MBI.subtract` works`, the logic here is "reversed" w.r.t. the one in the paper.

src/java.base/share/classes/java/math/MutableBigInteger.java line 2001:

> 1999:         } else {
> 2000:             rem = null;
> 2001:             if (u.compare(qSqr) == -1)

Since you don't depend on the exact value returned by `compare` but only on its signum, it's more robust to write this as
Suggestion:

            if (u.compare(qSqr) < 0)

test/jdk/java/math/BigInteger/BigIntegerTest.java line 296:

> 294:     }
> 295: 
> 296:     private static void perfectSquaresLong() {

On L.2 please change the last copyright year from 2023 to 2024.

test/micro/org/openjdk/bench/java/math/BigIntegerSquareRoot.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: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2212128217
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1699792998
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1699786653
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1699778380
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1699787332
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1699771929
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1699764168

From duke at openjdk.org  Thu Aug  1 10:16:59 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 1 Aug 2024 10:16:59 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
Message-ID: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@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:

  Last small changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19710/files
  - new: https://git.openjdk.org/jdk/pull/19710/files/f85f2a55..4c1d9e57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=48-49

  Stats: 11 lines in 3 files changed: 3 ins; 1 del; 7 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 rgiulietti at openjdk.org  Thu Aug  1 10:24:43 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 1 Aug 2024 10:24:43 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
Message-ID: <S3H7I5AdeVn6hRvHhNU7YmZZMhIKLwlvQ6alZjmXXiI=.0c293cf3-4362-4c8c-9a0e-cd16f712e2cd@github.com>

On Thu, 1 Aug 2024 10:16:59 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:
> 
>   Last small changes

I have no further comments, but I'll wait for a couple of days more before approving, just in case you have some last minute small changes.

Thanks for your efforts.

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2262686547

From hgreule at openjdk.org  Thu Aug  1 13:08:32 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 1 Aug 2024 13:08:32 GMT
Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively
 throws wrong exception [v2]
In-Reply-To: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
References: <gD4D2MSMO5dqwOf-XWA1u-a50e59goP8F_6be-mermA=.d172f4cf-14ad-492b-bdcc-8cf39d77c8ef@github.com>
 <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
Message-ID: <bbUiEPdexSvX2CxYMXEtLGCsF2M7YJE3QJp2jH-aad4=.b0ff85e8-4943-4e57-aa34-3c87cafcacd3@github.com>

On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods.
>> 
>> The exception message is less exact, but I think that's acceptable.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

@JornVernee if you want you can also review <https://bugs.openjdk.org/browse/JDK-8337301>

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

PR Comment: https://git.openjdk.org/jdk/pull/20015#issuecomment-2262988654

From duke at openjdk.org  Thu Aug  1 13:08:33 2024
From: duke at openjdk.org (duke)
Date: Thu, 1 Aug 2024 13:08:33 GMT
Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively
 throws wrong exception [v2]
In-Reply-To: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
References: <gD4D2MSMO5dqwOf-XWA1u-a50e59goP8F_6be-mermA=.d172f4cf-14ad-492b-bdcc-8cf39d77c8ef@github.com>
 <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
Message-ID: <rsTsQvT-0m5EHQr6THsMOC4YVkUXDoGeHPIcMYdeyIs=.71ed02a3-7ee2-4b02-ae24-ad9e30293db3@github.com>

On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods.
>> 
>> The exception message is less exact, but I think that's acceptable.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

@SirYwell 
Your change (at version e329ceb206d198e35186843391f4a8a25732e64e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20015#issuecomment-2262992409

From vklang at openjdk.org  Thu Aug  1 14:11:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 1 Aug 2024 14:11:31 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity
In-Reply-To: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
Message-ID: <KkczwGcanGrb9bwmg5Gr2i7xeZ-AhB3gpf7ZuRaU7FA=.3baf60db-868a-4e69-8adb-3c230af3e84f@github.com>

On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result.

@AlanBateman Would you want to be Reviewer? :)

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

PR Comment: https://git.openjdk.org/jdk/pull/20388#issuecomment-2263178440

From jvernee at openjdk.org  Thu Aug  1 14:38:34 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Aug 2024 14:38:34 GMT
Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively
 throws wrong exception [v2]
In-Reply-To: <s3ecyFzSeSB-ZY_HYForZPoga3JUOjMRftb91Zt_Wzs=.a6708d5f-e74d-43ea-afbb-e4136a356ca3@github.com>
References: <gD4D2MSMO5dqwOf-XWA1u-a50e59goP8F_6be-mermA=.d172f4cf-14ad-492b-bdcc-8cf39d77c8ef@github.com>
 <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
 <s3ecyFzSeSB-ZY_HYForZPoga3JUOjMRftb91Zt_Wzs=.a6708d5f-e74d-43ea-afbb-e4136a356ca3@github.com>
Message-ID: <6iSYVWCzeYcklxLJeKLvaXaM-0Vis0f-LbUUy3mARvM=.23e3aa59-ec67-48aa-beaf-27689c94b52d@github.com>

On Fri, 5 Jul 2024 14:23:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address comments
>
> I think this needs a CSR, to document the change in behavior. (See e.g. https://bugs.openjdk.org/browse/JDK-8335554 which is a very similar case)

> @JornVernee if you want you can also review https://bugs.openjdk.org/browse/JDK-8337301

@liach already asked me to take a look. The note looks good. There's no way for me to mark it as reviewed it seems

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

PR Comment: https://git.openjdk.org/jdk/pull/20015#issuecomment-2263238945

From jvernee at openjdk.org  Thu Aug  1 14:39:38 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Aug 2024 14:39:38 GMT
Subject: Integrated: 8324260: java/foreign/TestStubAllocFailure.java run
 timeout with -Xcomp
In-Reply-To: <rJlIdn1WZb_6JqwGbjN3_OIdF8TlmHhUcQ_r9iIlleY=.39e7bb13-844a-44b9-bcc4-ff11181012ab@github.com>
References: <rJlIdn1WZb_6JqwGbjN3_OIdF8TlmHhUcQ_r9iIlleY=.39e7bb13-844a-44b9-bcc4-ff11181012ab@github.com>
Message-ID: <jzuSs8zap7EPZAbVYNwWJyXwcd94MPwytKQW7K9YnLs=.bdc22d3a-447d-4fa6-8439-581007b0d90c@github.com>

On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This test spawns 2 forked processes, which then try to trigger a code cache OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow, which increases dramatically with `-Xcomp`, since startup Java code has to be compiled 3 times, once for the main test process, and then 2 more times for forks.
> 
> There is seemingly no/very little benefit of running this test with `-Xcomp`, since the test targets hotspot, not Java code. That and the test is sensitive to code cache usage, which is changed by `-Xcomp`.
> 
> So, to avoid instabilities, this PR proposes to disable the test when running with  `-Xcomp`. Another option is to not forward the VM flags of the parent process to the forks, but, on the off chance that this is useful for testing some other flags, this PR chooses the approach of disabling the test when running with `-Xcomp` instead.

This pull request has now been integrated.

Changeset: 27af80ef
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27af80ef9e676aaf9016279ff0c7990e2cdfe9ed
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8324260: java/foreign/TestStubAllocFailure.java run timeout with -Xcomp

Reviewed-by: alanb, jpai, shade

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

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

From liach at openjdk.org  Thu Aug  1 14:44:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 14:44:38 GMT
Subject: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively
 throws wrong exception [v2]
In-Reply-To: <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
References: <gD4D2MSMO5dqwOf-XWA1u-a50e59goP8F_6be-mermA=.d172f4cf-14ad-492b-bdcc-8cf39d77c8ef@github.com>
 <1yQze0X7kl1oxFtlWu0rtJwHF2WtnZYJ7t6OteIJAnQ=.85eae267-7848-4978-aa11-9f2720e67e00@github.com>
Message-ID: <ITr5drCopO9ppqUjldbmq22iGF2wwAjdVtg_MFtEO-g=.1e25afd0-9bfd-4494-908f-29131a935017@github.com>

On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods.
>> 
>> The exception message is less exact, but I think that's acceptable.
>
> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address comments

Thanks for this fix and the discussions. We should be good to go.

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

PR Comment: https://git.openjdk.org/jdk/pull/20015#issuecomment-2263247935

From hgreule at openjdk.org  Thu Aug  1 14:44:39 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Thu, 1 Aug 2024 14:44:39 GMT
Subject: Integrated: 8335638: Calling VarHandle.{access-mode} methods
 reflectively throws wrong exception
In-Reply-To: <gD4D2MSMO5dqwOf-XWA1u-a50e59goP8F_6be-mermA=.d172f4cf-14ad-492b-bdcc-8cf39d77c8ef@github.com>
References: <gD4D2MSMO5dqwOf-XWA1u-a50e59goP8F_6be-mermA=.d172f4cf-14ad-492b-bdcc-8cf39d77c8ef@github.com>
Message-ID: <ubJsuHbueQJrUq9HoOCDiEJC0onFM20u66D3rkcD10Y=.d2885dbc-d2ce-47d0-943b-4645457dc9b5@github.com>

On Wed, 3 Jul 2024 19:43:05 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods.
> 
> The exception message is less exact, but I think that's acceptable.

This pull request has now been integrated.

Changeset: 9fe6e231
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fe6e2316aef8fd125a7905cff2a2d9ae5d26109
Stats:     77 lines in 2 files changed: 72 ins; 0 del; 5 mod

8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception

Reviewed-by: liach

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

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

From kbarrett at openjdk.org  Thu Aug  1 15:05:33 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 1 Aug 2024 15:05:33 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK
In-Reply-To: <fyuVcNsa0PXqyqADc_a6y9jFjOvp_NeWoQrwxhpBt3E=.f14239b6-c555-4df3-abf7-cef497f8c9f9@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <fyuVcNsa0PXqyqADc_a6y9jFjOvp_NeWoQrwxhpBt3E=.f14239b6-c555-4df3-abf7-cef497f8c9f9@github.com>
Message-ID: <pt2Jrac4pz5CjhLdez2d57n41jC8mM7YFD94y5qnKhw=.05a3b204-4a73-42fd-84a3-3e7e8e284a2f@github.com>

On Sat, 13 Jul 2024 05:34:00 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> I would add a FORBID_C_FUNCTION for _snprintf for Windows, but unfortunately that would be completely useless since there's no way to restrict methods on Visual Studio

@TheShermanTanker - this seems to have been forgotten?

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2263298973

From jwaters at openjdk.org  Thu Aug  1 15:11:31 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Aug 2024 15:11:31 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v3]
In-Reply-To: <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
Message-ID: <PMmGBoF2fgKNGEpY5DpIeg9nGPXIlGpsnV_dVq7rs4c=.5770215c-c660-4904-9696-133d327ebccc@github.com>

On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Standard Integer type rewrite

Yeah, I do unfortunately need reviewers for the sections that haven't been approved yet. Taking this reminder as an opportunity to bump this Pull Request :)

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2263315060

From duke at openjdk.org  Thu Aug  1 16:13:32 2024
From: duke at openjdk.org (fitzsim)
Date: Thu, 1 Aug 2024 16:13:32 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
Message-ID: <LoWrj0MB67ZO0NlH_vJzzoq2vxN4EFtOiMm-xMvdMr0=.c1f3410e-22b4-4fc1-ab9a-b792fd2edc36@github.com>

On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim <duke at openjdk.org> wrote:

>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions

I saw a [`serviceability/jvmti/stress/StackTrace/Suspended/GetStackTraceSuspendedStressTest`](https://github.com/fitzsim/jdk/actions/runs/10188172450/attempts/1#summary-28185087430) failure but upon my re-running the job the failure did not happen again.  It seems unrelated to the patch set in this pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2263443381

From szaldana at openjdk.org  Thu Aug  1 17:20:00 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 1 Aug 2024 17:20:00 GMT
Subject: RFR: 8337667: sun/tools/jcmd/TestJcmdPIDSubstitution.java is failing
 on mac and windows
Message-ID: <Mcg9bHDK5y7FBg3dFczECbIJ6oeUZ_CgsRbDQIxCTms=.36fed73b-3701-48d2-82d8-5d3e477bbd6f@github.com>

Hi all, 

This PR addresses [8337667](https://bugs.openjdk.org/browse/JDK-8337667) . 

The `Compiler.perfmap` test case is failing on mac and windows as it is only enabled in linux. I am removing this test case and noting that this use case is already tested in [test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/dcmd/compiler/PerfMapTest.java#L88) which is linux specific.

Thanks, 
Sonia

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

Commit messages:
 - 8337667: sun/tools/jcmd/TestJcmdPIDSubstitution.java is failing on mac and windows

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

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

From naoto at openjdk.org  Thu Aug  1 17:26:50 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Aug 2024 17:26:50 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
Message-ID: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>

Fixing the Java launcher's command line argument parsing issue on Windows. The Java launcher on Windows has been using `GetCommandLineA()` to obtain arguments, which by default does "best-fit" mapping when the arguments are converted to ANSI code page encoding. By disabling this "best-fit" mapping, the launcher's parsing works as expected. A corresponding CSR has been drafted for the behavioral change.

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

Commit messages:
 - initial commit

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

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

From duke at openjdk.org  Thu Aug  1 18:17:38 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 1 Aug 2024 18:17:38 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <S3H7I5AdeVn6hRvHhNU7YmZZMhIKLwlvQ6alZjmXXiI=.0c293cf3-4362-4c8c-9a0e-cd16f712e2cd@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
 <S3H7I5AdeVn6hRvHhNU7YmZZMhIKLwlvQ6alZjmXXiI=.0c293cf3-4362-4c8c-9a0e-cd16f712e2cd@github.com>
Message-ID: <jb61kHx8heAhXW7-C96WdnyMzlu3jWU4rzQ6oZna-hs=.d208ef93-9219-49a5-85ee-e2435611cc18@github.com>

On Thu, 1 Aug 2024 10:22:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Last small changes
>
> I have no further comments, but I'll wait for a couple of days more before approving, just in case you have some last minute small changes.
> 
> Thanks for your efforts.

@rgiulietti If desired, we could further optimize the code by making it an iterative algorithm, thus avoiding the stack overhead due to recursive invocations.

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2263675965

From rgiulietti at openjdk.org  Thu Aug  1 19:13:38 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 1 Aug 2024 19:13:38 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
Message-ID: <OAxIZNfnT-5ADHiroLhV3qebxDlbZhmsLjs4U5Q9XCw=.53fb0e02-de0f-492e-b748-30f7ae384f94@github.com>

On Thu, 1 Aug 2024 10:16:59 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:
> 
>   Last small changes

I guess the overhead is negligible when compared to the arithmetic operation (shifts, divisions, etc.).
Also, the maximal stack depth for the recursion itself is quite limited and under control.
If at all, I would rather postpone that effort to a followup PR, and only if there are noticeable advantages without compromising readability.

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2263781654

From coffeys at openjdk.org  Thu Aug  1 19:31:34 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 1 Aug 2024 19:31:34 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <s128gFXVmj86c3JspVsFQ51GplnU3Ulxgw2G3rYnat4=.7964c6ee-d528-4032-975d-5fcf32124ecb@github.com>

On Thu, 1 Aug 2024 04:11:24 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

looks good - some minor issues highlighted

src/java.base/share/classes/jdk/internal/access/JavaIOFileInputStreamAccess.java line 30:

> 28: import java.io.IOException;
> 29: 
> 30: import jdk.internal.ref.PhantomCleanable;

these imports aren't required

src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java line 41:

> 39: import java.util.Set;
> 40: 
> 41: import jdk.internal.access.JavaIOFileInputStreamAccess;

shouldn't be required

src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java line 296:

> 294:                                     .getJavaIOFileInputStreamAccess()
> 295:                                     .getPath((FileInputStream) stream);
> 296:                     if (keystorePath != null) {

if `keystorePath` is null, no "Loaded" statement is printed. Let's cover that case also.

src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java line 297:

> 295:                                     .getPath((FileInputStream) stream);
> 296:                     if (keystorePath != null) {
> 297:                         debug.println("Loaded " + keystorePath.substring(

looking at debug output - it might be useful to surround the filename with quotes to emphasize that name is being printed.  e.g.

Loaded "keystore" keystore in PKCS12 format

test/jdk/java/security/KeyStore/LogKeyStorePathVerifier.java line 27:

> 25:  * @test
> 26:  * @bug 8329251
> 27:  * @library ../../

don't think this line is necessary

test/jdk/java/security/KeyStore/LogKeyStorePathVerifier.java line 31:

> 29:  * @summary Validates the customized keystore/ truststore paths
> 30:  * in the debug logs
> 31:  * @run main LogKeyStorePathVerifier

please run in ovm mode since test is reading system wide properties

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

PR Review: https://git.openjdk.org/jdk/pull/20414#pullrequestreview-2213714078
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1700708610
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1700711853
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1700714989
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1700714024
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1700715819
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1700716269

From duke at openjdk.org  Thu Aug  1 19:53:37 2024
From: duke at openjdk.org (fabioromano1)
Date: Thu, 1 Aug 2024 19:53:37 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <OAxIZNfnT-5ADHiroLhV3qebxDlbZhmsLjs4U5Q9XCw=.53fb0e02-de0f-492e-b748-30f7ae384f94@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
 <OAxIZNfnT-5ADHiroLhV3qebxDlbZhmsLjs4U5Q9XCw=.53fb0e02-de0f-492e-b748-30f7ae384f94@github.com>
Message-ID: <y2P6UOO-632c65G_Rayxq53-bqzthMvxuHkPdl1jA0E=.76ec777d-1937-4539-8a09-193eb73007c8@github.com>

On Thu, 1 Aug 2024 19:10:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Last small changes
>
> I guess the overhead is negligible when compared to the arithmetic operation (shifts, divisions, etc.).
> Also, the maximal stack depth for the recursion itself is quite limited and under control.
> If at all, I would rather postpone that effort to a followup PR, and only if there are noticeable advantages without compromising readability.

@rgiulietti In case, the code should look like this:

    /**
     * Assumes {@code intLen > 2 && intLen % 2 == 0
     * && Integer.numberOfLeadingZeros(value[offset]) <= 1}
     */
    private MutableBigInteger[] sqrtRemKaratsuba(boolean needRemainder) {
        MutableBigInteger sqrt, rem;
        // Base case
        {
            long x = ((value[offset] & LONG_MASK) << 32) | (value[offset + 1] & LONG_MASK);
            long s = unsignedLongSqrt(x);

            // Allocate sufficient space to hold the final square root
            sqrt = new MutableBigInteger(new int[intLen >> 1]);

            // Place the partial square root
            sqrt.intLen = 1;
            sqrt.value[0] = (int) s;

            rem = new MutableBigInteger(x - s * s);
        }

        // Iterative step
        int len;
        for (len = 4; len < intLen; len <<= 1) {
            final int blockLen = len >> 2;
            MutableBigInteger dividend = rem;
            dividend.shiftAddDisjoint(getBlockForSqrt(1, len, blockLen), blockLen);

            // Compute dividend / (2*sqrt)
            MutableBigInteger q = new MutableBigInteger();
            MutableBigInteger u = dividend.divide(sqrt, q);
            if (q.isOdd())
                u.add(sqrt);
            q.rightShift(1);

            sqrt.shiftAdd(q, blockLen);
            // Corresponds to ub + a_0 in the paper
            u.shiftAddDisjoint(getBlockForSqrt(0, len, blockLen), blockLen);
            BigInteger qBig = q.toBigInteger(); // Cast to BigInteger to use fast multiplication
            MutableBigInteger qSqr = new MutableBigInteger(qBig.multiply(qBig).mag);

            rem = u;
            if (rem.subtract(qSqr) < 0) {
                MutableBigInteger twiceSqrt = new MutableBigInteger(sqrt);
                twiceSqrt.leftShift(1);

                // Since subtract() performs an absolute difference, to get the correct algebraic sum
                // we must first add the sum of absolute values of addends concordant with the sign of rem
                // and then subtract the sum of absolute values of addends that are discordant
                rem.add(ONE);
                rem.subtract(twiceSqrt);
                sqrt.subtract(ONE);
            }
        }

        // Final step
        final int blockLen = len >> 2;
        MutableBigInteger dividend = rem;
        dividend.shiftAddDisjoint(getBlockForSqrt(1, len, blockLen), blockLen);

       MutableBigInteger q = new MutableBigInteger();
        MutableBigInteger u = dividend.divide(sqrt, q);
        if (q.isOdd())
            u.add(sqrt);
        q.rightShift(1);

        sqrt.shiftAdd(q, blockLen);
        u.shiftAddDisjoint(getBlockForSqrt(0, len, blockLen), blockLen);
        BigInteger qBig = q.toBigInteger();
        MutableBigInteger qSqr = new MutableBigInteger(qBig.multiply(qBig).mag);

        if (needRemainder) {
            rem = u;
            if (rem.subtract(qSqr) < 0) {
                MutableBigInteger twiceSqrt = new MutableBigInteger(sqrt);
                twiceSqrt.leftShift(1);

                rem.add(ONE);
                rem.subtract(twiceSqrt);
                sqrt.subtract(ONE);
            }
        } else {
            rem = null;
            if (u.compare(qSqr) < 0)
                sqrt.subtract(ONE);
        }

        return new MutableBigInteger[] { sqrt, rem };
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2263853409

From liach at openjdk.org  Thu Aug  1 20:02:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 20:02:54 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v7]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <bNp0RZntwuEDl_QcDv7V9oG5Ctr_WGz-zyPBRXxC6I0=.5ae87cc3-4cdb-42a8-839a-26618f67080e@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

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

 - Improve docs for repeating, default, and value name
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - More refinements from alex
 - Artifact -> construct
 - More about Annotation, add equals note
 - Further refine wording
 - Refine the spec of TypeAnnotation per Alex feedback
 - SealedGraph now redundant
 - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/cf16e7ee..d45c35fc

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

  Stats: 13943 lines in 436 files changed: 7864 ins; 4437 del; 1642 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Thu Aug  1 20:02:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 20:02:54 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v6]
In-Reply-To: <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <9qLO_N3ib22nV9uyQnSYxOxZIyC7hRZfZ-pMuI5boRs=.6239f79c-0e2e-4e9c-acd4-fa3f05faef80@github.com>
Message-ID: <mD-oVdBhV_ww8O9s1HijouilpGyCPPP0YiQkX8pvKd0=.c9ca2b13-1b04-455c-800f-4a570229281f@github.com>

On Wed, 24 Jul 2024 13:00:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note

I have added a few more paragraphs in response to the request for comments on default values and repeatable annotations. Below are the excerpts, for `Annotation` and `AnnotationElement::name`.


 * In an annotation in Java source code, elements in the annotation interface
 * with default values may not be compiled into element-value pairs unless an
 * explicit value is provided. ({@jls 9.6.2}) The default value is derived from
 * the {@link AnnotationDefaultAttribute AnnotationDefault} attribute on the
 * method representing the annotation interface element in the class file
 * representing the annotation interface.
 * <p id="repeatable">
 * Multiple annotations of the same interface <i>A</i> in Java source code
 * ({@jls 9.7.5}) are represented by the {@linkplain AnnotationValue.OfAnnotation
 * annotation-valued} array elements of the {@linkplain AnnotationValue.OfArray
 * array-valued} element named {@code value} of a container annotation of the
 * containing annotation interface of <i>A</i>. ({@jls 9.6.3})


     * <p>
     * A single-element annotation ({@jls 9.7.3}) in Java source code is
     * compiled to an {@link Annotation} with exactly one {@linkplain
     * Annotation#elements key-value pair} where the element has the name
     * {@code value}.
     * <p>
     * Multiple annotations of the same interface <i>A</i> in Java source code
     * is compiled to an implicitly declared container annotation ({@jls 9.7.5})
     * with exactly one {@linkplain Annotation#elements key-value pair} where
     * the element has the name {@code value} and the type of the element is the
     * {@linkplain AnnotationValue.OfArray array} whose component type is the
     * {@linkplain AnnotationValue.OfAnnotation annotation interface <i>A</i>}.

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

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2263874434

From rgiulietti at openjdk.org  Thu Aug  1 21:41:38 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 1 Aug 2024 21:41:38 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
Message-ID: <V2zc1GH0JKMwUKD2ONk17Q4YMe3LybcQzUbb36xAEz4=.5157d937-0205-420c-a244-0b55b3572f97@github.com>

On Thu, 1 Aug 2024 10:16:59 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:
> 
>   Last small changes

Mmh, benchmarks show a slight slowdown with the iterative variant (except for the XS case). I tried several times, this one is the most favorable run:

Benchmark                        Mode  Cnt      Score     Error  Units
BigIntegerSquareRoot.testSqrtL   avgt   15   2862.103 ?  14.482  ns/op
BigIntegerSquareRoot.testSqrtM   avgt   15    767.569 ?  22.197  ns/op
BigIntegerSquareRoot.testSqrtS   avgt   15    249.484 ?  48.970  ns/op
BigIntegerSquareRoot.testSqrtXL  avgt   15  22324.068 ? 147.290  ns/op
BigIntegerSquareRoot.testSqrtXS  avgt   15      4.815 ?   0.108  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2264056596

From prr at openjdk.org  Thu Aug  1 22:34:34 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Aug 2024 22:34:34 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v3]
In-Reply-To: <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
Message-ID: <u5yaMDAuEnx8yZY-Aa176jOYwhqA0a8Am2_WYEf6sXY=.6ed878bf-3864-4977-a5c3-213622ddb371@github.com>

On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Standard Integer type rewrite

AWT + A11Y

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2214138343

From liach at openjdk.org  Thu Aug  1 23:07:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Aug 2024 23:07:35 GMT
Subject: Withdrawn: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
In-Reply-To: <OX701aCsYNKyNvohWUHxo61QJCiZU_pljtJ8QDeB-Zo=.2a3ede65-c55e-4670-8bcb-520b22d82562@github.com>
References: <OX701aCsYNKyNvohWUHxo61QJCiZU_pljtJ8QDeB-Zo=.2a3ede65-c55e-4670-8bcb-520b22d82562@github.com>
Message-ID: <NJaUJobrbZcDLdF8wkdzdZ4qebngNLhhTHBJmpNNxTU=.7bb11eda-e99b-4a2e-bddd-38e7d9106d58@github.com>

On Sun, 14 Jul 2024 22:30:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove `AnnotationConstantValueEntry` and `AnnotationValue.OfConstant`.
> 
> This is a relic of the old model from https://github.com/openjdk/jdk-sandbox/commit/bb7e29474ecfcfbd1eb01d237593eb80d062944f. In addition, this is bug-prone: the byte, short, char, and boolean constants use the int entry, and getting the `ConstantDesc` for them will return an `Integer`, which cannot be inversed back into the respective annotation values via `AnnotationValue.of(Object)` factory.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Aug  1 23:43:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 1 Aug 2024 23:43:33 GMT
Subject: RFR: 8336856: Optimize String Concat [v22]
In-Reply-To: <wMwsPZOJSJu_ZCGuihZx4UnqIj6Z1GecNJQkQYRAu34=.059c06fa-7a71-410a-9021-0226dcc2585c@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <wMwsPZOJSJu_ZCGuihZx4UnqIj6Z1GecNJQkQYRAu34=.059c06fa-7a71-410a-9021-0226dcc2585c@github.com>
Message-ID: <xa79xpwPBIZyGvo-5zmHdlNUHgUUgL07va1noWJCmp4=.1f5bed2b-9a20-4d35-97f2-06358969469b@github.com>

On Wed, 31 Jul 2024 22:27:53 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
>> 
>> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ClassFile ACC Flags

Below are the performance numbers running on a MacBook M1 Pro. current2 is implemented completely with the new bytecode using `-Djava.lang.invoke.StringConcat.highArityThreshold=0`.


-# baseline 5ff7c57f9ff5428ef3d2aedd7e860bb1e8ff29ea
-Benchmark                                            (intValue)  Mode  Cnt    Score    Error  Units
-StringConcat.concat123String                               4711  avgt   15  990.214 ?  1.890  ns/op
-StringConcat.concat13String                                4711  avgt   15   45.810 ?  0.163  ns/op
-StringConcat.concat13StringConst                           4711  avgt   15   75.283 ?  4.831  ns/op
-StringConcat.concat23String                                4711  avgt   15   90.812 ?  0.317  ns/op
-StringConcat.concat23StringConst                           4711  avgt   15  101.114 ?  0.201  ns/op
-StringConcat.concat30Mix                                   4711  avgt   15  262.114 ? 20.685  ns/op
-StringConcat.concat3String                                 4711  avgt   15   12.607 ?  0.222  ns/op
-StringConcat.concat4String                                 4711  avgt   15   13.935 ?  0.181  ns/op
-StringConcat.concat6String                                 4711  avgt   15   19.831 ?  0.474  ns/op
-StringConcat.concatConst2String                            4711  avgt   15    9.491 ?  0.134  ns/op
-StringConcat.concatConst4String                            4711  avgt   15   14.786 ?  0.087  ns/op
-StringConcat.concatConst6Object                            4711  avgt   15   51.650 ?  0.314  ns/op
-StringConcat.concatConst6String                            4711  avgt   15   19.553 ?  0.054  ns/op
-StringConcat.concatConstBool                               4711  avgt   15    3.439 ?  0.020  ns/op
-StringConcat.concatConstBoolByte                           4711  avgt   15    6.440 ?  0.024  ns/op
-StringConcat.concatConstBoolString                         4711  avgt   15    7.054 ?  0.059  ns/op
-StringConcat.concatConstBoolean                            4711  avgt   15    3.965 ?  0.009  ns/op
-StringConcat.concatConstBooleanString                      4711  avgt   15    7.298 ?  0.021  ns/op
-StringConcat.concatConstFloat                              4711  avgt   15   58.590 ?  2.390  ns/op
-StringConcat.concatConstFloatString                        4711  avgt   15   59.409 ?  1.320  ns/op
-StringConcat.concatConstInt                                4711  avgt   15    6.074 ?  0.006  ns/op
-StringConcat.concatConstIntConstInt                        4711  avgt   15    9.726 ?  0.126  ns/op
-StringConcat.concatConstIntString                          4711  avgt   15   15.178 ?  0.642  ns/op
-StringConcat.concatConstInteger                            4711  avgt   15    4.002 ?  0.015  ns/op
-StringConcat.concatConstIntegerString                      4711  avgt   15    7.040 ?  0.207  ns/op
-StringConcat.concatConstString                             4711  avgt   15    4.983 ?  0.019  ns/op
-StringConcat.concatConstStringConstInt                     4711  avgt   15   11.906 ?  1.898  ns/op
-StringConcat.concatEmptyConstInt                           4711  avgt   15    5.618 ?  0.023  ns/op
-StringConcat.concatEmptyConstString                        4711  avgt   15    2.058 ?  0.037  ns/op
-StringConcat.concatEmptyLeft                               4711  avgt   15    2.216 ?  0.012  ns/op
-StringConcat.concatEmptyRight                              4711  avgt   15    2.373 ?  0.011  ns/op
-StringConcat.concatMethodConstString                       4711  avgt   15    4.973 ?  0.008  ns/op
-StringConcat.concatMix4String                              4711  avgt   15   84.747 ?  6.062  ns/op
-StringConcat.concatStringBoolString                        4711  avgt   15   18.836 ?  4.729  ns/op
-StringConcat.concatStringBooleanString                     4711  avgt   15    9.878 ?  0.087  ns/op
-StringConcat.concatStringIntString                         4711  avgt   15   18.083 ?  0.492  ns/op
-StringConcat.concatStringIntegerString                     4711  avgt   15    9.099 ?  0.126  ns/op
-StringConcatStartup.MixedLarge.run                          N/A    ss   10  315.546 ? 14.083  ms/op
-StringConcatStartup.MixedSmall.run                          N/A    ss   20   24.704 ?  0.621  ms/op
-StringConcatStartup.StringLarge.run                         N/A    ss   10   87.007 ?  5.414  ms/op
-StringConcatStartup.StringSingle.constBool                 4711    ss   40    2.102 ?  0.068  ms/op
-StringConcatStartup.StringSingle.constBoolString           4711    ss   40    0.261 ?  0.010  ms/op
-StringConcatStartup.StringSingle.constBoolean              4711    ss   40    0.147 ?  0.010  ms/op
-StringConcatStartup.StringSingle.constBooleanString        4711    ss   40    3.506 ?  0.090  ms/op
-StringConcatStartup.StringSingle.constFloat                4711    ss   40    2.628 ?  0.074  ms/op
-StringConcatStartup.StringSingle.constFloatString          4711    ss   40    4.473 ?  0.094  ms/op
-StringConcatStartup.StringSingle.constInt                  4711    ss   40    2.022 ?  0.070  ms/op
-StringConcatStartup.StringSingle.constIntString            4711    ss   40    0.150 ?  0.005  ms/op
-StringConcatStartup.StringSingle.constInteger              4711    ss   40    0.144 ?  0.008  ms/op
-StringConcatStartup.StringSingle.constIntegerString        4711    ss   40    3.541 ?  0.117  ms/op
-StringConcatStartup.StringSingle.constString               4711    ss   40    0.138 ?  0.009  ms/op
-StringConcatStartup.StringThree.stringIntString            4711    ss   40    6.166 ?  0.149  ms/op
-StringConcatStartup.StringThree.stringIntegerString        4711    ss   40    5.123 ?  0.127  ms/op

+# current d573c297219115976ad03f70fbd7777aedc3d4b8
+Benchmark                                            (intValue)  Mode  Cnt    Score    Error  Units
+StringConcat.concat123String                               4711  avgt   15  980.749 ? 10.562  ns/op
+StringConcat.concat13String                                4711  avgt   15   46.520 ?  0.509  ns/op
+StringConcat.concat13StringConst                           4711  avgt   15   71.920 ?  0.335  ns/op
+StringConcat.concat23String                                4711  avgt   15   93.629 ?  0.249  ns/op
+StringConcat.concat23StringConst                           4711  avgt   15  110.605 ?  0.171  ns/op
+StringConcat.concat30Mix                                   4711  avgt   15  376.001 ? 36.738  ns/op
+StringConcat.concat3String                                 4711  avgt   15   12.492 ?  0.228  ns/op
+StringConcat.concat4String                                 4711  avgt   15   13.968 ?  0.134  ns/op
+StringConcat.concat6String                                 4711  avgt   15   19.758 ?  0.477  ns/op
+StringConcat.concatConst2String                            4711  avgt   15    9.479 ?  0.121  ns/op
+StringConcat.concatConst4String                            4711  avgt   15   14.800 ?  0.046  ns/op
+StringConcat.concatConst6Object                            4711  avgt   15   51.606 ?  0.389  ns/op
+StringConcat.concatConst6String                            4711  avgt   15   19.513 ?  0.057  ns/op
+StringConcat.concatConstBool                               4711  avgt   15    3.465 ?  0.043  ns/op
+StringConcat.concatConstBoolByte                           4711  avgt   15    6.431 ?  0.025  ns/op
+StringConcat.concatConstBoolString                         4711  avgt   15    7.030 ?  0.022  ns/op
+StringConcat.concatConstBoolean                            4711  avgt   15    3.965 ?  0.016  ns/op
+StringConcat.concatConstBooleanString                      4711  avgt   15    7.308 ?  0.019  ns/op
+StringConcat.concatConstFloat                              4711  avgt   15   58.247 ?  1.906  ns/op
+StringConcat.concatConstFloatString                        4711  avgt   15   60.221 ?  1.932  ns/op
+StringConcat.concatConstInt                                4711  avgt   15    6.080 ?  0.012  ns/op
+StringConcat.concatConstIntConstInt                        4711  avgt   15    9.800 ?  0.131  ns/op
+StringConcat.concatConstIntString                          4711  avgt   15   14.696 ?  0.146  ns/op
+StringConcat.concatConstInteger                            4711  avgt   15    4.006 ?  0.038  ns/op
+StringConcat.concatConstIntegerString                      4711  avgt   15    6.922 ?  0.020  ns/op
+StringConcat.concatConstString                             4711  avgt   15    4.992 ?  0.050  ns/op
+StringConcat.concatConstStringConstInt                     4711  avgt   15   11.693 ?  1.738  ns/op
+StringConcat.concatEmptyConstInt                           4711  avgt   15    5.628 ?  0.029  ns/op
+StringConcat.concatEmptyConstString                        4711  avgt   15    2.065 ?  0.024  ns/op
+StringConcat.concatEmptyLeft                               4711  avgt   15    2.231 ?  0.017  ns/op
+StringConcat.concatEmptyRight                              4711  avgt   15    2.398 ?  0.014  ns/op
+StringConcat.concatMethodConstString                       4711  avgt   15    5.013 ?  0.012  ns/op
+StringConcat.concatMix4String                              4711  avgt   15   80.071 ?  1.992  ns/op
+StringConcat.concatStringBoolString                        4711  avgt   15   19.235 ?  1.379  ns/op
+StringConcat.concatStringBooleanString                     4711  avgt   15    9.780 ?  0.099  ns/op
+StringConcat.concatStringIntString                         4711  avgt   15   18.258 ?  0.515  ns/op
+StringConcat.concatStringIntegerString                     4711  avgt   15    9.161 ?  0.191  ns/op
+StringConcatStartup.MixedLarge.run                          N/A    ss   10  310.811 ? 12.045  ms/op
+StringConcatStartup.MixedSmall.run                          N/A    ss   20   24.526 ?  0.702  ms/op
+StringConcatStartup.StringLarge.run                         N/A    ss   10   86.733 ?  3.614  ms/op
+StringConcatStartup.StringSingle.constBool                 4711    ss   40    2.139 ?  0.074  ms/op
+StringConcatStartup.StringSingle.constBoolString           4711    ss   40    0.267 ?  0.010  ms/op
+StringConcatStartup.StringSingle.constBoolean              4711    ss   40    0.144 ?  0.009  ms/op
+StringConcatStartup.StringSingle.constBooleanString        4711    ss   40    3.610 ?  0.082  ms/op
+StringConcatStartup.StringSingle.constFloat                4711    ss   40    2.683 ?  0.090  ms/op
+StringConcatStartup.StringSingle.constFloatString          4711    ss   40    4.491 ?  0.109  ms/op
+StringConcatStartup.StringSingle.constInt                  4711    ss   40    2.073 ?  0.075  ms/op
+StringConcatStartup.StringSingle.constIntString            4711    ss   40    0.158 ?  0.008  ms/op
+StringConcatStartup.StringSingle.constInteger              4711    ss   40    0.146 ?  0.009  ms/op
+StringConcatStartup.StringSingle.constIntegerString        4711    ss   40    3.640 ?  0.070  ms/op
+StringConcatStartup.StringSingle.constString               4711    ss   40    0.147 ?  0.010  ms/op
+StringConcatStartup.StringThree.stringIntString            4711    ss   40    6.189 ?  0.131  ms/op
+StringConcatStartup.StringThree.stringIntegerString        4711    ss   40    5.250 ?  0.129  ms/op

+# current2 d573c297219115976ad03f70fbd7777aedc3d4b8
+# MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0"
+Benchmark                                            (intValue)  Mode  Cnt    Score    Error  Units
+StringConcat.concat123String                               4711  avgt   15  973.317 ?  0.981  ns/op
+StringConcat.concat13String                                4711  avgt   15   44.808 ?  0.051  ns/op
+StringConcat.concat13StringConst                           4711  avgt   15   67.801 ?  0.939  ns/op
+StringConcat.concat23String                                4711  avgt   15   93.563 ?  0.285  ns/op
+StringConcat.concat23StringConst                           4711  avgt   15  110.992 ?  0.368  ns/op
+StringConcat.concat30Mix                                   4711  avgt   15  369.601 ? 29.285  ns/op
+StringConcat.concat3String                                 4711  avgt   15   11.885 ?  0.114  ns/op
+StringConcat.concat4String                                 4711  avgt   15   13.974 ?  0.219  ns/op
+StringConcat.concat6String                                 4711  avgt   15   19.828 ?  0.510  ns/op
+StringConcat.concatConst2String                            4711  avgt   15    9.505 ?  0.111  ns/op
+StringConcat.concatConst4String                            4711  avgt   15   14.818 ?  0.100  ns/op
+StringConcat.concatConst6Object                            4711  avgt   15   82.329 ?  0.275  ns/op
+StringConcat.concatConst6String                            4711  avgt   15   22.217 ?  0.033  ns/op
+StringConcat.concatConstBool                               4711  avgt   15    3.431 ?  0.029  ns/op
+StringConcat.concatConstBoolByte                           4711  avgt   15    6.573 ?  0.021  ns/op
+StringConcat.concatConstBoolString                         4711  avgt   15    7.016 ?  0.018  ns/op
+StringConcat.concatConstBoolean                            4711  avgt   15    3.971 ?  0.017  ns/op
+StringConcat.concatConstBooleanString                      4711  avgt   15    7.336 ?  0.046  ns/op
+StringConcat.concatConstFloat                              4711  avgt   15   58.261 ?  1.530  ns/op
+StringConcat.concatConstFloatString                        4711  avgt   15   59.223 ?  0.967  ns/op
+StringConcat.concatConstInt                                4711  avgt   15    6.103 ?  0.016  ns/op
+StringConcat.concatConstIntConstInt                        4711  avgt   15    9.839 ?  0.148  ns/op
+StringConcat.concatConstIntString                          4711  avgt   15   15.349 ?  0.537  ns/op
+StringConcat.concatConstInteger                            4711  avgt   15    3.999 ?  0.020  ns/op
+StringConcat.concatConstIntegerString                      4711  avgt   15    6.926 ?  0.035  ns/op
+StringConcat.concatConstString                             4711  avgt   15    4.975 ?  0.013  ns/op
+StringConcat.concatConstStringConstInt                     4711  avgt   15   11.930 ?  1.951  ns/op
+StringConcat.concatEmptyConstInt                           4711  avgt   15    5.597 ?  0.024  ns/op
+StringConcat.concatEmptyConstString                        4711  avgt   15    2.081 ?  0.024  ns/op
+StringConcat.concatEmptyLeft                               4711  avgt   15    2.244 ?  0.025  ns/op
+StringConcat.concatEmptyRight                              4711  avgt   15    2.410 ?  0.052  ns/op
+StringConcat.concatMethodConstString                       4711  avgt   15    5.041 ?  0.010  ns/op
+StringConcat.concatMix4String                              4711  avgt   15   78.331 ?  0.604  ns/op
+StringConcat.concatStringBoolString                        4711  avgt   15   19.291 ?  1.504  ns/op
+StringConcat.concatStringBooleanString                     4711  avgt   15    9.847 ?  0.105  ns/op
+StringConcat.concatStringIntString                         4711  avgt   15   17.951 ?  0.388  ns/op
+StringConcat.concatStringIntegerString                     4711  avgt   15    9.237 ?  0.164  ns/op
+StringConcatStartup.MixedLarge.run                          N/A    ss   10  102.619 ?  4.217  ms/op
+StringConcatStartup.MixedSmall.run                          N/A    ss   20    4.819 ?  0.158  ms/op
+StringConcatStartup.StringLarge.run                         N/A    ss   10   42.792 ?  1.655  ms/op
+StringConcatStartup.StringSingle.constBool                 4711    ss   40    0.425 ?  0.009  ms/op
+StringConcatStartup.StringSingle.constBoolString           4711    ss   40    0.461 ?  0.012  ms/op
+StringConcatStartup.StringSingle.constBoolean              4711    ss   40    0.133 ?  0.004  ms/op
+StringConcatStartup.StringSingle.constBooleanString        4711    ss   40    0.456 ?  0.016  ms/op
+StringConcatStartup.StringSingle.constFloat                4711    ss   40    0.631 ?  0.017  ms/op
+StringConcatStartup.StringSingle.constFloatString          4711    ss   40    0.920 ?  0.025  ms/op
+StringConcatStartup.StringSingle.constInt                  4711    ss   40    0.427 ?  0.021  ms/op
+StringConcatStartup.StringSingle.constIntString            4711    ss   40    0.444 ?  0.015  ms/op
+StringConcatStartup.StringSingle.constInteger              4711    ss   40    0.135 ?  0.004  ms/op
+StringConcatStartup.StringSingle.constIntegerString        4711    ss   40    0.461 ?  0.014  ms/op
+StringConcatStartup.StringSingle.constString               4711    ss   40    0.133 ?  0.008  ms/op
+StringConcatStartup.StringThree.stringIntString            4711    ss   40    1.316 ?  0.041  ms/op
+StringConcatStartup.StringThree.stringIntegerString        4711    ss   40    0.394 ?  0.010  ms/op


|   | baseline  | current |  current2 | delta | delta2 |
| --- | --- | --- | --- | --- | --- |
| StringConcat.concat123String | 990.214 | 980.749 | 973.317 | 0.97% | 1.74% |
| StringConcat.concat13String | 45.810 | 46.520 | 44.808 | -1.53% | 2.24% |
| StringConcat.concat13StringConst | 75.283 | 71.920 | 67.801 | 4.68% | 11.04% |
| StringConcat.concat23String | 90.812 | 93.629 | 93.563 | -3.01% | -2.94% |
| StringConcat.concat23StringConst | 101.114 | 110.605 | 110.992 | -8.58% | -8.90% |
| StringConcat.concat30Mix | 262.114 | 376.001 | 369.601 | -30.29% | -29.08% |
| StringConcat.concat3String | 12.607 | 12.492 | 11.885 | 0.92% | 6.07% |
| StringConcat.concat4String | 13.935 | 13.968 | 13.974 | -0.24% | -0.28% |
| StringConcat.concat6String | 19.831 | 19.758 | 19.828 | 0.37% | 0.02% |
| StringConcat.concatConst2String | 9.491 | 9.479 | 9.505 | 0.13% | -0.15% |
| StringConcat.concatConst4String | 14.786 | 14.800 | 14.818 | -0.09% | -0.22% |
| StringConcat.concatConst6Object | 51.650 | 51.606 | 82.329 | 0.09% | -37.26% |
| StringConcat.concatConst6String | 19.553 | 19.513 | 22.217 | 0.20% | -11.99% |
| StringConcat.concatConstBool | 3.439 | 3.465 | 3.431 | -0.75% | 0.23% |
| StringConcat.concatConstBoolByte | 6.440 | 6.431 | 6.573 | 0.14% | -2.02% |
| StringConcat.concatConstBoolString | 7.054 | 7.030 | 7.016 | 0.34% | 0.54% |
| StringConcat.concatConstBoolean | 3.965 | 3.965 | 3.971 | 0.00% | -0.15% |
| StringConcat.concatConstBooleanString | 7.298 | 7.308 | 7.336 | -0.14% | -0.52% |
| StringConcat.concatConstFloat | 58.590 | 58.247 | 58.261 | 0.59% | 0.56% |
| StringConcat.concatConstFloatString | 59.409 | 60.221 | 59.223 | -1.35% | 0.31% |
| StringConcat.concatConstInt | 6.074 | 6.080 | 6.103 | -0.10% | -0.48% |
| StringConcat.concatConstIntConstInt | 9.726 | 9.800 | 9.839 | -0.76% | -1.15% |
| StringConcat.concatConstIntString | 15.178 | 14.696 | 15.349 | 3.28% | -1.11% |
| StringConcat.concatConstInteger | 4.002 | 4.006 | 3.999 | -0.10% | 0.08% |
| StringConcat.concatConstIntegerString | 7.040 | 6.922 | 6.926 | 1.70% | 1.65% |
| StringConcat.concatConstString | 4.983 | 4.992 | 4.975 | -0.18% | 0.16% |
| StringConcat.concatConstStringConstInt | 11.906 | 11.693 | 11.930 | 1.82% | -0.20% |
| StringConcat.concatEmptyConstInt | 5.618 | 5.628 | 5.597 | -0.18% | 0.38% |
| StringConcat.concatEmptyConstString | 2.058 | 2.065 | 2.081 | -0.34% | -1.11% |
| StringConcat.concatEmptyLeft | 2.216 | 2.231 | 2.244 | -0.67% | -1.25% |
| StringConcat.concatEmptyRight | 2.373 | 2.398 | 2.410 | -1.04% | -1.54% |
| StringConcat.concatMethodConstString | 4.973 | 5.013 | 5.041 | -0.80% | -1.35% |
| StringConcat.concatMix4String | 84.747 | 80.071 | 78.331 | 5.84% | 8.19% |
| StringConcat.concatStringBoolString | 18.836 | 19.235 | 19.291 | -2.07% | -2.36% |
| StringConcat.concatStringBooleanString | 9.878 | 9.780 | 9.847 | 1.00% | 0.31% |
| StringConcat.concatStringIntString | 18.083 | 18.258 | 17.951 | -0.96% | 0.74% |
| StringConcat.concatStringIntegerString | 9.099 | 9.161 | 9.237 | -0.68% | -1.49% |
| StringConcatStartup.MixedLarge.run | 315.546 | 310.811 | 102.619 | 1.52% | 207.49% |
| StringConcatStartup.MixedSmall.run | 24.704 | 24.526 | 4.819 | 0.73% | 412.64% |
| StringConcatStartup.StringLarge.run | 87.007 | 86.733 | 42.792 | 0.32% | 103.33% |
| StringConcatStartup.StringSingle.constBool | 2.102 | 2.139 | 0.425 | -1.73% | 394.59% |
| StringConcatStartup.StringSingle.constBoolString | 0.261 | 0.267 | 0.461 | -2.25% | -43.38% |
| StringConcatStartup.StringSingle.constBoolean | 0.147 | 0.144 | 0.133 | 2.08% | 10.53% |
| StringConcatStartup.StringSingle.constBooleanString | 3.506 | 3.610 | 0.456 | -2.88% | 668.86% |
| StringConcatStartup.StringSingle.constFloat | 2.628 | 2.683 | 0.631 | -2.05% | 316.48% |
| StringConcatStartup.StringSingle.constFloatString | 4.473 | 4.491 | 0.920 | -0.40% | 386.20% |
| StringConcatStartup.StringSingle.constInt | 2.022 | 2.073 | 0.427 | -2.46% | 373.54% |
| StringConcatStartup.StringSingle.constIntString | 0.150 | 0.158 | 0.444 | -5.06% | -66.22% |
| StringConcatStartup.StringSingle.constInteger | 0.144 | 0.146 | 0.135 | -1.37% | 6.67% |
| StringConcatStartup.StringSingle.constIntegerString | 3.541 | 3.640 | 0.461 | -2.72% | 668.11% |
| StringConcatStartup.StringSingle.constString | 0.138 | 0.147 | 0.133 | -6.12% | 3.76% |
| StringConcatStartup.StringThree.stringIntString | 6.166 | 6.189 | 1.316 | -0.37% | 368.54% |
| StringConcatStartup.StringThree.stringIntegerString | 5.123 | 5.250 | 0.394 | -2.42% | 1200.25% |

It can be seen that the following scenarios are performance regressions:

|   | baseline  | current |  current2 | delta | delta2 |
| --- | --- | --- | --- | --- | --- |
| StringConcat.concat23String | 90.812 | 93.629 | 93.563 | -3.01% | -2.94% |
| StringConcat.concat23StringConst | 101.114 | 110.605 | 110.992 | -8.58% | -8.90% |
| StringConcat.concat30Mix | 262.114 | 376.001 | 369.601 | -30.29% | -29.08% |
| StringConcat.concatConst6Object | 51.650 | 51.606 | 82.329 | 0.09% | -37.26% |
| StringConcat.concatConst6String | 19.553 | 19.513 | 22.217 | 0.20% | -11.99% |
| StringConcatStartup.StringSingle.constBoolString | 0.261 | 0.267 | 0.461 | -2.25% | -43.38% |
| StringConcatStartup.StringSingle.constIntString | 0.150 | 0.158 | 0.444 | -5.06% | -66.22% |

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264217921

From liach at openjdk.org  Fri Aug  2 00:04:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 00:04:48 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

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

 - remove compile, use element-value, break long sentences
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Improve docs for repeating, default, and value name
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - More refinements from alex
 - Artifact -> construct
 - More about Annotation, add equals note
 - Further refine wording
 - Refine the spec of TypeAnnotation per Alex feedback
 - ... and 2 more: https://git.openjdk.org/jdk/compare/cfd1bb21...3a91a3a5

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/d45c35fc..3a91a3a5

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

  Stats: 531 lines in 22 files changed: 322 ins; 11 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Fri Aug  2 00:04:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 00:04:50 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v7]
In-Reply-To: <bNp0RZntwuEDl_QcDv7V9oG5Ctr_WGz-zyPBRXxC6I0=.5ae87cc3-4cdb-42a8-839a-26618f67080e@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <bNp0RZntwuEDl_QcDv7V9oG5Ctr_WGz-zyPBRXxC6I0=.5ae87cc3-4cdb-42a8-839a-26618f67080e@github.com>
Message-ID: <EEisGWjdGGwDy7dO2kTBZf0dSPHsKS4HwaXde0T6gTQ=.0cdacc6e-0f53-43c0-9332-dd084d283f19@github.com>

On Thu, 1 Aug 2024 20:02:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> 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 10 additional commits since the last revision:
> 
>  - Improve docs for repeating, default, and value name
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note
>  - Further refine wording
>  - Refine the spec of TypeAnnotation per Alex feedback
>  - SealedGraph now redundant
>  - 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

I have implemented the suggestions (compiled to -> represented by, key-value -> element value) and tried to simplify the wording. Please review the current version:

 * <p>
 * In an annotation in Java source code, elements in the annotation interface
 * with default values may not be represented unless an explicit value is provided.
 * ({@jls 9.6.2}) The default value is derived from the {@link AnnotationDefaultAttribute
 * AnnotationDefault} attribute on the method representing the annotation
 * interface element, in the class file representing the annotation interface.
 * <p id="repeatable">
 * Multiple annotations of the same interface <i>A</i> in Java source code
 * ({@jls 9.7.5}) are represented by the {@linkplain AnnotationValue.OfAnnotation
 * annotation-valued} array elements of the {@linkplain AnnotationValue.OfArray
 * array-valued} element named {@code value} of a container annotation, whose
 * interface is the containing annotation interface of <i>A</i>. ({@jls 9.6.3})

// location in class files to source code construct/type section
 * If this annotation is of a {@linkplain ##repeatable repeatable} annotation
 * interface <i>A</i>, is an array element of an array-valued element named
 * {@code value} in a container annotation, and the interface of the container
 * annotation is the containing annotation interface <i>AC</i> of <i>A</i>,
 * this annotation represents a base annotation of type <i>A</i>, which applies
 * to the same source code construct or type as the container annotation of
 * type <i>AC</i>.

// On AnnotationElement::name
     * @apiNote
     * In Java source code, by convention, the name of the sole element in a
     * single-element annotation interface is {@code value}. ({@jls 9.6.1})
     * A single-element annotation ({@jls 9.7.3}) declares the element value
     * for the {@code value} element. The single element of a containing
     * annotation interface that holds {@linkplain Annotation##repeatable
     * multiple} base annotations is also named {@code value}. ({@jls 9.6.3})

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

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2264242499

From bpb at openjdk.org  Fri Aug  2 00:25:39 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Aug 2024 00:25:39 GMT
Subject: RFR: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix
Message-ID: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>

Add some verbiage indicating that an `IOException` will be thrown if a file with a name generated from the supplied prefix and suffix according to the described algorithm cannot be generated by the underlying system, whether that be due to the presence of one of more characters not supported by the underlying system or for some other reason.

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

Commit messages:
 - 6426678: (spec) File.createTempFile(prefix, suffix, dir) needs clarification for illegal symbols in suffix

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

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

From bpb at openjdk.org  Fri Aug  2 00:30:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Aug 2024 00:30:31 GMT
Subject: RFR: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix
In-Reply-To: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
References: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
Message-ID: <L6WKTwWo9iIQv7THUPW9oFYDYZ43yYpXaXNVR1p9LI8=.b30793d2-29ff-4c28-9917-e619aa3e31fb@github.com>

On Fri, 2 Aug 2024 00:21:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add some verbiage indicating that an `IOException` will be thrown if a file with a name generated from the supplied prefix and suffix according to the described algorithm cannot be generated by the underlying system, whether that be due to the presence of one of more characters not supported by the underlying system or for some other reason.

To be created when verbiage changes are quiescent.

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

PR Comment: https://git.openjdk.org/jdk/pull/20435#issuecomment-2264269407

From liach at openjdk.org  Fri Aug  2 00:43:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 00:43:46 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
Message-ID: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>

1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
2. Improved value specification to specify their tags.
3. Improved value factories to return their specific types instead of `OfConstant`
4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

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

Commit messages:
 - 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

Changes: https://git.openjdk.org/jdk/pull/20436/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335927
  Stats: 273 lines in 11 files changed: 106 ins; 34 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/20436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20436/head:pull/20436

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

From duke at openjdk.org  Fri Aug  2 00:59:06 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 00:59:06 GMT
Subject: RFR: 8336856: Optimize String Concat [v23]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>

> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
> 
> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866

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

  Fix performance regression caused by args.erase()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/d573c297..e2b30b3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=21-22

  Stats: 86 lines in 1 file changed: 46 ins; 36 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From redestad at openjdk.org  Fri Aug  2 01:06:38 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 2 Aug 2024 01:06:38 GMT
Subject: RFR: 8336856: Optimize String Concat [v23]
In-Reply-To: <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
Message-ID: <jnhFzAF452ftUROp6ClGHuuFbRcCixB35u3OdmUyjj8=.5cd42a78-1192-4290-ba41-6d2aceb025fb@github.com>

On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
>> 
>> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix performance regression caused by args.erase()

I think erasing arguments is needed for correctness - are you sure this was cause for observed regressions? e2b30b3  backed out a few other things, too.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264299852

From duke at openjdk.org  Fri Aug  2 01:10:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 01:10:36 GMT
Subject: RFR: 8336856: Optimize String Concat [v23]
In-Reply-To: <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
Message-ID: <_ZG7vOdv7oS_s_jT58TPKl2hIc9A7DqQRQ7wPJdhLHA=.d387899f-c3b6-47dc-8f0b-274f177df1da@github.com>

On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
>> 
>> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix performance regression caused by args.erase()

Erasing arguments does not require the use of local String variables. Not using local String variables will cause performance regression.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264302140

From duke at openjdk.org  Fri Aug  2 01:18:34 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 01:18:34 GMT
Subject: RFR: 8336856: Optimize String Concat [v23]
In-Reply-To: <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
Message-ID: <-8ghgrUCiSaOOhuJk6_kjk7RFO9Gon4jAay57n3rLK8=.220e8d6a-59dc-4bf0-ac76-0288cb323b16@github.com>

On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
>> 
>> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix performance regression caused by args.erase()

The following test will see the performance regression


git checkout d573c297219115976ad03f70fbd7777aedc3d4b8
make test TEST="micro:java.lang.StringConcat.concatConst6Object" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0"

git checkout e2b30b3f5f74ba8881e3674f3e0beef12883b138
make test TEST="micro:java.lang.StringConcat.concatConst6Object" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0"



# d573c29
Benchmark                        (intValue)  Mode  Cnt   Score   Error  Units
StringConcat.concatConst6Object        4711  avgt   15  74.717 ? 8.146  ns/op

# e2b30b3
Benchmark                        (intValue)  Mode  Cnt   Score   Error  Units
StringConcat.concatConst6Object        4711  avgt   15  51.573 ? 0.385  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264308978

From duke at openjdk.org  Fri Aug  2 01:35:43 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 01:35:43 GMT
Subject: RFR: 8336856: Optimize String Concat [v23]
In-Reply-To: <jnhFzAF452ftUROp6ClGHuuFbRcCixB35u3OdmUyjj8=.5cd42a78-1192-4290-ba41-6d2aceb025fb@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
 <jnhFzAF452ftUROp6ClGHuuFbRcCixB35u3OdmUyjj8=.5cd42a78-1192-4290-ba41-6d2aceb025fb@github.com>
Message-ID: <KiXl30HExTi3AE4Muw7yRute5FUpteiTI6UmL9dCwUI=.bc7c9e30-0d11-4bc5-9a78-07285c78186e@github.com>

On Fri, 2 Aug 2024 01:04:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix performance regression caused by args.erase()
>
> I think erasing arguments is needed for correctness - are you sure this was cause for observed regressions? e2b30b3  backed out a few other things, too.

@cl4es What is the reason for `erasing arguments is needed for correctness`? The current version can handle non-Object type parameters, is it because of complexity?

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264323333

From liach at openjdk.org  Fri Aug  2 04:29:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 04:29:33 GMT
Subject: RFR: 8336856: Optimize String Concat [v23]
In-Reply-To: <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
Message-ID: <g1hKmps1NesHfJ3POJKEW12a1IQzUiQ71QoTH9LtplM=.0661a4d1-c41f-47c8-96cc-c6e9b775641d@github.com>

On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
>> 
>> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix performance regression caused by args.erase()

Because we load the class in the bootstrap loader so it can access java.lang; means our class cannot see user classes as a result.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264521467

From duke at openjdk.org  Fri Aug  2 05:20:05 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 05:20:05 GMT
Subject: RFR: 8336856: Optimize String Concat [v24]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <Jr0w1sz9-XUxYa_AcTJ9hGPK1bjHJvFs-gDPE4uwdKs=.22263ebf-4bec-45cc-9b83-09cfc39c121b@github.com>

> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
> 
> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866

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

  erase argument types

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/e2b30b3f..7875fd3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=22-23

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

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

From duke at openjdk.org  Fri Aug  2 05:31:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 05:31:03 GMT
Subject: RFR: 8336856: Optimize String Concat [v25]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <uiX2CxKrmV2ioDmSlOmYCS0Oxen9gB1MvnhDrsRMvsM=.59ceda0b-84cf-4559-a530-96a2925de055@github.com>

> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
> 
> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866

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/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/7875fd3e..b7e1f524

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=23-24

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

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

From duke at openjdk.org  Fri Aug  2 06:33:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 Aug 2024 06:33:36 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <V2zc1GH0JKMwUKD2ONk17Q4YMe3LybcQzUbb36xAEz4=.5157d937-0205-420c-a244-0b55b3572f97@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
 <V2zc1GH0JKMwUKD2ONk17Q4YMe3LybcQzUbb36xAEz4=.5157d937-0205-420c-a244-0b55b3572f97@github.com>
Message-ID: <CdTKUOmxqrd7rsbf8CWR8Ozd07dsOJcHy2MSUZAl-co=.1d2fe99c-a320-4963-8167-ba92f988eda8@github.com>

On Thu, 1 Aug 2024 21:38:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Mmh, benchmarks show a slight slowdown with the iterative variant (except for the XS case). I tried several times, this one is the most favorable run:
> 
> ```
> Benchmark                        Mode  Cnt      Score     Error  Units
> BigIntegerSquareRoot.testSqrtL   avgt   15   2862.103 ?  14.482  ns/op
> BigIntegerSquareRoot.testSqrtM   avgt   15    767.569 ?  22.197  ns/op
> BigIntegerSquareRoot.testSqrtS   avgt   15    249.484 ?  48.970  ns/op
> BigIntegerSquareRoot.testSqrtXL  avgt   15  22324.068 ? 147.290  ns/op
> BigIntegerSquareRoot.testSqrtXS  avgt   15      4.815 ?   0.108  ns/op
> ```

This can happen too. It had already happened to me once when I was trying to implement an iterative version of MergeSort, and strangely it was slower. It is still useful to test for comparing the two versions.

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2264661114

From duke at openjdk.org  Fri Aug  2 06:41:40 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 2 Aug 2024 06:41:40 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <CdTKUOmxqrd7rsbf8CWR8Ozd07dsOJcHy2MSUZAl-co=.1d2fe99c-a320-4963-8167-ba92f988eda8@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
 <V2zc1GH0JKMwUKD2ONk17Q4YMe3LybcQzUbb36xAEz4=.5157d937-0205-420c-a244-0b55b3572f97@github.com>
 <CdTKUOmxqrd7rsbf8CWR8Ozd07dsOJcHy2MSUZAl-co=.1d2fe99c-a320-4963-8167-ba92f988eda8@github.com>
Message-ID: <KLmM7d4lCVaI8fSWehCOqTcP2e8wnxpXfD4wBRxKwPc=.6b9a1f68-e329-4852-b775-befa1deaf343@github.com>

On Fri, 2 Aug 2024 06:31:05 GMT, fabioromano1 <duke at openjdk.org> wrote:

> Mmh, benchmarks show a slight slowdown with the iterative variant (except for the XS case). I tried several times, this one is the most favorable run:
> 
> ```
> Benchmark                        Mode  Cnt      Score     Error  Units
> BigIntegerSquareRoot.testSqrtL   avgt   15   2862.103 ?  14.482  ns/op
> BigIntegerSquareRoot.testSqrtM   avgt   15    767.569 ?  22.197  ns/op
> BigIntegerSquareRoot.testSqrtS   avgt   15    249.484 ?  48.970  ns/op
> BigIntegerSquareRoot.testSqrtXL  avgt   15  22324.068 ? 147.290  ns/op
> BigIntegerSquareRoot.testSqrtXS  avgt   15      4.815 ?   0.108  ns/op
> ```

Probably it's due to the different splitting of the input array.

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2264670506

From pminborg at openjdk.org  Fri Aug  2 07:27:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 Aug 2024 07:27:07 GMT
Subject: RFR: 8337712: Wrong javadoc in java.util.Date#toString(): "61" and
 right parenthesis
Message-ID: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>

This trivial PR proposes to add a missing parenthesis in `java.util.Date::toString`.

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

Commit messages:
 - Update copyright year
 - Add missing parenthesis in Date::toString

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

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

From pminborg at openjdk.org  Fri Aug  2 07:27:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 Aug 2024 07:27:07 GMT
Subject: RFR: 8337712: Wrong javadoc in java.util.Date#toString(): "61" and
 right parenthesis
In-Reply-To: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
References: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
Message-ID: <kiQA69X4p3z3COKfkKVKwWHcvjZguQ47NtQ9skg_kQI=.7052165a-8469-46bc-b0d1-e88ffad0d031@github.com>

On Fri, 2 Aug 2024 07:20:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to add a missing parenthesis in `java.util.Date::toString`.

src/java.base/share/classes/java/util/Date.java line 1015:

> 1013:      *     {@code 59}), as two decimal digits.
> 1014:      * <li>{@code ss} is the second within the minute ({@code 00} through
> 1015:      *     {@code 61}), as two decimal digits.

The doc mentions seconds could be in the range [0, 61]. The normal interval should be [0, 59] but maybe there are situations where leap seconds are inserted (see https://en.wikipedia.org/wiki/Leap_second). Historically, only one second has been used so I wonder why it says "61"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20439#discussion_r1701412451

From pminborg at openjdk.org  Fri Aug  2 07:40:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 Aug 2024 07:40:32 GMT
Subject: RFR: 8337712: Wrong javadoc in java.util.Date#toString(): "61" and
 right parenthesis
In-Reply-To: <kiQA69X4p3z3COKfkKVKwWHcvjZguQ47NtQ9skg_kQI=.7052165a-8469-46bc-b0d1-e88ffad0d031@github.com>
References: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
 <kiQA69X4p3z3COKfkKVKwWHcvjZguQ47NtQ9skg_kQI=.7052165a-8469-46bc-b0d1-e88ffad0d031@github.com>
Message-ID: <S4FIeV1CciMwHxb28pdII2IkmsVBi-sPmTKAr_Py6yY=.3869fd2f-b4f5-478a-b574-08e9a336bd43@github.com>

On Fri, 2 Aug 2024 07:24:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This trivial PR proposes to add a missing parenthesis in `java.util.Date::toString`.
>
> src/java.base/share/classes/java/util/Date.java line 1015:
> 
>> 1013:      *     {@code 59}), as two decimal digits.
>> 1014:      * <li>{@code ss} is the second within the minute ({@code 00} through
>> 1015:      *     {@code 61}), as two decimal digits.
> 
> The doc mentions seconds could be in the range [0, 61]. The normal interval should be [0, 59] but maybe there are situations where leap seconds are inserted (see https://en.wikipedia.org/wiki/Leap_second). Historically, only one second has been used so I wonder why it says "61"?

![image](https://github.com/user-attachments/assets/95586ba8-5d20-40de-8ab4-47f88ba048a3)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20439#discussion_r1701429707

From asotona at openjdk.org  Fri Aug  2 08:00:32 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Aug 2024 08:00:32 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <w4XQv_NC5jO1-eL9mKSOdYIR_CIB6jXA4aJ4mTafqzo=.65d6ae87-b2dd-4d98-b37a-565475d07945@github.com>

On Fri, 2 Aug 2024 00:39:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 90:

> 88:      */
> 89:     @PreviewFeature(feature = PreviewFeature.Feature.CLASSFILE_API)
> 90:     sealed interface OfConstant<C extends AnnotationConstantValueEntry, R extends Comparable<R> & Constable>

I suggest to minimize use of generics in combination with sealed interface trees and pattern matching. It does not give many benefits, it takes out a part of the code readability and adds many unnecessary brackets and questionmarks: 

case AnnotationValue.OfConstant<?, ?> oc ->


`<R extends Comparable<R> & Constable>` at least brings a benefit of types combination. However I still think it does not outweigh the generics use cost. None of the generics parameter is near to orthogonal to the `OfConstant` nor critical for the API to operate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20436#discussion_r1701457480

From syan at openjdk.org  Fri Aug  2 08:27:57 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 2 Aug 2024 08:27:57 GMT
Subject: RFR: 8337720: Test com/sun/jndi/dns/ConfigTests/Timeout.java fails
 with C1 mode by fastdebug binary
Message-ID: <osRZGI4X7B8QU8_pn3K4Uh1aIR47ArOY5ZUzdLmSLBg=.cdc09bf5-f657-46d3-8368-0f4559dfcf20@github.com>

Hi all,
The test `com/sun/jndi/dns/ConfigTests/Timeout.java` fails with `-Xcomp -XX:TieredStopAtLevel=1` jvm options by fastdebug binary. In C1 mode and with debug binary, the JIT comple time longger than -Xmixed  and release binary is accatable. So this should not report fails with `-Xcomp -XX:TieredStopAtLevel=1` jvm options by fastdebug binary.
Thus, this test should be skip when run with `-Xcomp -XX:TieredStopAtLevel=1` jvm options by fastdebug binary.

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

Commit messages:
 - update copyright year to 2024
 - 8337720: Test com/sun/jndi/dns/ConfigTests/Timeout.java fails with C1 mode by fastdebug binary

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

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

From alanb at openjdk.org  Fri Aug  2 08:46:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Aug 2024 08:46:31 GMT
Subject: RFR: 8337720: Test com/sun/jndi/dns/ConfigTests/Timeout.java fails
 with C1 mode by fastdebug binary
In-Reply-To: <osRZGI4X7B8QU8_pn3K4Uh1aIR47ArOY5ZUzdLmSLBg=.cdc09bf5-f657-46d3-8368-0f4559dfcf20@github.com>
References: <osRZGI4X7B8QU8_pn3K4Uh1aIR47ArOY5ZUzdLmSLBg=.cdc09bf5-f657-46d3-8368-0f4559dfcf20@github.com>
Message-ID: <-x77PrtbvIa2eml5JbwDrc_0b2ojTzuD2qcXe2anIuw=.1765373b-0b13-4bc2-a9f6-d47ba0485d6d@github.com>

On Fri, 2 Aug 2024 08:21:42 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The test `com/sun/jndi/dns/ConfigTests/Timeout.java` fails with `-Xcomp -XX:TieredStopAtLevel=1` jvm options by fastdebug binary. In C1 mode and with debug binary, the JIT comple time longger than -Xmixed  and release binary is accatable. So this should not report fails with `-Xcomp -XX:TieredStopAtLevel=1` jvm options by fastdebug binary.
> Thus, this test should be skip when run with `-Xcomp -XX:TieredStopAtLevel=1` jvm options by fastdebug binary.

I assume it would be better to re-examine the timeout + retry used in the test to make it more robust when running with a debug build and different compilation modes.

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

PR Comment: https://git.openjdk.org/jdk/pull/20440#issuecomment-2264878031

From alanb at openjdk.org  Fri Aug  2 08:47:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Aug 2024 08:47:31 GMT
Subject: RFR: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix
In-Reply-To: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
References: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
Message-ID: <JuJIDUcx7EIZShK-nnW8GTrZTmVw6CdPrqes6i0Pgac=.6d2352d8-be73-4d31-9b4f-2e017b886526@github.com>

On Fri, 2 Aug 2024 00:21:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add some verbiage indicating that an `IOException` will be thrown if a file with a name generated from the supplied prefix and suffix according to the described algorithm cannot be generated by the underlying system, whether that be due to the presence of one of more characters not supported by the underlying system or for some other reason.

src/java.base/share/classes/java/io/File.java line 2120:

> 2118:      * prefix, five or more internally-generated characters, and the suffix.
> 2119:      *
> 2120:      * <p> If a file having the generated name cannot be created by the

I think it might be clear to say "with the generated name".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20435#discussion_r1701515512

From syan at openjdk.org  Fri Aug  2 08:53:31 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 2 Aug 2024 08:53:31 GMT
Subject: RFR: 8337720: Test com/sun/jndi/dns/ConfigTests/Timeout.java fails
 with C1 mode by fastdebug binary
In-Reply-To: <-x77PrtbvIa2eml5JbwDrc_0b2ojTzuD2qcXe2anIuw=.1765373b-0b13-4bc2-a9f6-d47ba0485d6d@github.com>
References: <osRZGI4X7B8QU8_pn3K4Uh1aIR47ArOY5ZUzdLmSLBg=.cdc09bf5-f657-46d3-8368-0f4559dfcf20@github.com>
 <-x77PrtbvIa2eml5JbwDrc_0b2ojTzuD2qcXe2anIuw=.1765373b-0b13-4bc2-a9f6-d47ba0485d6d@github.com>
Message-ID: <_IVdw-Cx1Avqv3VwmBWrr77fRIsy4IHkD1U0N3whzSQ=.33b7eb10-b57f-476c-9815-19bbc966c595@github.com>

On Fri, 2 Aug 2024 08:43:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume it would be better to re-examine the timeout + retry used in the test to make it more robust when running with a debug build and different compilation modes.

Okey, I will re-examine the timeout value in linux x64/linux aarch64/linux riscv64.

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

PR Comment: https://git.openjdk.org/jdk/pull/20440#issuecomment-2264889753

From alanb at openjdk.org  Fri Aug  2 09:33:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Aug 2024 09:33:36 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
In-Reply-To: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
Message-ID: <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>

On Thu, 1 Aug 2024 17:21:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the Java launcher's command line argument parsing issue on Windows. The Java launcher on Windows has been using `GetCommandLineA()` to obtain arguments, which by default does "best-fit" mapping when the arguments are converted to ANSI code page encoding. By disabling this "best-fit" mapping, the launcher's parsing works as expected. A corresponding CSR has been drafted for the behavioral change.

src/java.base/share/native/launcher/main.c line 121:

> 119:         wcCmdline, -1, NULL, 0, NULL, NULL);
> 120:     LPSTR mbCmdline = JLI_MemAlloc(mbSize);
> 121:     if (WideCharToMultiByte(CP_ACP, WC_NO_BEST_FIT_CHARS | WC_COMPOSITECHECK | WC_DEFAULTCHAR,

I think this looks okay but will need to handle GetCommandLineW, WideCharToMultiByte, or JLI_MemAlloc failing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20428#discussion_r1701589380

From rgiulietti at openjdk.org  Fri Aug  2 10:30:45 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 Aug 2024 10:30:45 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
Message-ID: <y3NwKo5PcqTE1xFnTFEzC4YJGalyoBokrf4TRHvTiMA=.73df2671-d2f1-4fdc-ba88-fa47f0c065a5@github.com>

On Thu, 1 Aug 2024 10:16:59 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:
> 
>   Last small changes

LGTM.

Please wait for another working day before issuing `/integrate`. This gives a last opportunity to reviewers in different timezone to chime in.

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

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2215277000

From rgiulietti at openjdk.org  Fri Aug  2 10:33:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 2 Aug 2024 10:33:31 GMT
Subject: RFR: 8337712: Wrong javadoc in java.util.Date#toString(): "61" and
 right parenthesis
In-Reply-To: <S4FIeV1CciMwHxb28pdII2IkmsVBi-sPmTKAr_Py6yY=.3869fd2f-b4f5-478a-b574-08e9a336bd43@github.com>
References: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
 <kiQA69X4p3z3COKfkKVKwWHcvjZguQ47NtQ9skg_kQI=.7052165a-8469-46bc-b0d1-e88ffad0d031@github.com>
 <S4FIeV1CciMwHxb28pdII2IkmsVBi-sPmTKAr_Py6yY=.3869fd2f-b4f5-478a-b574-08e9a336bd43@github.com>
Message-ID: <YAI1OvEmfBn-ZVCzurNtkhFSj4QL2RQO8nJU7uplJ5U=.b8a5f694-b433-4e1a-a56f-ff6bbacbc3dc@github.com>

On Fri, 2 Aug 2024 07:37:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Date.java line 1015:
>> 
>>> 1013:      *     {@code 59}), as two decimal digits.
>>> 1014:      * <li>{@code ss} is the second within the minute ({@code 00} through
>>> 1015:      *     {@code 61}), as two decimal digits.
>> 
>> The doc mentions seconds could be in the range [0, 61]. The normal interval should be [0, 59] but maybe there are situations where leap seconds are inserted (see https://en.wikipedia.org/wiki/Leap_second). Historically, only one second has been used so I wonder why it says "61"?
>
> ![image](https://github.com/user-attachments/assets/95586ba8-5d20-40de-8ab4-47f88ba048a3)

Indeed, given that a leap second can be theoretically inserted or removed at the end of March, June, September and December, it seems strange to have second 61 as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20439#discussion_r1701664012

From jpai at openjdk.org  Fri Aug  2 13:14:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 Aug 2024 13:14:33 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v8]
In-Reply-To: <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
Message-ID: <hYp38kwMZDokToNasNXtBHNokdX4T3ut-p54osmPxUs=.ce7c66e0-326e-4ddb-8c4e-82b1daf5cc0e@github.com>

On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java).
>  - Add GZIP input test for various gzip(1) command outputs.

Hello Archie,

> It seems like we're going around in circles a bit here... but maybe the circles are getting smaller?

We try to avoid/reduce changes in zip, gzip and other similar areas because of several open to interpretation parts of the specification and the fact that there are tools outside of the JDK (like the one we found out from Lance's example) which behave in a certain manner. I agree we sometimes do end up having to re-evaluate the original proposal. It's not a bad thing though. In fact the current discussion in this PR and the experiments have been useful to go back and check why the code behaves the way it currently does.

> IMO doing nothing is a bad option, because as it stands today the class is fundamentally unreliable

Lance, me and others have been discussing the changes in this PR for the past several days. We started this off with an intention to introduce a new constructor to allow more tighter control over not processing the "corrupt" bytes after a GZIP trailer. Experiments with the other tools (gunzip, winzip and even 7zip) has shown us that any garbage/corrupt data after a GZIP trailer is considered equivalent to end of stream and any deflated content thus far is returned from that stream - just like what the `GZIPInputStream` currently does in mainline. So its behaviour is at least consistent with these other commonly used tools. 


> Are you sure we want to do that for all of the current behavior?
>
> I would think maybe for some we do and for some we don't:
>
>    Swallowing IOException's - this we should not specify, so that we may someday eliminate it to make this class reliable
>    Concatenated GZIP's - this would be good to document
>    Reading extra bytes - the only thing to document would be that "there is a chance extra bytes will be read" which is not very useful, so what's the point?
>
> What of that would you want to specify?

The `GZIPInputStream` currently states:

> This class implements a stream filter for reading compressed data in the GZIP file format.

and that's it, nothing more. What we want to do is specify that the InputStream that is passed to the GZIPInputStream constructor is allowed to have one or more GZIP streams. A stream with more than one GZIP stream is considered a concatenated GZIP stream. The GZIPInputStream will stop processing any further content after an individual GZIP stream's trailer if that content doesn't represent a valid GZIP stream header of the next GZIP stream. 
(Of course, it might need rewording a bit with better grammar)

I think specifying these parts in the javadoc will clarify the current behaviour without getting too much into the implementation details.

> But I'm also running out of steam...

I'm sorry you had to go back and forth on some of these proposals and I understand it can be confusing and demotivating. I think to take this exercise to conclusion, we should only focus on specifying the current behaviour. Separately expanding the test coverage would be the next important thing (I'm not saying you should be doing it).

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

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2265378324

From liach at openjdk.org  Fri Aug  2 13:19:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 13:19:49 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v2]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <O18-Y5wey2Q0aKBCl28jJAGbZiQJr9DuBpvue9hAJzc=.6bbfb913-6bf2-4d66-b59e-402705804fac@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

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

 - Remove generics, further improve docs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/annotation-constant
 - 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/611a9505..b212a3ec

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

  Stats: 234 lines in 19 files changed: 111 ins; 17 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/20436.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20436/head:pull/20436

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

From liach at openjdk.org  Fri Aug  2 13:29:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 13:29:32 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v2]
In-Reply-To: <w4XQv_NC5jO1-eL9mKSOdYIR_CIB6jXA4aJ4mTafqzo=.65d6ae87-b2dd-4d98-b37a-565475d07945@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
 <w4XQv_NC5jO1-eL9mKSOdYIR_CIB6jXA4aJ4mTafqzo=.65d6ae87-b2dd-4d98-b37a-565475d07945@github.com>
Message-ID: <1TgWNYoZlzbpf02df8XWVcHsNvEsfo-mc6YNl3xAuiY=.05a3081f-c15b-4614-ad79-0eaf0da04b5d@github.com>

On Fri, 2 Aug 2024 07:57:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Remove generics, further improve docs
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/annotation-constant
>>  - 8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant
>
> src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 90:
> 
>> 88:      */
>> 89:     @PreviewFeature(feature = PreviewFeature.Feature.CLASSFILE_API)
>> 90:     sealed interface OfConstant<C extends AnnotationConstantValueEntry, R extends Comparable<R> & Constable>
> 
> I suggest to minimize use of generics in combination with sealed interface trees and pattern matching. It does not give many benefits, it takes out a part of the code readability and adds many unnecessary brackets and questionmarks: 
> 
> case AnnotationValue.OfConstant<?, ?> oc ->
> 
> 
> `<R extends Comparable<R> & Constable>` at least brings a benefit of types combination. However I still think it does not outweigh the generics use cost. None of the generics parameter is near to orthogonal to the `OfConstant` nor critical for the API to operate.

Removed the type parameters. Please review again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20436#discussion_r1701848599

From asotona at openjdk.org  Fri Aug  2 13:55:37 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Aug 2024 13:55:37 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
Message-ID: <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>

On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> 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 12 additional commits since the last revision:
> 
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Improve docs for repeating, default, and value name
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note
>  - Further refine wording
>  - Refine the spec of TypeAnnotation per Alex feedback
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863

From liach at openjdk.org  Fri Aug  2 14:19:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 14:19:52 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v3]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <WF3-IPcr-orjpBkSOZ_trEgRfYhP9Vkd8Th7q_y_hXY=.21f866e6-a0d0-41fd-ab20-10481d1da40b@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - poolEntry back to constant
 - OfInteger/Character -> OfInt/Char

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/b212a3ec..d2f56527

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

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

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

From liach at openjdk.org  Fri Aug  2 14:45:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 14:45:09 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v4]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <cSDJw2WS-i7AMhLDki4HQWZdYLPYTI9khVsTraa9ytc=.28fc4e10-e7fd-4d82-96fb-ae6943a3cd1c@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

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

  Compile error in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/d2f56527..d3390fd6

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

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

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

From chen.l.liang at oracle.com  Fri Aug  2 15:45:22 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 2 Aug 2024 15:45:22 +0000
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
 <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
Message-ID: <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>

One specification question for Alex: we call an annotation interface's element "element". What about the element-value pair that binds a value to an interface element in an annotation? Can we call this element-value pair an "element", or is there any other more proper name that is still concise? For context:
> [This annotation] is an array element of an array-valued element named {@code value} in a container annotation

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Adam Sotona <asotona at openjdk.org>
Sent: Friday, August 2, 2024 8:55 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
Subject: Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v8]

On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>>
>> Depends on #20205.
>
> 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 12 additional commits since the last revision:
>
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Improve docs for repeating, default, and value name
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - More refinements from alex
>  - Artifact -> construct
>  - More about Annotation, add equals note
>  - Further refine wording
>  - Refine the spec of TypeAnnotation per Alex feedback
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240802/7dc6a2d5/attachment.htm>

From alex.buckley at oracle.com  Fri Aug  2 15:53:49 2024
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 2 Aug 2024 08:53:49 -0700
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
 <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
 <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>
Message-ID: <1b7f69be-abe5-4380-a39b-435d92e17cec@oracle.com>

In the annotation `@Foo(a=1)`, the left hand side `a` is an _element_ 
(as declared in the annotation interface Foo) and the right hand side 
`1` is an _element value_ (per the first line of JLS 9.7.1).

Syntactically the `a` is an identifier but that's almost never relevant 
what discussing element-value pairs. In the text you quoted, "an array 
element of an array-valued element `value`" is the right way to say it.

Alex

On 8/2/2024 8:45 AM, Chen Liang wrote:
> One specification question for Alex: we call an annotation interface's 
> element "element". What about the element-value pair that binds a value 
> to an interface element in an annotation? Can we call this element-value 
> pair an "element", or is there any other more proper name that is still 
> concise? For context:
>  >?[This annotation] is an array element of an array-valued element 
> named {@code value} in a container annotation
> 
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Adam 
> Sotona <asotona at openjdk.org>
> *Sent:* Friday, August 2, 2024 8:55 AM
> *To:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>; 
> core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; 
> javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
> *Subject:* Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of 
> "be" an Annotation [v8]
> On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:
> 
>>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>>> 
>>> Depends on #20205.
>>
>> 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 12 additional commits since the last revision:
>> 
>>? - remove compile, use element-value, break long sentences
>>? - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into 
> fix/typeanno-model
>>? - Improve docs for repeating, default, and value name
>>? - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into 
> fix/typeanno-model
>>? - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into 
> fix/typeanno-model
>>? - More refinements from alex
>>? - Artifact -> construct
>>? - More about Annotation, add equals note
>>? - Further refine wording
>>? - Refine the spec of TypeAnnotation per Alex feedback
>>? - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5 
> <https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5>
> 
> Marked as reviewed by asotona (Reviewer).
> 
> -------------
> 
> PR Review: 
> https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863 
> <https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863>

From chen.l.liang at oracle.com  Fri Aug  2 15:59:11 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 2 Aug 2024 15:59:11 +0000
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v8]
In-Reply-To: <1b7f69be-abe5-4380-a39b-435d92e17cec@oracle.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <ExHxQ4tSvC3NSZji0WtSKaCEtvwPYqbEKInTHio5RH0=.ab9edad7-0b84-4446-a789-eccd648f970b@github.com>
 <WS6kJIUVVIJ1hRRuYgdTn51A4Ciz-eUlFUmsFy73BpQ=.25d94704-4140-495e-849c-95b02723c1d9@github.com>
 <CH3PR10MB76776801161AD77C8725B8F2A2B32@CH3PR10MB7677.namprd10.prod.outlook.com>
 <1b7f69be-abe5-4380-a39b-435d92e17cec@oracle.com>
Message-ID: <CH3PR10MB767755B5D08A7508FE2B3A6AA2B32@CH3PR10MB7677.namprd10.prod.outlook.com>

Thanks for the confirmation. I will submit this finalized specification for CSR review.
________________________________
From: javadoc-dev <javadoc-dev-retn at openjdk.org> on behalf of Alex Buckley <alex.buckley at oracle.com>
Sent: Friday, August 2, 2024 10:53 AM
To: compiler-dev at openjdk.org <compiler-dev at openjdk.org>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
Subject: Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation [v8]

In the annotation `@Foo(a=1)`, the left hand side `a` is an _element_
(as declared in the annotation interface Foo) and the right hand side
`1` is an _element value_ (per the first line of JLS 9.7.1).

Syntactically the `a` is an identifier but that's almost never relevant
what discussing element-value pairs. In the text you quoted, "an array
element of an array-valued element `value`" is the right way to say it.

Alex

On 8/2/2024 8:45 AM, Chen Liang wrote:
> One specification question for Alex: we call an annotation interface's
> element "element". What about the element-value pair that binds a value
> to an interface element in an annotation? Can we call this element-value
> pair an "element", or is there any other more proper name that is still
> concise? For context:
>  > [This annotation] is an array element of an array-valued element
> named {@code value} in a container annotation
>
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Adam
> Sotona <asotona at openjdk.org>
> *Sent:* Friday, August 2, 2024 8:55 AM
> *To:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>;
> core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>;
> javadoc-dev at openjdk.org <javadoc-dev at openjdk.org>
> *Subject:* Re: RFR: 8336754: Remodel TypeAnnotation to "has" instead of
> "be" an Annotation [v8]
> On Fri, 2 Aug 2024 00:04:48 GMT, Chen Liang <liach at openjdk.org> wrote:
>
>>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>>>
>>> Depends on #20205.
>>
>> 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 12 additional commits since the last revision:
>>
>>  - remove compile, use element-value, break long sentences
>>  - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into
> fix/typeanno-model
>>  - Improve docs for repeating, default, and value name
>>  - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into
> fix/typeanno-model
>>  - Merge branch 'master' of https://github.com/openjdk/jdk <https://github.com/openjdk/jdk> into
> fix/typeanno-model
>>  - More refinements from alex
>>  - Artifact -> construct
>>  - More about Annotation, add equals note
>>  - Further refine wording
>>  - Refine the spec of TypeAnnotation per Alex feedback
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5
> <https://git.openjdk.org/jdk/compare/f3707e9b...3a91a3a5>
>
> Marked as reviewed by asotona (Reviewer).
>
> -------------
>
> PR Review:
> https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863
> <https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2215642863>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240802/328908ae/attachment.htm>

From bpb at openjdk.org  Fri Aug  2 16:26:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Aug 2024 16:26:06 GMT
Subject: RFR: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix [v2]
In-Reply-To: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
References: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
Message-ID: <QPZ6oo0iv1tozJ9fOfyGsq4yvdALnpZkwvcp0Hq7kso=.a31128c2-437d-4c31-8d89-bc8650ee1bcd@github.com>

> Add some verbiage indicating that an `IOException` will be thrown if a file with a name generated from the supplied prefix and suffix according to the described algorithm cannot be generated by the underlying system, whether that be due to the presence of one of more characters not supported by the underlying system or for some other reason.

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

  6426678: having the generated name -> with the generated name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20435/files
  - new: https://git.openjdk.org/jdk/pull/20435/files/79e00800..64440ec8

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

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

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

From liach at openjdk.org  Fri Aug  2 16:31:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Aug 2024 16:31:48 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v5]
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

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

  Fix another failing test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20436/files
  - new: https://git.openjdk.org/jdk/pull/20436/files/d3390fd6..fb6b2f99

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

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

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

From naoto at openjdk.org  Fri Aug  2 17:00:32 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Aug 2024 17:00:32 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
In-Reply-To: <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
 <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>
Message-ID: <5dIBRvTE_YZmfWcnERbWGJqNS7_Ob9pO_GrPpJxbSAY=.529f931c-36de-4fe4-8798-c107c3a14722@github.com>

On Fri, 2 Aug 2024 09:30:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fixing the Java launcher's command line argument parsing issue on Windows. The Java launcher on Windows has been using `GetCommandLineA()` to obtain arguments, which by default does "best-fit" mapping when the arguments are converted to ANSI code page encoding. By disabling this "best-fit" mapping, the launcher's parsing works as expected. A corresponding CSR has been drafted for the behavioral change.
>
> src/java.base/share/native/launcher/main.c line 121:
> 
>> 119:         wcCmdline, -1, NULL, 0, NULL, NULL);
>> 120:     LPSTR mbCmdline = JLI_MemAlloc(mbSize);
>> 121:     if (WideCharToMultiByte(CP_ACP, WC_NO_BEST_FIT_CHARS | WC_COMPOSITECHECK | WC_DEFAULTCHAR,
> 
> I think this looks okay but will need to handle GetCommandLineW, WideCharToMultiByte, or JLI_MemAlloc failing.

IIUC, all errors should be handled with the proposed patch. On error with JLI_MemAlloc and WideCharToMultiByte, the process exits with `exit(1)`. As to `GetCommandLineW()`, there is no description of error in the MS document (https://learn.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-getcommandlinew), so I suppose no error handling on our side is needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20428#discussion_r1702102957

From alanb at openjdk.org  Fri Aug  2 17:55:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Aug 2024 17:55:31 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
In-Reply-To: <5dIBRvTE_YZmfWcnERbWGJqNS7_Ob9pO_GrPpJxbSAY=.529f931c-36de-4fe4-8798-c107c3a14722@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
 <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>
 <5dIBRvTE_YZmfWcnERbWGJqNS7_Ob9pO_GrPpJxbSAY=.529f931c-36de-4fe4-8798-c107c3a14722@github.com>
Message-ID: <zj-QcNNd243qiax6kqtefDGL7Hbh7YBDD9U-Or3m0aY=.d6c5a6e3-7cd3-41eb-96dc-1168ededb098@github.com>

On Fri, 2 Aug 2024 16:57:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> IIUC, all errors should be handled with the proposed patch. On error with JLI_MemAlloc and WideCharToMultiByte, the process exits with `exit(1)`. 

I think I'm mostly wondering about WideCharToMultiByte as it returns 0 when it fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20428#discussion_r1702153934

From naoto at openjdk.org  Fri Aug  2 18:04:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Aug 2024 18:04:30 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
In-Reply-To: <zj-QcNNd243qiax6kqtefDGL7Hbh7YBDD9U-Or3m0aY=.d6c5a6e3-7cd3-41eb-96dc-1168ededb098@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
 <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>
 <5dIBRvTE_YZmfWcnERbWGJqNS7_Ob9pO_GrPpJxbSAY=.529f931c-36de-4fe4-8798-c107c3a14722@github.com>
 <zj-QcNNd243qiax6kqtefDGL7Hbh7YBDD9U-Or3m0aY=.d6c5a6e3-7cd3-41eb-96dc-1168ededb098@github.com>
Message-ID: <gdmgmUg5__CXkGce2mttvGTZIoWkIQWISkjL6Ih-tBU=.0d83c5ad-e45e-4549-945f-2ac0c5944cb4@github.com>

On Fri, 2 Aug 2024 17:53:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> IIUC, all errors should be handled with the proposed patch. On error with JLI_MemAlloc and WideCharToMultiByte, the process exits with `exit(1)`. As to `GetCommandLineW()`, there is no description of error in the MS document (https://learn.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-getcommandlinew), so I suppose no error handling on our side is needed.
>
>> IIUC, all errors should be handled with the proposed patch. On error with JLI_MemAlloc and WideCharToMultiByte, the process exits with `exit(1)`. 
> 
> I think I'm mostly wondering about WideCharToMultiByte as it returns 0 when it fails.

The first call to `WideCharToMultiByte()` returns the required size for the multibyte buffer. When it returns 0, `exit(1)` is issued inside `JLI_MemAlloc()`. If the second call to `WideCharToMultiByte()` returns 0, it is explicitly dealt with the patch which also issues `exit(1)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20428#discussion_r1702160635

From acobbs at openjdk.org  Fri Aug  2 18:22:33 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 2 Aug 2024 18:22:33 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v8]
In-Reply-To: <hYp38kwMZDokToNasNXtBHNokdX4T3ut-p54osmPxUs=.ce7c66e0-326e-4ddb-8c4e-82b1daf5cc0e@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
 <hYp38kwMZDokToNasNXtBHNokdX4T3ut-p54osmPxUs=.ce7c66e0-326e-4ddb-8c4e-82b1daf5cc0e@github.com>
Message-ID: <9z2aQIulLBtkda5qYUlsD3AgZIwN-E7BZIsgZIMtrtU=.15ae541f-16c1-4e6c-a29d-bcc6072bed73@github.com>

On Fri, 2 Aug 2024 13:12:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java).
>>  - Add GZIP input test for various gzip(1) command outputs.
>
> Hello Archie,
> 
>> It seems like we're going around in circles a bit here... but maybe the circles are getting smaller?
> 
> We try to avoid/reduce changes in zip, gzip and other similar areas because of several open to interpretation parts of the specification and the fact that there are tools outside of the JDK (like the one we found out from Lance's example) which behave in a certain manner. I agree we sometimes do end up having to re-evaluate the original proposal. It's not a bad thing though. In fact the current discussion in this PR and the experiments have been useful to go back and check why the code behaves the way it currently does.
> 
>> IMO doing nothing is a bad option, because as it stands today the class is fundamentally unreliable
> 
> Lance, me and others have been discussing the changes in this PR for the past several days. We started this off with an intention to introduce a new constructor to allow more tighter control over not processing the "corrupt" bytes after a GZIP trailer. Experiments with the other tools (gunzip, winzip and even 7zip) has shown us that any garbage/corrupt data after a GZIP trailer is considered equivalent to end of stream and any deflated content thus far is returned from that stream - just like what the `GZIPInputStream` currently does in mainline. So its behaviour is at least consistent with these other commonly used tools. 
> 
> 
>> Are you sure we want to do that for all of the current behavior?
>>
>> I would think maybe for some we do and for some we don't:
>>
>>    Swallowing IOException's - this we should not specify, so that we may someday eliminate it to make this class reliable
>>    Concatenated GZIP's - this would be good to document
>>    Reading extra bytes - the only thing to document would be that "there is a chance extra bytes will be read" which is not very useful, so what's the point?
>>
>> What of that would you want to specify?
> 
> The `GZIPInputStream` currently states:
> 
>> This class implements a stream filter for reading compressed data in the GZIP file format.
> 
> and that's it, nothing more. What we want to do is specify that the InputStream that is passed to the GZIPInputStream constructor is allowed to have one or more GZIP streams. A stream with more than one GZIP stream is considered a concatenated GZIP stream. The GZIPInputStream will stop processing any further content after an individual GZIP stream's trailer if that content doesn't represent a valid GZIP stream header of the next GZIP stream. 
> (Of course, it mi...

Hi @jaikiran,

Thanks. Sorry to sound frustrated. It's not due to the back & forth with you guys but more because there are several subtle, overlapping technical issues (and judgement calls) and hashing it all out over the simplex channel of github PR comments is inherently cumbersome.

I do want to clarify one thing...

> Experiments with the other tools (gunzip, winzip and even 7zip) has shown us that any garbage/corrupt data after a GZIP trailer is considered equivalent to end of stream and any deflated content thus far is returned from that stream - just like what the GZIPInputStream currently does in mainline. So its behaviour is at least consistent with these other commonly used tools.

Yes I agree with that. My main worry is with the swallowing of `IOException`'s from the underlying stream. In theory a carefully timed malicious TCP reset could result in truncated data (even encrypted data) being read without any error reported. For some reason I'm morally offended by this :) I'm also skeptical there is code out there that actually relies on this part of the current behavior. As a result I think this particular behavior should be at least a candidate for deprecation, if not outright fixing or an alternative provided. But of course I could be wrong and realize my opinion is just one of many.

> What we want to do is specify that the InputStream that is passed to the GZIPInputStream constructor is allowed to have one or more GZIP streams. A stream with more than one GZIP stream is considered a concatenated GZIP stream. The GZIPInputStream will stop processing any further content after an individual GZIP stream's trailer if that content doesn't represent a valid GZIP stream header of the next GZIP stream.

That sounds reasonable. Importantly it doesn't specify the swallowing of `IOException`'s, which means hopefully someday we can stop doing that...

Would you guys recommend including some kind of additional statement like this?

> If an `IOException` is thrown while attempting to read or decode a GZIP header following a previous GZIP stream's trailer, it is indeterminate whether that exception is propagated to the caller, or just EOF is returned.

Once you guys let me know what you think about that point I'll update this PR to just be a Javadoc change.

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

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2265914557

From alanb at openjdk.org  Fri Aug  2 18:23:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Aug 2024 18:23:36 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
In-Reply-To: <gdmgmUg5__CXkGce2mttvGTZIoWkIQWISkjL6Ih-tBU=.0d83c5ad-e45e-4549-945f-2ac0c5944cb4@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
 <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>
 <5dIBRvTE_YZmfWcnERbWGJqNS7_Ob9pO_GrPpJxbSAY=.529f931c-36de-4fe4-8798-c107c3a14722@github.com>
 <zj-QcNNd243qiax6kqtefDGL7Hbh7YBDD9U-Or3m0aY=.d6c5a6e3-7cd3-41eb-96dc-1168ededb098@github.com>
 <gdmgmUg5__CXkGce2mttvGTZIoWkIQWISkjL6Ih-tBU=.0d83c5ad-e45e-4549-945f-2ac0c5944cb4@github.com>
Message-ID: <FSJhijSLSIn7lsVCL6zD12ZerF94cit7tRxNxBnYVt8=.26708191-8a99-4ec2-b6ba-654308df5280@github.com>

On Fri, 2 Aug 2024 18:00:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The first call to `WideCharToMultiByte()` returns the required size for the multibyte buffer. When it returns 0, `exit(1)` is issued inside `JLI_MemAlloc()`.

That's a bit subtle. I think it needs to be handled here or at least include a comment to say that it returns 0 on error which will cause JLI_MemAlloc to exit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20428#discussion_r1702179487

From naoto at openjdk.org  Fri Aug  2 18:40:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Aug 2024 18:40:07 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
 [v2]
In-Reply-To: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
Message-ID: <lrmHPqEaVTEL0ryiFfzyicQHabtXwY17TdY6PSoZ-oQ=.d9f80244-96a3-4aa7-8934-8c886a125937@github.com>

> Fixing the Java launcher's command line argument parsing issue on Windows. The Java launcher on Windows has been using `GetCommandLineA()` to obtain arguments, which by default does "best-fit" mapping when the arguments are converted to ANSI code page encoding. By disabling this "best-fit" mapping, the launcher's parsing works as expected. A corresponding CSR has been drafted for the behavioral change.

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

  Add comment for the error case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20428/files
  - new: https://git.openjdk.org/jdk/pull/20428/files/707a1bd6..6a92ed2a

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

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

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

From naoto at openjdk.org  Fri Aug  2 18:40:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Aug 2024 18:40:07 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
 [v2]
In-Reply-To: <FSJhijSLSIn7lsVCL6zD12ZerF94cit7tRxNxBnYVt8=.26708191-8a99-4ec2-b6ba-654308df5280@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
 <77SvtaQ8a42eQE-bP-JGrqaNuAHU44pVyREzshTL6Bg=.6e9abbad-2cbb-467f-b2b1-87fd02b425ab@github.com>
 <5dIBRvTE_YZmfWcnERbWGJqNS7_Ob9pO_GrPpJxbSAY=.529f931c-36de-4fe4-8798-c107c3a14722@github.com>
 <zj-QcNNd243qiax6kqtefDGL7Hbh7YBDD9U-Or3m0aY=.d6c5a6e3-7cd3-41eb-96dc-1168ededb098@github.com>
 <gdmgmUg5__CXkGce2mttvGTZIoWkIQWISkjL6Ih-tBU=.0d83c5ad-e45e-4549-945f-2ac0c5944cb4@github.com>
 <FSJhijSLSIn7lsVCL6zD12ZerF94cit7tRxNxBnYVt8=.26708191-8a99-4ec2-b6ba-654308df5280@github.com>
Message-ID: <RcyovI2Gcl4UuWMU70EMgiQOFLMyjgic2tQWoKxF_8A=.cbdbec49-07ab-45ca-99fe-770d9b0bded6@github.com>

On Fri, 2 Aug 2024 18:20:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The first call to `WideCharToMultiByte()` returns the required size for the multibyte buffer. When it returns 0, `exit(1)` is issued inside `JLI_MemAlloc()`. If the second call to `WideCharToMultiByte()` returns 0, it is explicitly dealt with the patch which also issues `exit(1)`.
>
>> The first call to `WideCharToMultiByte()` returns the required size for the multibyte buffer. When it returns 0, `exit(1)` is issued inside `JLI_MemAlloc()`.
> 
> That's a bit subtle. I think it needs to be handled here or at least include a comment to say that it returns 0 on error which will cause JLI_MemAlloc to exit.

OK, added the comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20428#discussion_r1702193100

From duke at openjdk.org  Fri Aug  2 22:52:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 2 Aug 2024 22:52:10 GMT
Subject: RFR: 8336856: Optimize String Concat [v26]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <7JmXDkO8XG2N-xZM8FRIgYvL4KX4XbmAE-ugPnNWlIA=.c12bd360-1408-4e8e-a061-9034bc8bb491@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with 14 additional commits since the last revision:

 - Merge pull request #9 from cl4es/pr_20273_inject_cache
   
   Cached prototype
 - Updated comment
 - Redo concatArgs
 - Shift constructor logic to shared superclass
 - merge
 - Remove defensive cloning (hidden class, trusted caller)
 - Rename
 - Mark all fields as @Stable
 - Simplify, promote byte and short arguments to int early
 - Weak -> Soft reference the constructor+handle pair
 - ... and 4 more: https://git.openjdk.org/jdk/compare/b7e1f524...c91b82a8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/b7e1f524..c91b82a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=24-25

  Stats: 262 lines in 2 files changed: 143 ins; 66 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From duke at openjdk.org  Sat Aug  3 09:48:43 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 3 Aug 2024 09:48:43 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
Message-ID: <rgfTXMCbVA-dh2NzbTU4agpjqmMMz_UBb13VP01pezg=.389720fd-849f-41de-88c5-7331bf71779e@github.com>

On Thu, 1 Aug 2024 10:16:59 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:
> 
>   Last small changes

`/integrate`

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2266656350

From duke at openjdk.org  Sat Aug  3 09:48:44 2024
From: duke at openjdk.org (duke)
Date: Sat, 3 Aug 2024 09:48:44 GMT
Subject: RFR: 8334755: Asymptotically faster implementation of square root
 algorithm [v50]
In-Reply-To: <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
References: <G_L2YhPongvI31hmgNoqduB02mXtR3FV1PKhyYzbBfg=.7963f050-f98b-4333-96b8-6ab05ac9f59c@github.com>
 <2XkjBhhf40aqq9d3mtibboTt6bUGkXlosxs4V6Ub010=.56edc930-dac8-4661-81f9-fee4bc674451@github.com>
Message-ID: <Gct8yNOLNdZi9haB2CEkSgzKjXTvNGhXNbiW9uC-TdE=.ff580b3e-6384-4692-925e-c66b4f50472d@github.com>

On Thu, 1 Aug 2024 10:16:59 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:
> 
>   Last small changes

@fabioromano1 
Your change (at version 4c1d9e57158994e55a2e6429ecc2bb3dad46b4b1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19710#issuecomment-2266656648

From duke at openjdk.org  Sat Aug  3 10:39:09 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 3 Aug 2024 10:39:09 GMT
Subject: RFR: 8336856: Optimize String Concat [v27]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <2z35cKps1dTvrKhnedIrbFtTXAOOtvhQRiXXPcdYg0A=.1cd7f449-c94b-4809-8832-babc079fd8ce@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  remove lengthcoder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/c91b82a8..a3cd822e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=25-26

  Stats: 452 lines in 2 files changed: 296 ins; 74 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From duke at openjdk.org  Sat Aug  3 13:11:43 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 3 Aug 2024 13:11:43 GMT
Subject: Integrated: 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: <qiUXtNB_ctmg6hPn0B_83ElFAgsVEWMdsv2XAnvkTUI=.37b49875-f6d1-4464-8386-a8175084ad92@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.

This pull request has now been integrated.

Changeset: 367e0a65
Author:    fabioromano1 <51378941+fabioromano1 at users.noreply.github.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/367e0a65561f95aad61b40930d5f46843fee3444
Stats:     416 lines in 4 files changed: 331 ins; 26 del; 59 mod

8334755: Asymptotically faster implementation of square root algorithm

Reviewed-by: rgiulietti

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

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

From davidalayachew at gmail.com  Sun Aug  4 07:14:42 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 4 Aug 2024 03:14:42 -0400
Subject: Gatherers -- windowBy
Message-ID: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>

Hello Core Libs Dev Team,

Apologies for the massive delay. I have been juggling many severe personal
emergencies, and thus, did not have time or strength to follow up on the
previous thread --
https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html

As mentioned in my previous thread, I have been extremely happy with the
new Gatherers API, and have found numerous uses for it.

I did want to add one addition to the list of premade gatherers provided by
the standard library in java.util.stream.Gatherers API -- a windowBy
gatherer.

The result of the thread was that, while the feature had nothing wrong with
it, evidence needed to be provided of its utility. This email is that
evidence. Specifically, this email is providing all of the situations where
I used this windowBy Gatherer that Viktor Klang made for me, with the hope
that it is strong enough evidence to push this method into the Gatherers
API.

Here we go.

   1. Advent of Code 2020 -- Day 14 [1] -- and here is my code [2] -- here
   is a link to the line that actually used the gatherer [3]
   1. This cleaned up my solution CONSIDERABLY. If I was doing this with
      for loops, I would have to do index manipulation to jump ahead
my for loop
      index wise. Here, all I am doing is telling it how to split apart the
      stream. Way more clear and elegant. Which was critical because
this AOC day
      was extremely difficult for me. Solution is not yet done, but
making great
      progress.
      2. Service Health Analytics -- Work project, so I can't share the code
      1. This was a super basic use case, but long story short, I'm tracing
      down yet another network issue, and I wanted to know what was occurring
      before the network outage, to see if there was a correlation. I ended up
      scrapping this solution in favor of another one, but I was quite
happy with
      how easy the Gatherer made it to grab exactly what I wanted. It
was just a
      windowBy followed by a sliding window, and then extracting some info by
      comparing the 2 chunks.
      3. Typing Metrics [4] -- here is the link to the method that uses the
   Gatherer [5]
   1. This is where I really put the Gatherer through its paces. I had some
      semi-complex examples, but I got them all to work out well. It made my
      logic simpler than the imperative equivalent, while also keeping things
      concise. Now, one point that caused me some difficulty was
recognizing that
      the Gatherer has a surprisingly large number of edge cases. For example,
      when looking at the data in aggregate, you notice a pattern -- the first
      element of every window is the FALSE case of your predicate, while all
      remaining members of that window are the TRUE case of the predicate.
      However, it's very possible for the first window to be a single element
      TRUE case window. I think this is the first time I found a valid use for
      the Stream::dropWhile method lol. But otherwise, this feature
REALLY helped
      me move forward, and I am very happy with it!

My biggest takeaway from using this Gatherer is that, when dealing with a
Stream of events that you want to get metrics of, this gatherer is going to
be a critical tool in the arsenal. This Gatherer also pairs BEAUTIFULLY
with slidingWindow, to where I feel it made sliding window even stronger. I
break up my stream into chunks using the windowBy, then slide over those
chunks using sliding window. I kept finding myself using this strategy to
aggregate and analyze. To use an analogy, it feels almost like making a
database view of a larger database table.

This is my experience using the windowBy Gatherer that Viktor Klang gave
me. Please let me know if there are any questions, comments, or concerns.

Thank you for your time, patience, and understanding!
David Alayachew

[1] = https://adventofcode.com/2020/day/14
[2] =
https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L334
[3] =
https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L468
[4] = https://github.com/davidalayachew/HowFastCanYouType
[5] =
https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java#L151
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240804/10e3a217/attachment.htm>

From davidalayachew at gmail.com  Sun Aug  4 07:15:59 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 4 Aug 2024 03:15:59 -0400
Subject: Gatherers -- conditionalWindowFixed?
In-Reply-To: <CAA9v-_PXqXxGB0vhUxhvFAsWeW5X6gifUx1zoq0vS-PoKQv-ag@mail.gmail.com>
References: <CAA9v-_NX5c0GwfMNJihrGiB7A71CQxHRMEarU_-hedzAXf73UA@mail.gmail.com>
 <MW4PR10MB5774AA5CEDA7B1FEFDA4D07BFF692@MW4PR10MB5774.namprd10.prod.outlook.com>
 <509230836.99178022.1704910615048.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774D2C27CF509EE48B8DC66FF692@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_PXqXxGB0vhUxhvFAsWeW5X6gifUx1zoq0vS-PoKQv-ag@mail.gmail.com>
Message-ID: <CAA9v-_Pi4wbRxvH0GZM0XtzVFhCxp9QibCk2OnVxQ69JfEBr8g@mail.gmail.com>

Hello,

Sorry I didn't respond when I said I was going to. I have been juggling
some pretty severe personal emergencies. So, not only am I overdue on this,
but I don't really have the energy to make the full post I originally
wanted to.

Regardless, I have made a new thread posting my findings, and why I think
this new windowBy function makes sense. Here is the link --
https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127293.html

Thank you for your time and patience!
David Alayachew

On Sun, Jan 28, 2024 at 1:54?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Thank you both for your replies!
>
> And thanks for the Gatherer example Viktor.
>
> It sounds like, from your email, that you want to see just how useful this
> method would be to add before we can justify adding it to Gatherers.
>
> Fair enough. I have spent a couple of days using this custom Gatherer you
> made for me, and I will post a new email thread either tomorrow or the day
> after that shows my experience with it. My hope is that I can convince you
> that this function absolutely is worth adding.
>
> Thank you for your time and help!
> David Alayachew
>
> On Wed, Jan 10, 2024 at 2:29?PM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>> >1/ Is there a reason why the integrator is not declared greedy (I'm
>> still not sure to what exactly Greedy means in the context of gatherers) ?
>>
>> No, that was just a (benign) omission from typing the solution as I was
>> typing the email ?
>>
>> >2/ Is there a reason to write the code in a OOP way like you have done
>> instead of only having fields in State and specify the behaviors using
>> lambdas (because with lambdas will you get inference)
>>
>> Great question!
>> I chose to do that since I wanted to A) allocate the backing list
>> on-demand, and also B) not allocate a new ArrayList for the downstream
>> windows and retain the (cleared) old one (since its size could become
>> needlessly large).
>>
>>
>> As a side-note, I tend to prototype using lambdas and then refactor
>> as/when needed to either embed logic in the state or even migrate into a
>> full-on implementation of the Gatherer interface (for instance if I want to
>> override composition).
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>>
>>
>> ------------------------------
>> *From:* Remi Forax <forax at univ-mlv.fr>
>> *Sent:* Wednesday, 10 January 2024 19:16
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* David Alayachew <davidalayachew at gmail.com>; core-libs-dev <
>> core-libs-dev at openjdk.org>
>> *Subject:* [External] : Re: Gatherers -- conditionalWindowFixed?
>>
>>
>>
>> ------------------------------
>>
>> *From: *"Viktor Klang" <viktor.klang at oracle.com>
>> *To: *"David Alayachew" <davidalayachew at gmail.com>, "core-libs-dev" <
>> core-libs-dev at openjdk.org>
>> *Sent: *Wednesday, January 10, 2024 2:33:45 PM
>> *Subject: *Re: Gatherers -- conditionalWindowFixed?
>>
>> Hi David!
>>
>> Apologies for the late reply, there's been lots of catching up to do
>> after the holidays.
>>
>> >I'm really excited for what this will enable for us.
>>
>> I'm really glad to hear that \uD83D\uDE42
>>
>> >It is very much appreciated.
>>
>> \uD83D\uDC4D
>>
>> > Could we add one more method for a conditionalWindowFixed? We would
>> need to pass in some Predicate<T>. If the predicate returns true, create a
>> list (if it does not already exist) then add the element to it. If the
>> predicate returns false while the list is empty, then just move along to
>> the next. Else if the predicate returns false while the list is non empty,
>> pass the list down into the stream. So, you end up with Stream<T> ----->
>> Stream<List<T>>.
>>
>> What ends up under Gatherers.* does require careful triaging, ideally by
>> first seeing user-created implementations being heavily used/useful, then
>> potential candidate for Gatherers.*, and then at the end it might end up in
>> Stream as a dedicated method.
>>
>> By virtue of the Gatherers API, it seems pretty straight-forward for you
>> to implement what you describe, and personally I'd probably call it
>> something like *windowBy*.
>>
>> Just typing this up as I write this reply, it could look something like
>> this:
>>
>> <TR> Gatherer<TR, ?, List<TR>> windowBy(Predicate<TR>
>> includeInCurrentWindow) {
>>   class State {
>>     ArrayList<TR> window;
>>
>>     boolean integrate(TR element, Gatherer.Downstream<? super List<TR>>
>> downstream) {
>>       if (window != null && !includeInCurrentWindow.test(element)) {
>>         var result = Collections.unmodifiableList(window);
>>         window = null;
>>         if (!downstream.push(result))
>>           return false;
>>       }
>>
>>       if (window == null)
>>         window = new ArrayList<>();
>>
>>       return window.add(element);
>>     }
>>
>>     void finish(Gatherer.Downstream<? super List<TR>> downstream) {
>>       if (window != null) {
>>         var result = Collections.unmodifiableList(window);
>>         window = null;
>>         downstream.push(result);
>>       }
>>     }
>>   }
>>   return Gatherer.<TR, State, List<TR>>ofSequential(State::new,
>> State::integrate, State::finish);
>> }
>>
>> jshell> Stream.of("header", "value1", "value2", "header", "header",
>> "value 3", "value 4",
>> null).gather(windowBy(Predicate.not("header"::equals))).toList()
>> $1 ==> [[header, value1, value2], [header], [header, value 3, value 4,
>> null]]
>>
>>
>> Hello,
>> I've two questions,
>> 1/ Is there a reason why the integrator is not declared greedy (I'm still
>> not sure to what exactly Greedy means in the context of gatherers) ?
>> 2/ Is there a reason to write the code in a OOP way like you have done
>> instead of only having fields in State and specify the behaviors using
>> lambdas (because with lambdas will you get inference)
>>
>> <T> Gatherer<T, ?, List<T>> windowBy(Predicate<? super T>
>> includeInCurrentWindow) {
>>   class State {
>>     ArrayList<T> window;
>>   }
>>   return Gatherer.ofSequential(
>>       State::new,
>>       (state, element, downstream) -> {
>>        ...
>>       },
>>       (state, downstream) -> {
>>         ...
>>       });
>> }
>>
>>
>> Cheers,
>> ?
>>
>>
>> regards,
>> R?mi
>>
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
>> David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Wednesday, 10 January 2024 07:05
>> *To:* core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>> *Subject:* Gatherers -- conditionalWindowFixed?
>>
>> Hello Core Libs Dev Team,
>>
>> I have been reading through JEP 461 (https://openjdk.org/jeps/461) about
>> Gatherers, and I'm really excited for what this will enable for us.
>>
>> By far, the most important functionality that this API facilitates is the
>> ability to create windows. Anytime I needed a window, I was basically
>> forced to use a for loop. Now, the 2 most common window cases are being
>> handed to us for free. It is very much appreciated.
>>
>> Could we add one more method for a conditionalWindowFixed? We would need
>> to pass in some Predicate<T>. If the predicate returns true, create a list
>> (if it does not already exist) then add the element to it. If the predicate
>> returns false while the list is empty, then just move along to the next.
>> Else if the predicate returns false while the list is non empty, pass the
>> list down into the stream. So, you end up with Stream<T> ----->
>> Stream<List<T>>.
>>
>> The reason I think this is worth adding is because it facilitates a
>> really common use case. We may not want all windows to be the same size.
>>
>> Is this something worth adding to the Gatherers API?
>>
>> Thank you for your time and help!
>> David Alayachew
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240804/ed3c89f8/attachment-0001.htm>

From davidalayachew at gmail.com  Sun Aug  4 07:22:05 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 4 Aug 2024 03:22:05 -0400
Subject: Gatherers -- windowBy
In-Reply-To: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>
References: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>
Message-ID: <CAA9v-_NaLQogawXq_rDYm_c946mPZ2syMSuh+xgxany6v+ja-g@mail.gmail.com>

Just realized that 4 and 5 will become dead links after my next commit. So
here is a link tied to the commit.

https://github.com/davidalayachew/HowFastCanYouType/blob/e3ed9880a0927e84ebf8e5858cdcca9581186034/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java#L151

On Sun, Aug 4, 2024 at 3:14?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Core Libs Dev Team,
>
> Apologies for the massive delay. I have been juggling many severe personal
> emergencies, and thus, did not have time or strength to follow up on the
> previous thread --
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html
>
> As mentioned in my previous thread, I have been extremely happy with the
> new Gatherers API, and have found numerous uses for it.
>
> I did want to add one addition to the list of premade gatherers provided
> by the standard library in java.util.stream.Gatherers API -- a windowBy
> gatherer.
>
> The result of the thread was that, while the feature had nothing wrong
> with it, evidence needed to be provided of its utility. This email is that
> evidence. Specifically, this email is providing all of the situations where
> I used this windowBy Gatherer that Viktor Klang made for me, with the hope
> that it is strong enough evidence to push this method into the Gatherers
> API.
>
> Here we go.
>
>    1. Advent of Code 2020 -- Day 14 [1] -- and here is my code [2] --
>    here is a link to the line that actually used the gatherer [3]
>    1. This cleaned up my solution CONSIDERABLY. If I was doing this with
>       for loops, I would have to do index manipulation to jump ahead my for loop
>       index wise. Here, all I am doing is telling it how to split apart the
>       stream. Way more clear and elegant. Which was critical because this AOC day
>       was extremely difficult for me. Solution is not yet done, but making great
>       progress.
>       2. Service Health Analytics -- Work project, so I can't share the
>    code
>       1. This was a super basic use case, but long story short, I'm
>       tracing down yet another network issue, and I wanted to know what was
>       occurring before the network outage, to see if there was a correlation. I
>       ended up scrapping this solution in favor of another one, but I was quite
>       happy with how easy the Gatherer made it to grab exactly what I wanted. It
>       was just a windowBy followed by a sliding window, and then extracting some
>       info by comparing the 2 chunks.
>       3. Typing Metrics [4] -- here is the link to the method that uses
>    the Gatherer [5]
>    1. This is where I really put the Gatherer through its paces. I had
>       some semi-complex examples, but I got them all to work out well. It made my
>       logic simpler than the imperative equivalent, while also keeping things
>       concise. Now, one point that caused me some difficulty was recognizing that
>       the Gatherer has a surprisingly large number of edge cases. For example,
>       when looking at the data in aggregate, you notice a pattern -- the first
>       element of every window is the FALSE case of your predicate, while all
>       remaining members of that window are the TRUE case of the predicate.
>       However, it's very possible for the first window to be a single element
>       TRUE case window. I think this is the first time I found a valid use for
>       the Stream::dropWhile method lol. But otherwise, this feature REALLY helped
>       me move forward, and I am very happy with it!
>
> My biggest takeaway from using this Gatherer is that, when dealing with a
> Stream of events that you want to get metrics of, this gatherer is going to
> be a critical tool in the arsenal. This Gatherer also pairs BEAUTIFULLY
> with slidingWindow, to where I feel it made sliding window even stronger. I
> break up my stream into chunks using the windowBy, then slide over those
> chunks using sliding window. I kept finding myself using this strategy to
> aggregate and analyze. To use an analogy, it feels almost like making a
> database view of a larger database table.
>
> This is my experience using the windowBy Gatherer that Viktor Klang gave
> me. Please let me know if there are any questions, comments, or concerns.
>
> Thank you for your time, patience, and understanding!
> David Alayachew
>
> [1] = https://adventofcode.com/2020/day/14
> [2] =
> https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L334
> [3] =
> https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L468
> [4] = https://github.com/davidalayachew/HowFastCanYouType
> [5] =
> https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java#L151
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240804/43e52dbb/attachment.htm>

From duke at openjdk.org  Sun Aug  4 16:09:08 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 4 Aug 2024 16:09:08 GMT
Subject: RFR: 8336856: Optimize String Concat [v28]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <H2c2B6KQQxVsyKZRsR04Fg9Cb997LNQImg2WaVyggBg=.bccba6fc-bbd0-4898-9ee1-f8fbf312c257@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with 11 additional commits since the last revision:

 - 1. split length & coder & prepend method
   2. fix comment
   3. change forceInlineThreshold to 16
   4. 1 arg use built-in method
   5. add tests
 - Extract an erasedArgs method
 - Remove unnecessary operations
 - copyright
 - typo
 - bug fix and make clean
 - Code structuring to reduce the size of generated code
 - forceinline
 - use prepend and split lengthcoder
 - Revert "use static method, remove ConcatBase & MethodHandlePair & CONSTRUCTOR_BUILDER"
   
   This reverts commit 03d0c3e6d638a94b29000da510e3b69abdbbe240.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a3cd822e...937f4117

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/a3cd822e..937f4117

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=26-27

  Stats: 811 lines in 5 files changed: 512 ins; 132 del; 167 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From duke at openjdk.org  Sun Aug  4 16:25:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 4 Aug 2024 16:25:39 GMT
Subject: RFR: 8336856: Optimize String Concat [v28]
In-Reply-To: <H2c2B6KQQxVsyKZRsR04Fg9Cb997LNQImg2WaVyggBg=.bccba6fc-bbd0-4898-9ee1-f8fbf312c257@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <H2c2B6KQQxVsyKZRsR04Fg9Cb997LNQImg2WaVyggBg=.bccba6fc-bbd0-4898-9ee1-f8fbf312c257@github.com>
Message-ID: <FqA4O9Z9yI5RQyAGHOdHsuPCW-PpwgJP-EoU35x-ZaY=.2e317650-a0ac-4c58-b0d8-97b68f29723d@github.com>

On Sun, 4 Aug 2024 16:09:08 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with 11 additional commits since the last revision:
> 
>  - 1. split length & coder & prepend method
>    2. fix comment
>    3. change forceInlineThreshold to 16
>    4. 1 arg use built-in method
>    5. add tests
>  - Extract an erasedArgs method
>  - Remove unnecessary operations
>  - copyright
>  - typo
>  - bug fix and make clean
>  - Code structuring to reduce the size of generated code
>  - forceinline
>  - use prepend and split lengthcoder
>  - Revert "use static method, remove ConcatBase & MethodHandlePair & CONSTRUCTOR_BUILDER"
>    
>    This reverts commit 03d0c3e6d638a94b29000da510e3b69abdbbe240.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/a3cd822e...937f4117

[StringConcat13.txt](https://github.com/user-attachments/files/16488239/StringConcat13.txt)

The version of 937f4117162efc869d6dd0a2ff7465fb2071895c has achieved the same performance as the version using MethodHandle, and is significantly ahead in startup performance.

Below are the performance numbers on the MacBook M1 Pro


# prepend last version 
git chekcout 937f4117162efc869d6dd0a2ff7465fb2071895c

# baseline
make test TEST="micro:java.lang.StringConcat" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=20"

# bytecode
make test TEST="micro:java.lang.StringConcat" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0"


|   | baseline  | bytecode | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 1226.402 | 1064.982 | 15.16% |
| StringConcat.concat13String | 45.690 | 44.908 | 1.74% |
| StringConcat.concat13StringConst | 71.923 | 65.761 | 9.37% |
| StringConcat.concat23String | 136.207 | 136.542 | -0.25% |
| StringConcat.concat23StringConst | 115.112 | 115.689 | -0.50% |
| StringConcat.concat30Mix | 404.258 | 411.780 | -1.83% |
| StringConcat.concat3String | 12.529 | 12.657 | -1.01% |
| StringConcat.concat4String | 13.950 | 23.398 | -40.38% |
| StringConcat.concat6String | 19.983 | 18.363 | 8.82% |
| StringConcat.concatConst2String | 9.783 | 7.974 | 22.69% |
| StringConcat.concatConst4String | 14.783 | 22.698 | -34.87% |
| StringConcat.concatConst6Object | 51.522 | 47.578 | 8.29% |
| StringConcat.concatConst6String | 19.563 | 18.592 | 5.22% |
| StringConcat.concatConstBool | 3.432 | 3.435 | -0.09% |
| StringConcat.concatConstBoolByte | 6.465 | 6.172 | 4.75% |
| StringConcat.concatConstBoolString | 7.234 | 7.846 | -7.80% |
| StringConcat.concatConstBoolean | 3.970 | 3.953 | 0.43% |
| StringConcat.concatConstBooleanConst | 4.870 | 4.860 | 0.21% |
| StringConcat.concatConstBooleanString | 7.429 | 8.589 | -13.51% |
| StringConcat.concatConstFloat | 56.911 | 53.658 | 6.06% |
| StringConcat.concatConstFloatConst | 54.156 | 53.585 | 1.07% |
| StringConcat.concatConstFloatString | 59.664 | 60.519 | -1.41% |
| StringConcat.concatConstInt | 6.075 | 6.074 | 0.02% |
| StringConcat.concatConstIntConst | 6.880 | 6.436 | 6.90% |
| StringConcat.concatConstIntConstInt | 9.748 | 9.955 | -2.08% |
| StringConcat.concatConstIntString | 14.359 | 10.480 | 37.01% |
| StringConcat.concatConstInteger | 3.997 | 3.981 | 0.40% |
| StringConcat.concatConstIntegerConst | 4.763 | 4.750 | 0.27% |
| StringConcat.concatConstIntegerString | 6.973 | 7.789 | -10.48% |
| StringConcat.concatConstObjectConst | 11.078 | 10.961 | 1.07% |
| StringConcat.concatConstString | 4.976 | 4.960 | 0.32% |
| StringConcat.concatConstStringConst | 8.101 | 6.161 | 31.49% |
| StringConcat.concatConstStringConstInt | 11.896 | 27.647 | -56.97% |
| StringConcat.concatEmptyConstInt | 5.604 | 5.667 | -1.11% |
| StringConcat.concatEmptyConstString | 2.058 | 2.084 | -1.25% |
| StringConcat.concatEmptyLeft | 2.212 | 2.244 | -1.43% |
| StringConcat.concatEmptyRight | 2.327 | 2.369 | -1.77% |
| StringConcat.concatMethodConstString | 4.969 | 5.030 | -1.21% |
| StringConcat.concatMix4String | 81.670 | 75.552 | 8.10% |
| StringConcat.concatStringBoolString | 19.159 | 8.492 | 125.61% |
| StringConcat.concatStringBooleanString | 9.847 | 8.492 | 15.96% |
| StringConcat.concatStringIntString | 18.228 | 15.132 | 20.46% |
| StringConcat.concatStringIntegerString | 9.097 | 8.528 | 6.67% |
| StringConcatStartup.MixedLarge.run | 321.940 | 152.246 | 111.46% |
| StringConcatStartup.MixedSmall.run | 29.818 | 7.609 | 291.88% |
| StringConcatStartup.StringLarge.run | 93.671 | 31.292 | 199.34% |
| StringConcatStartup.StringSingle.constBool | 3.110 | 0.465 | 568.82% |
| StringConcatStartup.StringSingle.constBoolString | 0.231 | 0.744 | -68.95% |
| StringConcatStartup.StringSingle.constBoolean | 0.120 | 0.145 | -17.24% |
| StringConcatStartup.StringSingle.constBooleanString | 3.549 | 0.996 | 256.33% |
| StringConcatStartup.StringSingle.constFloat | 3.800 | 0.601 | 532.28% |
| StringConcatStartup.StringSingle.constFloatString | 5.741 | 1.237 | 364.11% |
| StringConcatStartup.StringSingle.constInt | 3.004 | 0.465 | 546.02% |
| StringConcatStartup.StringSingle.constIntString | 0.146 | 0.119 | 22.69% |
| StringConcatStartup.StringSingle.constInteger | 0.121 | 0.143 | -15.38% |
| StringConcatStartup.StringSingle.constIntegerString | 3.585 | 0.996 | 259.94% |
| StringConcatStartup.StringSingle.constString | 0.116 | 0.141 | -17.73% |
| StringConcatStartup.StringThree.stringIntString | 7.000 | 1.552 | 351.03% |
| StringConcatStartup.StringThree.stringIntegerString | 6.530 | 1.070 | 510.28% |

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2267596390

From jwaters at openjdk.org  Mon Aug  5 05:15:41 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 5 Aug 2024 05:15:41 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v3]
In-Reply-To: <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
Message-ID: <fajmeY0hG_jwXo_lyU-w1ieH5JSjfgyHcDnIZx-1ab4=.0ef03076-fa77-4c2c-beec-b69786bfca2b@github.com>

On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Standard Integer type rewrite

Alright! Just need approval for java.base and security, then we should be good to go

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

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2268188595

From duke at openjdk.org  Mon Aug  5 05:38:09 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 5 Aug 2024 05:38:09 GMT
Subject: RFR: 8336856: Optimize String Concat [v29]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <CkpY6y7mwAx_zN9r_LOZKF_jl-EABtacL-APW87xTTY=.92831aee-605e-46a9-8bb4-c7c92d9d32c6@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - copyright
 - add comments & code style & make code clear
 - add comments and make code clear
 - fix comments and reduce code size of generated methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/937f4117..520f4ced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=27-28

  Stats: 244 lines in 3 files changed: 114 ins; 68 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From jpai at openjdk.org  Mon Aug  5 05:57:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Aug 2024 05:57:32 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v3]
In-Reply-To: <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
Message-ID: <cUUSMuOwfn8ecOydsqcwOPF8ghiMWDO5FZJKvJFMO_M=.679d9ef6-cc34-40c9-a02e-3e6cba143ebb@github.com>

On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Standard Integer type rewrite

Hello Julian,
> Just need approval for java.base and security

Daniel has approved this PR and I think that should take care of java.base review. In any case, I had a look at the java.base change and it looks OK to me.

A several of these files will need a copyright year change. Could you update those files to use 2024?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2218070566

From jpai at openjdk.org  Mon Aug  5 06:19:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Aug 2024 06:19:31 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity
In-Reply-To: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
Message-ID: <yBB-fRr44ijZUeCYpkH3_tFSA38h0QJNqZx935CnzBU=.44470bf1-e0e8-4c40-b156-1486a31afece@github.com>

On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result.

Doug has reviewed this doc-only change and the proposed update to the text looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20388#pullrequestreview-2218116731

From vklang at openjdk.org  Mon Aug  5 09:57:04 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 5 Aug 2024 09:57:04 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity [v2]
In-Reply-To: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
Message-ID: <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>

> Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result.

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

  Adding paragraph to ConcurrentSkipListSet::set

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20388/files
  - new: https://git.openjdk.org/jdk/pull/20388/files/6240668b..c1e02242

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

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

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

From vklang at openjdk.org  Mon Aug  5 09:57:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 5 Aug 2024 09:57:05 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity [v2]
In-Reply-To: <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
 <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>
Message-ID: <8_eyxXY8-j0m1fnJtkg3RSSB43OthhHwaioE98mSklI=.13c1c4ea-537e-400e-a0bc-8611edf24983@github.com>

On Mon, 5 Aug 2024 09:53:48 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding paragraph to ConcurrentSkipListSet::set

src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 192:

> 190:      * returns {@code Integer.MAX_VALUE}.
> 191:      *
> 192:      * <p>It is possible for the size to change during execution of this method,

@jaikiran Realized the paragraph fell away so I re-added it. Reapproval needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20388#discussion_r1703861457

From jpai at openjdk.org  Mon Aug  5 10:26:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Aug 2024 10:26:31 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity [v2]
In-Reply-To: <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
 <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>
Message-ID: <0FfHzdRmMWfZWJ0xMztxZoFYXGjDPnXorsR2rx08YGo=.37164e44-6314-4637-904c-3447bfd67782@github.com>

On Mon, 5 Aug 2024 09:57:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding paragraph to ConcurrentSkipListSet::set

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20388#pullrequestreview-2218625410

From jpai at openjdk.org  Mon Aug  5 10:26:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Aug 2024 10:26:32 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity [v2]
In-Reply-To: <8_eyxXY8-j0m1fnJtkg3RSSB43OthhHwaioE98mSklI=.13c1c4ea-537e-400e-a0bc-8611edf24983@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
 <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>
 <8_eyxXY8-j0m1fnJtkg3RSSB43OthhHwaioE98mSklI=.13c1c4ea-537e-400e-a0bc-8611edf24983@github.com>
Message-ID: <X0SHllvqxdI_dl2S0zVzz5B-8U18JP0TVqtwOgPKxpk=.24a3fa81-fed8-4ab6-8009-7a6dc83a510d@github.com>

On Mon, 5 Aug 2024 09:52:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding paragraph to ConcurrentSkipListSet::set
>
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 192:
> 
>> 190:      * returns {@code Integer.MAX_VALUE}.
>> 191:      *
>> 192:      * <p>It is possible for the size to change during execution of this method,
> 
> @jaikiran Realized the paragraph fell away so I re-added it. Reapproval needed?

Hello Viktor, the new review process in the JDK project marks the previous review as stale if a change is done after the approval. Re-review is mandated in such cases. I've now approved the latest change which looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20388#discussion_r1703897877

From vklang at openjdk.org  Mon Aug  5 10:56:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 5 Aug 2024 10:56:38 GMT
Subject: RFR: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity [v2]
In-Reply-To: <X0SHllvqxdI_dl2S0zVzz5B-8U18JP0TVqtwOgPKxpk=.24a3fa81-fed8-4ab6-8009-7a6dc83a510d@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
 <2Qm5Ijeqq_VQcUuRhID3kQdHy-JjXVl0VBh_HVT81_k=.e4965b7d-63b5-4f51-bcb1-2aefcdd45937@github.com>
 <8_eyxXY8-j0m1fnJtkg3RSSB43OthhHwaioE98mSklI=.13c1c4ea-537e-400e-a0bc-8611edf24983@github.com>
 <X0SHllvqxdI_dl2S0zVzz5B-8U18JP0TVqtwOgPKxpk=.24a3fa81-fed8-4ab6-8009-7a6dc83a510d@github.com>
Message-ID: <dD98zKUQfsuvH1jBTb5Ob1x24dr4cWmE_i2GKQCKsHU=.90f2cb63-d776-4090-909b-2ef36d4925b4@github.com>

On Mon, 5 Aug 2024 10:23:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java line 192:
>> 
>>> 190:      * returns {@code Integer.MAX_VALUE}.
>>> 191:      *
>>> 192:      * <p>It is possible for the size to change during execution of this method,
>> 
>> @jaikiran Realized the paragraph fell away so I re-added it. Reapproval needed?
>
> Hello Viktor, the new review process in the JDK project marks the previous review as stale if a change is done after the approval. Re-review is mandated in such cases. I've now approved the latest change which looks good to me.

Thanks @jaikiran ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20388#discussion_r1703932924

From vklang at openjdk.org  Mon Aug  5 10:59:36 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 5 Aug 2024 10:59:36 GMT
Subject: Integrated: 8336462: ConcurrentSkipListSet Javadoc incorrectly warns
 about size method complexity
In-Reply-To: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
References: <Qwek3RZKl-XIbiO4-jbDDL5pGjfEicI-bUUNiXyy5rg=.ecb1df8f-c459-4a7d-afa9-4031e38f0df2@github.com>
Message-ID: <FC0u0tzlZAIcvcJHSpeZlQpEUU0T343VFY7-MLSdv6A=.975105f0-679f-4de1-8285-5a68cf0d6abc@github.com>

On Tue, 30 Jul 2024 09:24:12 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Removes some of the old wording around the algorithmic complexity of ConcurrentSkipListSet::size() while still retaining the warning around the accuracy of the returned result.

This pull request has now been integrated.

Changeset: d3e7b0c1
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3e7b0c12afde03985f1b06e6e7d789928971090
Stats:     8 lines in 1 file changed: 0 ins; 5 del; 3 mod

8336462: ConcurrentSkipListSet Javadoc incorrectly warns about size method complexity

Reviewed-by: jpai

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

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

From duke at openjdk.org  Mon Aug  5 11:14:05 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 5 Aug 2024 11:14:05 GMT
Subject: RFR: 8336856: Optimize String Concat [v30]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <yM7dFDD36OcnhhI2swYW3slO8bftzbPsBSHQOzI9hvQ=.2a4a38e4-c0b1-456c-83de-c2ba34c6549e@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 93 commits:

 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
 - revert simplify prepend
 - simplify prepend & code style
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
 - Update src/java.base/share/classes/java/lang/StringConcatHelper.java
   
   Co-authored-by: David Schlosnagle <schlosna at gmail.com>
 - copyright
 - add comments & code style & make code clear
 - add comments and make code clear
 - fix comments and reduce code size of generated methods
 - 1. split length & coder & prepend method
   2. fix comment
   3. change forceInlineThreshold to 16
   4. 1 arg use built-in method
   5. add tests
 - ... and 83 more: https://git.openjdk.org/jdk/compare/be34730f...726b9ad8

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

Changes: https://git.openjdk.org/jdk/pull/20273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=29
  Stats: 1259 lines in 7 files changed: 1135 ins; 32 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From viktor.klang at oracle.com  Mon Aug  5 11:26:10 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 5 Aug 2024 11:26:10 +0000
Subject: [External] : Gatherers -- windowBy
In-Reply-To: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>
References: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>
Message-ID: <MW4PR10MB57746C1EF26FFEBD809F08F6FFBE2@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

Thank you for the write-up?sharing your experience with us.

I'm happy you've had much success with `windowBy`, and we're going to have to wait and see what other feedback on Gatherers and potential unmet needs in the roster of baked-in Gatherers.

Gatherers is scheduled to have a second preview in Java 23, in order to give users a chance to try it out and share their experience.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Sunday, 4 August 2024 09:14
To: core-libs-dev <core-libs-dev at openjdk.org>
Cc: Remi Forax <forax at univ-mlv.fr>; Viktor Klang <viktor.klang at oracle.com>
Subject: [External] : Gatherers -- windowBy

Hello Core Libs Dev Team,

Apologies for the massive delay. I have been juggling many severe personal emergencies, and thus, did not have time or strength to follow up on the previous thread -- https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html

As mentioned in my previous thread, I have been extremely happy with the new Gatherers API, and have found numerous uses for it.

I did want to add one addition to the list of premade gatherers provided by the standard library in java.util.stream.Gatherers API -- a windowBy gatherer.

The result of the thread was that, while the feature had nothing wrong with it, evidence needed to be provided of its utility. This email is that evidence. Specifically, this email is providing all of the situations where I used this windowBy Gatherer that Viktor Klang made for me, with the hope that it is strong enough evidence to push this method into the Gatherers API.

Here we go.

  1.  Advent of Code 2020 -- Day 14 [1] -- and here is my code [2] -- here is a link to the line that actually used the gatherer [3]
     *   This cleaned up my solution CONSIDERABLY. If I was doing this with for loops, I would have to do index manipulation to jump ahead my for loop index wise. Here, all I am doing is telling it how to split apart the stream. Way more clear and elegant. Which was critical because this AOC day was extremely difficult for me. Solution is not yet done, but making great progress.
  2.  Service Health Analytics -- Work project, so I can't share the code
     *   This was a super basic use case, but long story short, I'm tracing down yet another network issue, and I wanted to know what was occurring before the network outage, to see if there was a correlation. I ended up scrapping this solution in favor of another one, but I was quite happy with how easy the Gatherer made it to grab exactly what I wanted. It was just a windowBy followed by a sliding window, and then extracting some info by comparing the 2 chunks.
  3.  Typing Metrics [4] -- here is the link to the method that uses the Gatherer [5]
     *   This is where I really put the Gatherer through its paces. I had some semi-complex examples, but I got them all to work out well. It made my logic simpler than the imperative equivalent, while also keeping things concise. Now, one point that caused me some difficulty was recognizing that the Gatherer has a surprisingly large number of edge cases. For example, when looking at the data in aggregate, you notice a pattern -- the first element of every window is the FALSE case of your predicate, while all remaining members of that window are the TRUE case of the predicate. However, it's very possible for the first window to be a single element TRUE case window. I think this is the first time I found a valid use for the Stream::dropWhile method lol. But otherwise, this feature REALLY helped me move forward, and I am very happy with it!

My biggest takeaway from using this Gatherer is that, when dealing with a Stream of events that you want to get metrics of, this gatherer is going to be a critical tool in the arsenal. This Gatherer also pairs BEAUTIFULLY with slidingWindow, to where I feel it made sliding window even stronger. I break up my stream into chunks using the windowBy, then slide over those chunks using sliding window. I kept finding myself using this strategy to aggregate and analyze. To use an analogy, it feels almost like making a database view of a larger database table.

This is my experience using the windowBy Gatherer that Viktor Klang gave me. Please let me know if there are any questions, comments, or concerns.

Thank you for your time, patience, and understanding!
David Alayachew

[1] = https://adventofcode.com/2020/day/14<https://urldefense.com/v3/__https://adventofcode.com/2020/day/14__;!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1j6kToUsc$>
[2] = https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L334<https://urldefense.com/v3/__https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java*L334__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jakXmB9k$>
[3] = https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L468<https://urldefense.com/v3/__https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java*L468__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jWHufk2U$>
[4] = https://github.com/davidalayachew/HowFastCanYouType<https://urldefense.com/v3/__https://github.com/davidalayachew/HowFastCanYouType__;!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jOKot3vY$>
[5] = https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java#L151<https://urldefense.com/v3/__https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java*L151__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jXX46EYs$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240805/4650436d/attachment-0001.htm>

From rgiulietti at openjdk.org  Mon Aug  5 15:03:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 5 Aug 2024 15:03:31 GMT
Subject: RFR: 8337712: Wrong javadoc in java.util.Date#toString(): "61" and
 right parenthesis
In-Reply-To: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
References: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
Message-ID: <QEVt0NzBtt_y7ENuRRq7JnOU3hQArVaPIroLsHDls6c=.10b34286-6428-4e86-ae84-d753b3a04778@github.com>

On Fri, 2 Aug 2024 07:20:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to add a missing parenthesis in `java.util.Date::toString`.

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20439#pullrequestreview-2219235940

From pminborg at openjdk.org  Mon Aug  5 15:09:39 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 5 Aug 2024 15:09:39 GMT
Subject: Integrated: 8337712: Wrong javadoc in java.util.Date#toString(): "61"
 and right parenthesis
In-Reply-To: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
References: <No1E3vGGpKf8ioJlwMl1y9RKMzkrU6vcqI6e312YZ7A=.7200a459-672d-4f8f-8519-c670a45ca4c7@github.com>
Message-ID: <qleY1kgJDvcdByuVqGW5O03YVBZb3wxM4YpQEdFbCn4=.2bb20125-3b7e-485b-84a8-7d3b341b98fd@github.com>

On Fri, 2 Aug 2024 07:20:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to add a missing parenthesis in `java.util.Date::toString`.

This pull request has now been integrated.

Changeset: 219e1eb1
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/219e1eb13a688532705e603e276799c0157f5f28
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8337712: Wrong javadoc in java.util.Date#toString(): "61" and right parenthesis

Reviewed-by: rgiulietti

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

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

From ihse at openjdk.org  Mon Aug  5 15:22:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:22:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
Message-ID: <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>

On Fri, 26 Jul 2024 19:40:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

make/modules/java.base/lib/CoreLibraries.gmk line 57:

> 55:     OPTIMIZATION := HIGH, \
> 56:     EXTRA_HEADER_DIRS := \
> 57:         libnio/ch, \

This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this. 

Maybe the libnio/ch code also should move to libjava? Or, perhaps at least the header files. Conceptually, I'd feel better about having a dependency on libnio as a "downstream" library on libjava source code, than the other way around.

make/modules/java.base/lib/CoreLibraries.gmk line 71:

> 69:         -framework Foundation \
> 70:         -framework SystemConfiguration, \
> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \

Please keep libraries alphabetically sorted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704283438
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704283936

From bpb at openjdk.org  Mon Aug  5 15:40:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Aug 2024 15:40:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
 <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
Message-ID: <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>

On Mon, 5 Aug 2024 15:19:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this.

I'll look into improving it.

> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \
> 
> Please keep libraries alphabetically sorted.

Thanks for pointing this out; I will fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704310018
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1704310460

From duke at openjdk.org  Mon Aug  5 18:09:05 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 5 Aug 2024 18:09:05 GMT
Subject: RFR: 8337832: Optimize datetime toString
Message-ID: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>

Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

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

Commit messages:
 - copyright
 - use var
 - Update src/java.base/share/classes/java/time/ZonedDateTime.java
 - refactor datetime to string

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

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

From liach at openjdk.org  Mon Aug  5 18:09:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 Aug 2024 18:09:05 GMT
Subject: RFR: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <3s2mQgV_sZOlihJZBw-omD-lNaBDwo8JcTKGszvIsc8=.a649575d-e1c7-42e4-ab68-752a5a7fc57a@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

src/java.base/share/classes/java/time/ZonedDateTime.java line 2222:

> 2220:         if (offset != zone) {
> 2221:             zoneStr = zone.toString();
> 2222:             length += zoneStr.length();

Suggestion:

            length += zoneStr.length() + 2;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20368#discussion_r1693963178

From aturbanov at openjdk.org  Mon Aug  5 19:59:40 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Aug 2024 19:59:40 GMT
Subject: RFR: 8337838: Remove unused methods from ChronoLocalDateImpl
Message-ID: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>

A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could be removed:
1. plusWeeks(long)
2. minusYears(long)
3. minusMonths(long)
4. minusWeeks(long)
5. minusDays(long)

Tested `test/jdk/java/time` on Linux x64 release

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

Commit messages:
 - [PATCH] Remove unused methods from ChronoLocalDateImpl

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

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

From aturbanov at openjdk.org  Mon Aug  5 20:03:00 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Aug 2024 20:03:00 GMT
Subject: RFR: 8337839: Make a few fields in MergeCollation static
Message-ID: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>

3 fields in java.text.MergeCollation could be made 'static':
1. BITARRAYMASK
2. BYTEPOWER
3. BYTEMASK

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

Commit messages:
 - [PATCH] Make a few fields in MergeCollation static

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

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

From aturbanov at openjdk.org  Mon Aug  5 20:07:00 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 5 Aug 2024 20:07:00 GMT
Subject: RFR: 8337840: Remove redundant null check in
 ObjectOutputStream.writeProxyDesc
Message-ID: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>

There is implicit null check in line before.

https://github.com/openjdk/jdk/blob/431d4f7e18369466eedd00926a5162a1461d0b25/src/java.base/share/classes/java/io/ObjectOutputStream.java#L1267-L1277

'cl' can't be null after that.

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

Commit messages:
 - [PATCH] Remove redundant null check in ObjectOutputStream.writeProxyDesc

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

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

From duke at openjdk.org  Mon Aug  5 23:42:08 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 5 Aug 2024 23:42:08 GMT
Subject: RFR: 8336856: Optimize String Concat [v31]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <IXhASm7jVtP9ji724GEEWG2mdrXf_2VtwvH-_GCrLwM=.e762d15a-344c-43d3-bd58-13f7ef83e470@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/726b9ad8..31b4fbc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=29-30

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

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

From naoto at openjdk.org  Tue Aug  6 00:57:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Aug 2024 00:57:14 GMT
Subject: RFR: 8337603: Change in behavior with
 -Djava.locale.useOldISOCodes=true
Message-ID: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>

Fixing a regression caused by the removal of the legacy locale data. Legacy locale data happened to have resource bundle for "he" language (new ISO code) with the launguage name for "iw" (old ISO code). CLDR does not have it, thus the name fell back to English.

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

Commit messages:
 - initial commit

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

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

From alanb at openjdk.org  Tue Aug  6 03:04:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Aug 2024 03:04:33 GMT
Subject: RFR: 8337506: Disable "best-fit" mapping on Windows command line
 [v2]
In-Reply-To: <lrmHPqEaVTEL0ryiFfzyicQHabtXwY17TdY6PSoZ-oQ=.d9f80244-96a3-4aa7-8934-8c886a125937@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
 <lrmHPqEaVTEL0ryiFfzyicQHabtXwY17TdY6PSoZ-oQ=.d9f80244-96a3-4aa7-8934-8c886a125937@github.com>
Message-ID: <8k86DRUwJKoJkUKDd_aIabSEFHn0e_nD-sM83-ZT2ic=.f1981a6f-23ca-4411-b655-658b4b15c3ca@github.com>

On Fri, 2 Aug 2024 18:40:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the Java launcher's command line argument parsing issue on Windows. The Java launcher on Windows has been using `GetCommandLineA()` to obtain arguments, which by default does "best-fit" mapping when the arguments are converted to ANSI code page encoding. By disabling this "best-fit" mapping, the launcher's parsing works as expected. A corresponding CSR has been drafted for the behavioral change.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment for the error case

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20428#pullrequestreview-2220183865

From jpai at openjdk.org  Tue Aug  6 04:20:35 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Aug 2024 04:20:35 GMT
Subject: RFR: 8337840: Remove redundant null check in
 ObjectOutputStream.writeProxyDesc
In-Reply-To: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
References: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
Message-ID: <B2-oJE5ILspeyJXeWArLI0q168wVSH4TuEVXXSFcRUk=.8c454790-91e3-477e-a8af-7af7d58cd329@github.com>

On Fri, 26 Jul 2024 13:09:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is implicit null check in line before.
> 
> https://github.com/openjdk/jdk/blob/431d4f7e18369466eedd00926a5162a1461d0b25/src/java.base/share/classes/java/io/ObjectOutputStream.java#L1267-L1277
> 
> 'cl' can't be null after that.

That null check appears to have been added as part of https://mail.openjdk.org/pipermail/core-libs-dev/2014-April/026379.html. The change in that previous commit introduced 2 null checks - one in `writeProxyDesc()` and one in `writeNonProxyDesc()`. The null check added in `writeProxyDesc()` appears to be a copy/paste issue and as you note that null check essentially is a no-op because the `cl` has already been dereferenced a few lines above. Removing this redundant null check seems OK to me. 

Having said that, I think we might have to consider if that null check needs to be moved just after the call to `desc.forClass()`. Apparently that call is allowed to return null (which is what prompted the original commit).

I would wait for Roger or someone more familiar with this area to recommend what needs to be done here.

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

PR Comment: https://git.openjdk.org/jdk/pull/20351#issuecomment-2270349946

From jpai at openjdk.org  Tue Aug  6 04:42:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Aug 2024 04:42:31 GMT
Subject: RFR: 8337839: Make a few fields in MergeCollation static
In-Reply-To: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>
References: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>
Message-ID: <_WAm54AYROArcYDbr031lKwhTfm_r_92EzL_ijHSym4=.8ecfdd46-476c-428f-a600-70d6dcff4b14@github.com>

On Thu, 25 Jul 2024 08:59:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in java.text.MergeCollation could be made 'static':
> 1. BITARRAYMASK
> 2. BYTEPOWER
> 3. BYTEMASK

Looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20323#pullrequestreview-2220261608

From iris at openjdk.org  Tue Aug  6 06:56:35 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 6 Aug 2024 06:56:35 GMT
Subject: RFR: 8337603: Change in behavior with
 -Djava.locale.useOldISOCodes=true
In-Reply-To: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
References: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
Message-ID: <x6O8DjBNBAx-uXK92gfcsDaD2NWKgK8xoduVDvuuPf8=.9e0cc58e-e861-4c98-af65-cb3f625109b0@github.com>

On Tue, 6 Aug 2024 00:50:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the removal of the legacy locale data. Legacy locale data happened to have resource bundle for "he" language (new ISO code) with the launguage name for "iw" (old ISO code). CLDR does not have it, thus the name fell back to English.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20474#pullrequestreview-2220431354

From jlahoda at openjdk.org  Tue Aug  6 09:10:38 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 6 Aug 2024 09:10:38 GMT
Subject: Integrated: 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: <ffnKuVh6XLGqSZLMmyuFR-X6odfpBa0oXqOjjBiSPX4=.aa9ef213-98b1-49df-85bf-3a6036b647dc@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  ...

This pull request has now been integrated.

Changeset: 958786b2
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/958786b28ffb532b38746640b6fc11242f056ad9
Stats:     197 lines in 2 files changed: 158 ins; 19 del; 20 mod

8332522: SwitchBootstraps::mappedEnumLookup constructs unused array

Reviewed-by: liach, redestad

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

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

From duke at openjdk.org  Tue Aug  6 14:10:58 2024
From: duke at openjdk.org (Turkhan)
Date: Tue, 6 Aug 2024 14:10:58 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
Message-ID: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>

This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.

Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

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

Commit messages:
 - 8337205: Set Deque's peekFirst() method as equivalent to Stack's peek() method in the doc

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

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

From pminborg at openjdk.org  Tue Aug  6 14:10:58 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 6 Aug 2024 14:10:58 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
Message-ID: <zaPvUgWlG5fzfHLGywnRqWIqj0d9JtWKIUTi0YdxRVc=.63e7a9e0-3c7b-4609-8f14-91e7078a6b96@github.com>

On Fri, 26 Jul 2024 21:06:31 GMT, Turkhan <duke at openjdk.org> wrote:

> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
> 
> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

Thanks for taking a look at this @tbadalov and sorry for the slow progress of OCA.

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

PR Comment: https://git.openjdk.org/jdk/pull/20363#issuecomment-2270511250

From duke at openjdk.org  Tue Aug  6 14:10:59 2024
From: duke at openjdk.org (Turkhan)
Date: Tue, 6 Aug 2024 14:10:59 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <zaPvUgWlG5fzfHLGywnRqWIqj0d9JtWKIUTi0YdxRVc=.63e7a9e0-3c7b-4609-8f14-91e7078a6b96@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
 <zaPvUgWlG5fzfHLGywnRqWIqj0d9JtWKIUTi0YdxRVc=.63e7a9e0-3c7b-4609-8f14-91e7078a6b96@github.com>
Message-ID: <SQcwyuBBYGC8QUhwGQL5a_P4d8PL6NL5yAHqsWefb_w=.56381f70-ceda-4a83-8b90-af828639c19d@github.com>

On Tue, 6 Aug 2024 06:48:52 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
>> 
>> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.
>
> Thanks for taking a look at this @tbadalov and sorry for the slow progress of OCA.

Thanks for the follow-up, @minborg! Glad that it is in progress

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

PR Comment: https://git.openjdk.org/jdk/pull/20363#issuecomment-2270903840

From bpb at openjdk.org  Tue Aug  6 15:21:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 Aug 2024 15:21:31 GMT
Subject: RFR: 8337603: Change in behavior with
 -Djava.locale.useOldISOCodes=true
In-Reply-To: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
References: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
Message-ID: <qxJqS60bfJMiFJoB1pETimM62mDNjOsmnvsPyaD26cc=.36d6d99e-537a-4fb6-a93a-f3bf0ae73f1d@github.com>

On Tue, 6 Aug 2024 00:50:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the removal of the legacy locale data. Legacy locale data happened to have resource bundle for "he" language (new ISO code) with the launguage name for "iw" (old ISO code). CLDR does not have it, thus the name fell back to English.

Looks all right.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20474#pullrequestreview-2221616419

From duke at openjdk.org  Tue Aug  6 17:01:11 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 6 Aug 2024 17:01:11 GMT
Subject: RFR: 8336856: Optimize String Concat [v32]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <rOePrxddGUjIyfC8eIvaBhoQWVTsAujJ6pv-S281Mkc=.15b855d7-74d3-4c84-b67f-0cd12be161db@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  fix comments & code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/31b4fbc1..aedc30c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=30-31

  Stats: 35 lines in 1 file changed: 12 ins; 5 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From redestad at openjdk.org  Tue Aug  6 17:32:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Aug 2024 17:32:35 GMT
Subject: RFR: 8336856: Optimize String Concat [v32]
In-Reply-To: <rOePrxddGUjIyfC8eIvaBhoQWVTsAujJ6pv-S281Mkc=.15b855d7-74d3-4c84-b67f-0cd12be161db@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <rOePrxddGUjIyfC8eIvaBhoQWVTsAujJ6pv-S281Mkc=.15b855d7-74d3-4c84-b67f-0cd12be161db@github.com>
Message-ID: <BEeM7eyau6NRxGbi7SSeQauNa1quUVbjU0QMCPOJTB8=.359eb41d-d063-4722-9f8c-a9dca84f5ba4@github.com>

On Tue, 6 Aug 2024 17:01:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments & code style

Did some debugging and I think this should be sufficient to resolve the WithSecurityManager test failure:


diff --git a/src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java b/src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java
index afb3d1374ab..fa47428d113 100644
--- a/src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java
+++ b/src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java
@@ -80,7 +80,7 @@ public static ClassFileDumper getInstance(String key, String path) {
     private final AtomicInteger counter = new AtomicInteger();

     private ClassFileDumper(String key, String path) {
-        String value = GetPropertyAction.privilegedGetProperty(key);
+        String value = VM.getSavedProperty(key);
         this.key = key;
         boolean enabled = value != null && value.isEmpty() ? true : Boolean.parseBoolean(value);
         if (enabled) {

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2271794247

From duke at openjdk.org  Tue Aug  6 17:43:08 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 6 Aug 2024 17:43:08 GMT
Subject: RFR: 8336856: Optimize String Concat [v33]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <MawwRLlJMpP7_3Iwdtbpzt918UQrrkVRloQXwYoUzKY=.09f06998-e6f7-40ac-9ff1-e5d1c3e7fb7e@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  resolve the WithSecurityManager test failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/aedc30c6..68b00c3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=31-32

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

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

From duke at openjdk.org  Tue Aug  6 18:07:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 6 Aug 2024 18:07:16 GMT
Subject: RFR: 8336856: Optimize String Concat [v34]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - copyright
 - remove unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/68b00c3c..adc12ade

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=32-33

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

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

From rriggs at openjdk.org  Tue Aug  6 18:47:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Aug 2024 18:47:33 GMT
Subject: RFR: 8336043: Add quality of implementation discussion to
 Object.{equals, toString, hashCode} [v4]
In-Reply-To: <ttwXfIJXaWA1cTd5y8k760Gn55zrGcobkv1mG_gHp1c=.2b87abfe-ae40-4652-8492-9fffdfeb646b@github.com>
References: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
 <ttwXfIJXaWA1cTd5y8k760Gn55zrGcobkv1mG_gHp1c=.2b87abfe-ae40-4652-8492-9fffdfeb646b@github.com>
Message-ID: <8qYsj8zwOvd1FVZ-IKi9i-flI0foLKd92bZPsd4893g=.1dd1f216-f69f-4b94-8edf-4c022d1c36db@github.com>

On Wed, 31 Jul 2024 01:46:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> First pass at adding some quality of implementation discussions around the overridable methods of Object.
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8336043
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8336043
>  - Appease jcheck.
>  - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

src/java.base/share/classes/java/lang/Object.java line 125:

> 123:      * collections}.
> 124:      *
> 125:      * As as a quality of implementation concern, a particular

"As as" typo.
"particular" is unnecessary.  "a" -> "an"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1705969830

From duke at openjdk.org  Tue Aug  6 19:28:40 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 6 Aug 2024 19:28:40 GMT
Subject: RFR: 8336856: Optimize String Concat [v34]
In-Reply-To: <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>
Message-ID: <hiMZbCPGVJ_0ytnT6Eyw6LLkm0DCgVd60sa3r-tIUjE=.5cfba66a-3d89-4382-a2bc-d8917a010475@github.com>

On Tue, 6 Aug 2024 18:07:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright
>  - remove unused import

https://github.com/wenshao/jdk/actions/runs/10271363457

Thanks to @cl4es for the patch, I created a branch with highArity set to the default value of 0, and it can be built successfully.

Next we can do two things:
1. SimpleStringBuilderStrategy or need to change a name, now it is not using StringBuilder
2. Change the default value of highArity to 0

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2271990852

From rriggs at openjdk.org  Tue Aug  6 19:48:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Aug 2024 19:48:31 GMT
Subject: RFR: 8337838: Remove unused methods from ChronoLocalDateImpl
In-Reply-To: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
References: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
Message-ID: <v2_ftdNDMtQnEN5aIact3U-bNpxz3eAR30xZb4uGBzA=.5d80b2b8-b9a3-4a42-9eaa-04066c4e4544@github.com>

On Fri, 19 Jul 2024 09:52:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could be removed:
> 1. plusWeeks(long)
> 2. minusYears(long)
> 3. minusMonths(long)
> 4. minusWeeks(long)
> 5. minusDays(long)
> 
> Tested `test/jdk/java/time` on Linux x64 release

The methods should not be removed, they provide default implementation, even though subclasses define overridden implementations.
Please close this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20250#issuecomment-2272023547

From naoto at openjdk.org  Tue Aug  6 20:14:39 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 Aug 2024 20:14:39 GMT
Subject: Integrated: 8337506: Disable "best-fit" mapping on Windows command
 line
In-Reply-To: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
References: <ghHujqX87UyRg1UpWicfqejUcrjysoWg_-NDsgAdBpE=.e471f9b8-3879-4007-ac11-67a2d3f8e9a9@github.com>
Message-ID: <3syZKoNGaS6dMkAIOTm_WvKzv9GEmoKY7X_1X3kJwmg=.2401ac3e-82b2-4f46-8b96-46d1906d7696@github.com>

On Thu, 1 Aug 2024 17:21:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the Java launcher's command line argument parsing issue on Windows. The Java launcher on Windows has been using `GetCommandLineA()` to obtain arguments, which by default does "best-fit" mapping when the arguments are converted to ANSI code page encoding. By disabling this "best-fit" mapping, the launcher's parsing works as expected. A corresponding CSR has been drafted for the behavioral change.

This pull request has now been integrated.

Changeset: ff634a96
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff634a967027cfa56b666d31c45db9a4acc09ea4
Stats:     103 lines in 2 files changed: 101 ins; 0 del; 2 mod

8337506: Disable "best-fit" mapping on Windows command line

Reviewed-by: alanb

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

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

From davidalayachew at gmail.com  Tue Aug  6 21:21:08 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 6 Aug 2024 17:21:08 -0400
Subject: [External] : Gatherers -- windowBy
In-Reply-To: <MW4PR10MB57746C1EF26FFEBD809F08F6FFBE2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>
 <MW4PR10MB57746C1EF26FFEBD809F08F6FFBE2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_M-vDy2CqTySZ+gdo2bH5L_LSUjKBW6TMFmXVH=zVg2kA@mail.gmail.com>

Thanks. I am going to use it a lot more. If I get more examples, should I
post a follow up? Or leave it for others to jump in?

On Mon, Aug 5, 2024, 7:26?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi David,
>
> Thank you for the write-up?sharing your experience with us.
>
> I'm happy you've had much success with `windowBy`, and we're going to have
> to wait and see what other feedback on Gatherers and potential unmet needs
> in the roster of baked-in Gatherers.
>
> Gatherers is scheduled to have a second preview in Java 23, in order to
> give users a chance to try it out and share their experience.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Sunday, 4 August 2024 09:14
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Cc:* Remi Forax <forax at univ-mlv.fr>; Viktor Klang <
> viktor.klang at oracle.com>
> *Subject:* [External] : Gatherers -- windowBy
>
> Hello Core Libs Dev Team,
>
> Apologies for the massive delay. I have been juggling many severe personal
> emergencies, and thus, did not have time or strength to follow up on the
> previous thread --
> https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html
>
> As mentioned in my previous thread, I have been extremely happy with the
> new Gatherers API, and have found numerous uses for it.
>
> I did want to add one addition to the list of premade gatherers provided
> by the standard library in java.util.stream.Gatherers API -- a windowBy
> gatherer.
>
> The result of the thread was that, while the feature had nothing wrong
> with it, evidence needed to be provided of its utility. This email is that
> evidence. Specifically, this email is providing all of the situations where
> I used this windowBy Gatherer that Viktor Klang made for me, with the hope
> that it is strong enough evidence to push this method into the Gatherers
> API.
>
> Here we go.
>
>    1. Advent of Code 2020 -- Day 14 [1] -- and here is my code [2] --
>    here is a link to the line that actually used the gatherer [3]
>    1. This cleaned up my solution CONSIDERABLY. If I was doing this with
>       for loops, I would have to do index manipulation to jump ahead my for loop
>       index wise. Here, all I am doing is telling it how to split apart the
>       stream. Way more clear and elegant. Which was critical because this AOC day
>       was extremely difficult for me. Solution is not yet done, but making great
>       progress.
>       2. Service Health Analytics -- Work project, so I can't share the
>    code
>       1. This was a super basic use case, but long story short, I'm
>       tracing down yet another network issue, and I wanted to know what was
>       occurring before the network outage, to see if there was a correlation. I
>       ended up scrapping this solution in favor of another one, but I was quite
>       happy with how easy the Gatherer made it to grab exactly what I wanted. It
>       was just a windowBy followed by a sliding window, and then extracting some
>       info by comparing the 2 chunks.
>       3. Typing Metrics [4] -- here is the link to the method that uses
>    the Gatherer [5]
>    1. This is where I really put the Gatherer through its paces. I had
>       some semi-complex examples, but I got them all to work out well. It made my
>       logic simpler than the imperative equivalent, while also keeping things
>       concise. Now, one point that caused me some difficulty was recognizing that
>       the Gatherer has a surprisingly large number of edge cases. For example,
>       when looking at the data in aggregate, you notice a pattern -- the first
>       element of every window is the FALSE case of your predicate, while all
>       remaining members of that window are the TRUE case of the predicate.
>       However, it's very possible for the first window to be a single element
>       TRUE case window. I think this is the first time I found a valid use for
>       the Stream::dropWhile method lol. But otherwise, this feature REALLY helped
>       me move forward, and I am very happy with it!
>
> My biggest takeaway from using this Gatherer is that, when dealing with a
> Stream of events that you want to get metrics of, this gatherer is going to
> be a critical tool in the arsenal. This Gatherer also pairs BEAUTIFULLY
> with slidingWindow, to where I feel it made sliding window even stronger. I
> break up my stream into chunks using the windowBy, then slide over those
> chunks using sliding window. I kept finding myself using this strategy to
> aggregate and analyze. To use an analogy, it feels almost like making a
> database view of a larger database table.
>
> This is my experience using the windowBy Gatherer that Viktor Klang gave
> me. Please let me know if there are any questions, comments, or concerns.
>
> Thank you for your time, patience, and understanding!
> David Alayachew
>
> [1] = https://adventofcode.com/2020/day/14
> <https://urldefense.com/v3/__https://adventofcode.com/2020/day/14__;!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1j6kToUsc$>
> [2] =
> https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L334
> <https://urldefense.com/v3/__https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java*L334__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jakXmB9k$>
> [3] =
> https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L468
> <https://urldefense.com/v3/__https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java*L468__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jWHufk2U$>
> [4] = https://github.com/davidalayachew/HowFastCanYouType
> <https://urldefense.com/v3/__https://github.com/davidalayachew/HowFastCanYouType__;!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jOKot3vY$>
> [5] =
> https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java#L151
> <https://urldefense.com/v3/__https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java*L151__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jXX46EYs$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240806/6a56e215/attachment.htm>

From redestad at openjdk.org  Tue Aug  6 21:53:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Aug 2024 21:53:35 GMT
Subject: RFR: 8336856: Optimize String Concat [v34]
In-Reply-To: <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>
Message-ID: <wwI9bYaYT56OK-tfpZcQThTQ3nUv7cFJHXkFH6ZoEOM=.5de0deb6-8e2e-4c5d-abbf-cfbbd8e927f5@github.com>

On Tue, 6 Aug 2024 18:07:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright
>  - remove unused import

Yes, I'd suggest: 
- Rename `SimpleStringBuilderStrategy` to something like `InlineHiddenClassStrategy`.
- Change the default value of `highArity` to 0
- Adding a `inlineThreshold` parameter to control the now hard-coded inlining threshold

The only thing I'd really like to see after that is a test to verify that unloading of the hidden concat classes works. 

We should probably keep the existing strategy around for a while. At least until the new strategy has gone through extensive testing. Looking forward to the code cleanup removing it will entail, though.

On a review side note I see some opportunity to fine-tune the code a bit. For example:
- we could prefer generating and passing around `MethodTypeDesc` instead of `MethodType` to reduce transforms
- refactor to not generate `coderArgs` unless needed
- use more idiomatic class-file API code: `cb.parameterSlot(int)` instead of allocating `int[] paramSlots` arrays and calculating slows, use `cb.allocateLocal` etc..

Such micro-optimization/cleanup work probably isn't going to significantly change characteristics and could be deferred to a follow-up.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2272211492

From redestad at openjdk.org  Tue Aug  6 22:55:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 6 Aug 2024 22:55:37 GMT
Subject: RFR: 8336856: Optimize String Concat [v34]
In-Reply-To: <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <KbPRohWFk-Yta3jGsLfwscGLZ_4qzhMeZ2GDYUj_MTQ=.a5806198-2ef4-4b16-bf77-414b4afcb38b@github.com>
Message-ID: <ljF_APwpfOZGKYX2dVYDAxp5Qt7EVgoS3JayZk57nfs=.6d628bab-0826-4ee0-b972-68b731f4de57@github.com>

On Tue, 6 Aug 2024 18:07:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright
>  - remove unused import

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1591:

> 1589:                             }
> 1590:                             cb.loadLocal(kind, nextSlot)
> 1591:                               .invokestatic(CD_StringConcatHelper, "stringSize", methodTypeDesc);

The approach here isn't checking for overflow at all, deferring to the length check in the newArray step. While current tests all pass with this I think we need to maintain checking for overflow as we go, otherwise it'd be possible to construct concatenations where the length overflows to negative and then back again to positive. Let's try this with a new set of `mix` methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1706191966

From duke at openjdk.org  Tue Aug  6 23:41:09 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 6 Aug 2024 23:41:09 GMT
Subject: RFR: 8336856: Optimize String Concat [v35]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <5WQdJK8A8XXfs7RCS2jh54oMNXXhjC620UMNeAWcjVU=.5288b0bb-1eae-4865-b6a8-7cbd2a2efd2b@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with six additional commits since the last revision:

 - checkOverflow
 - highArity default 0
 - use MethodTypeDesc instead of MethodType
 - inlineThreshold parameter
 - use more idiomatic class-file API
 - rename SimpleStringBuilderStrategy to InlineHiddenClassStrategy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/adc12ade..65a16e41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=33-34

  Stats: 129 lines in 2 files changed: 18 ins; 25 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From duke at openjdk.org  Tue Aug  6 23:49:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 6 Aug 2024 23:49:36 GMT
Subject: RFR: 8336856: Optimize String Concat [v35]
In-Reply-To: <5WQdJK8A8XXfs7RCS2jh54oMNXXhjC620UMNeAWcjVU=.5288b0bb-1eae-4865-b6a8-7cbd2a2efd2b@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <5WQdJK8A8XXfs7RCS2jh54oMNXXhjC620UMNeAWcjVU=.5288b0bb-1eae-4865-b6a8-7cbd2a2efd2b@github.com>
Message-ID: <niAqRrg5XYGLKEofD_3FUpgiEzG90heiA38sZCy36pc=.590c1b3f-3b6d-4a8a-92bb-117725c41223@github.com>

On Tue, 6 Aug 2024 23:41:09 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - checkOverflow
>  - highArity default 0
>  - use MethodTypeDesc instead of MethodType
>  - inlineThreshold parameter
>  - use more idiomatic class-file API
>  - rename SimpleStringBuilderStrategy to InlineHiddenClassStrategy

1. `refactor to not generate coderArgs unless needed. ` Is this what you want?
https://github.com/wenshao/jdk/commit/d64552e247beca3f3241f20d5147ad62250dd06b

2. concatArgs still uses MethodType. There is no extra transformation here, so we will not change it for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2272351590

From darcy at openjdk.org  Wed Aug  7 00:02:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Aug 2024 00:02:46 GMT
Subject: RFR: 8336043: Add quality of implementation discussion to
 Object.{equals, toString, hashCode} [v5]
In-Reply-To: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
References: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
Message-ID: <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>

> First pass at adding some quality of implementation discussions around the overridable methods of Object.

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

 - Fix typo found in code review.
 - Merge branch 'master' into JDK-8336043
 - Merge branch 'master' into JDK-8336043
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8336043
 - Appease jcheck.
 - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20128/files
  - new: https://git.openjdk.org/jdk/pull/20128/files/80cabee0..840ee4f2

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

  Stats: 9191 lines in 323 files changed: 4525 ins; 3108 del; 1558 mod
  Patch: https://git.openjdk.org/jdk/pull/20128.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20128/head:pull/20128

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

From redestad at openjdk.org  Wed Aug  7 00:07:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 7 Aug 2024 00:07:36 GMT
Subject: RFR: 8336856: Optimize String Concat [v35]
In-Reply-To: <5WQdJK8A8XXfs7RCS2jh54oMNXXhjC620UMNeAWcjVU=.5288b0bb-1eae-4865-b6a8-7cbd2a2efd2b@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <5WQdJK8A8XXfs7RCS2jh54oMNXXhjC620UMNeAWcjVU=.5288b0bb-1eae-4865-b6a8-7cbd2a2efd2b@github.com>
Message-ID: <yXabv1e1y17npCJfhwAth1lzWs4vtFPyMIxdFLkxxaM=.0df70e5a-1755-4383-bab6-048eb3b2a5e5@github.com>

On Tue, 6 Aug 2024 23:41:09 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - checkOverflow
>  - highArity default 0
>  - use MethodTypeDesc instead of MethodType
>  - inlineThreshold parameter
>  - use more idiomatic class-file API
>  - rename SimpleStringBuilderStrategy to InlineHiddenClassStrategy

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1584:

> 1582:                         }
> 1583:                         cb.iadd()
> 1584:                           .invokestatic(CD_StringConcatHelper, "checkOverflow", MTD_int_int);

Good, but wouldn't we generate slightly more compact code if this check was baked into the `stringSize` (when we call that) and only emitted in this generated for `char` parameters?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1706229674

From duke at openjdk.org  Wed Aug  7 00:58:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 7 Aug 2024 00:58:26 GMT
Subject: RFR: 8336856: Optimize String Concat [v36]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <ZB7QbRpr_WZLNfd7n22PDfn731yP0swaTOQKg4XjYiw=.2b9c47fc-969f-45b8-98df-2d2898dd4281@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  refactor checkOverflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/65a16e41..afca6a4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=34-35

  Stats: 72 lines in 2 files changed: 21 ins; 12 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From duke at openjdk.org  Wed Aug  7 03:38:09 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 7 Aug 2024 03:38:09 GMT
Subject: RFR: 8336856: Optimize String Concat [v37]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <QSfru8_jSURAY1leir0xEWETEx-s8xjpiLZXuSBX814=.7c960895-3c11-4c0d-abca-c47c0b39125c@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  1. not generate coderArgs unless needed
  2. code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/afca6a4e..b260874a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=35-36

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

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

From aturbanov at openjdk.org  Wed Aug  7 05:57:34 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 7 Aug 2024 05:57:34 GMT
Subject: RFR: 8337838: Remove unused methods from ChronoLocalDateImpl
In-Reply-To: <v2_ftdNDMtQnEN5aIact3U-bNpxz3eAR30xZb4uGBzA=.5d80b2b8-b9a3-4a42-9eaa-04066c4e4544@github.com>
References: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
 <v2_ftdNDMtQnEN5aIact3U-bNpxz3eAR30xZb4uGBzA=.5d80b2b8-b9a3-4a42-9eaa-04066c4e4544@github.com>
Message-ID: <YWp7KM1IumPb327RguXeFsZk3ktAVJPpXmWL2A4O85c=.c9f6f177-acd1-4c3f-9b6c-cad2325f5eed@github.com>

On Tue, 6 Aug 2024 19:46:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could be removed:
>> 1. plusWeeks(long)
>> 2. minusYears(long)
>> 3. minusMonths(long)
>> 4. minusWeeks(long)
>> 5. minusDays(long)
>> 
>> Tested `test/jdk/java/time` on Linux x64 release
>
> The methods should not be removed, they provide default implementation, even though subclasses define overridden implementations.
> Please close this PR.

@RogerRiggs hm. I removed methods in subclases too - they are unused as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20250#issuecomment-2272673688

From dnsimon at openjdk.org  Wed Aug  7 08:40:59 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Aug 2024 08:40:59 GMT
Subject: RFR: 8337972: Problem list jdk/internal/util/ReferencedKeyTest.java
Message-ID: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>

Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926) is fixed to reduce the noise in testing.

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

Commit messages:
 - Problem list jdk/internal/util/ReferencedKeyTest.java

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

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

From scolebourne at openjdk.org  Wed Aug  7 08:59:32 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Wed, 7 Aug 2024 08:59:32 GMT
Subject: RFR: 8337838: Remove unused methods from ChronoLocalDateImpl
In-Reply-To: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
References: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
Message-ID: <lBx54XdinyEO_eR3C_Q5LZx6HFwooOY30X0maV-SL7E=.46c11f5d-bd9a-4b8e-8d1e-69827744b8cb@github.com>

On Fri, 19 Jul 2024 09:52:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could be removed:
> 1. plusWeeks(long)
> 2. minusYears(long)
> 3. minusMonths(long)
> 4. minusWeeks(long)
> 5. minusDays(long)
> 
> Tested `test/jdk/java/time` on Linux x64 release

I believe the rest of the methods are OK to remove given the current design

src/java.base/share/classes/java/time/chrono/ChronoLocalDateImpl.java line 276:

> 274:      * @throws DateTimeException if the result exceeds the supported date range
> 275:      */
> 276:     D plusWeeks(long weeksToAdd) {

Rather than removing it, this method should in fact be called from `plus(long amountToAdd, TemporalUnit unit)` to give subclasses the chance to override the 7 day behaviour. 

(Sure, this is an internal class, and there is no implementation that needs to do that, but it is how the class was designed, and it would be clearer to fix tha current mistaken setup)

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

PR Review: https://git.openjdk.org/jdk/pull/20250#pullrequestreview-2223469992
PR Review Comment: https://git.openjdk.org/jdk/pull/20250#discussion_r1706638887

From viktor.klang at oracle.com  Wed Aug  7 11:06:27 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 7 Aug 2024 11:06:27 +0000
Subject: [External] : Gatherers -- windowBy
In-Reply-To: <CAA9v-_M-vDy2CqTySZ+gdo2bH5L_LSUjKBW6TMFmXVH=zVg2kA@mail.gmail.com>
References: <CAA9v-_N4fypuxTKgU1P-bOBJ3K+5zEH67P9AE_SmrWYc8-8X2Q@mail.gmail.com>
 <MW4PR10MB57746C1EF26FFEBD809F08F6FFBE2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_M-vDy2CqTySZ+gdo2bH5L_LSUjKBW6TMFmXVH=zVg2kA@mail.gmail.com>
Message-ID: <MW4PR10MB57744BAF9FB1A811D21487D9FFB82@MW4PR10MB5774.namprd10.prod.outlook.com>

All input/feedback is welcome! ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Tuesday, 6 August 2024 23:21
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>; Remi Forax <forax at univ-mlv.fr>
Subject: Re: [External] : Gatherers -- windowBy

Thanks. I am going to use it a lot more. If I get more examples, should I post a follow up? Or leave it for others to jump in?

On Mon, Aug 5, 2024, 7:26?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi David,

Thank you for the write-up?sharing your experience with us.

I'm happy you've had much success with `windowBy`, and we're going to have to wait and see what other feedback on Gatherers and potential unmet needs in the roster of baked-in Gatherers.

Gatherers is scheduled to have a second preview in Java 23, in order to give users a chance to try it out and share their experience.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Sunday, 4 August 2024 09:14
To: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Cc: Remi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>>; Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Subject: [External] : Gatherers -- windowBy

Hello Core Libs Dev Team,

Apologies for the massive delay. I have been juggling many severe personal emergencies, and thus, did not have time or strength to follow up on the previous thread -- https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117718.html

As mentioned in my previous thread, I have been extremely happy with the new Gatherers API, and have found numerous uses for it.

I did want to add one addition to the list of premade gatherers provided by the standard library in java.util.stream.Gatherers API -- a windowBy gatherer.

The result of the thread was that, while the feature had nothing wrong with it, evidence needed to be provided of its utility. This email is that evidence. Specifically, this email is providing all of the situations where I used this windowBy Gatherer that Viktor Klang made for me, with the hope that it is strong enough evidence to push this method into the Gatherers API.

Here we go.

  1.  Advent of Code 2020 -- Day 14 [1] -- and here is my code [2] -- here is a link to the line that actually used the gatherer [3]
     *   This cleaned up my solution CONSIDERABLY. If I was doing this with for loops, I would have to do index manipulation to jump ahead my for loop index wise. Here, all I am doing is telling it how to split apart the stream. Way more clear and elegant. Which was critical because this AOC day was extremely difficult for me. Solution is not yet done, but making great progress.
  2.  Service Health Analytics -- Work project, so I can't share the code
     *   This was a super basic use case, but long story short, I'm tracing down yet another network issue, and I wanted to know what was occurring before the network outage, to see if there was a correlation. I ended up scrapping this solution in favor of another one, but I was quite happy with how easy the Gatherer made it to grab exactly what I wanted. It was just a windowBy followed by a sliding window, and then extracting some info by comparing the 2 chunks.
  3.  Typing Metrics [4] -- here is the link to the method that uses the Gatherer [5]
     *   This is where I really put the Gatherer through its paces. I had some semi-complex examples, but I got them all to work out well. It made my logic simpler than the imperative equivalent, while also keeping things concise. Now, one point that caused me some difficulty was recognizing that the Gatherer has a surprisingly large number of edge cases. For example, when looking at the data in aggregate, you notice a pattern -- the first element of every window is the FALSE case of your predicate, while all remaining members of that window are the TRUE case of the predicate. However, it's very possible for the first window to be a single element TRUE case window. I think this is the first time I found a valid use for the Stream::dropWhile method lol. But otherwise, this feature REALLY helped me move forward, and I am very happy with it!

My biggest takeaway from using this Gatherer is that, when dealing with a Stream of events that you want to get metrics of, this gatherer is going to be a critical tool in the arsenal. This Gatherer also pairs BEAUTIFULLY with slidingWindow, to where I feel it made sliding window even stronger. I break up my stream into chunks using the windowBy, then slide over those chunks using sliding window. I kept finding myself using this strategy to aggregate and analyze. To use an analogy, it feels almost like making a database view of a larger database table.

This is my experience using the windowBy Gatherer that Viktor Klang gave me. Please let me know if there are any questions, comments, or concerns.

Thank you for your time, patience, and understanding!
David Alayachew

[1] = https://adventofcode.com/2020/day/14<https://urldefense.com/v3/__https://adventofcode.com/2020/day/14__;!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1j6kToUsc$>
[2] = https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L334<https://urldefense.com/v3/__https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java*L334__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jakXmB9k$>
[3] = https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java#L468<https://urldefense.com/v3/__https://github.com/davidalayachew/Advent_of_Code/blob/1f054282d610af444dd27be4dfb374e10ac76db4/AOC/AOC_2020.java*L468__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jWHufk2U$>
[4] = https://github.com/davidalayachew/HowFastCanYouType<https://urldefense.com/v3/__https://github.com/davidalayachew/HowFastCanYouType__;!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jOKot3vY$>
[5] = https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java#L151<https://urldefense.com/v3/__https://github.com/davidalayachew/HowFastCanYouType/blob/main/src/main/java/HowFastCanYouTypeModule/HowFastCanYouTypePackage/GUI.java*L151__;Iw!!ACWV5N9M2RV99hQ!LEBjZbZKNTq2ifo9CYK0RE3c2wwJMxmUlb7ZWZ88j3Dgq50_x3z_2hX4j2GAL_hicf5s05xDzgM8__xH7_1jXX46EYs$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240807/26f4282e/attachment-0001.htm>

From rriggs at openjdk.org  Wed Aug  7 13:38:32 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Aug 2024 13:38:32 GMT
Subject: RFR: 8337838: Remove unused methods from ChronoLocalDateImpl
In-Reply-To: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
References: <RQnB2TQYzA-u_pRCnq9nrE0b4afqYHA8USvDKYk3f7A=.a7257c20-4e2d-4796-92a8-fae0b0f051c9@github.com>
Message-ID: <uV4mGQPKPl4QYm4cEhFvfzbdI41Ereiv35qU2UHt4yE=.233dab07-a69a-4fef-8277-9e5e462810c2@github.com>

On Fri, 19 Jul 2024 09:52:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could be removed:
> 1. plusWeeks(long)
> 2. minusYears(long)
> 3. minusMonths(long)
> 4. minusWeeks(long)
> 5. minusDays(long)
> 
> Tested `test/jdk/java/time` on Linux x64 release

The implementations, in the subclasses too, were there to match the similar methods in LocalDate. 
At one point in the API development they were visible and had been included in the ChronoLocalDate interface. 
Simplification prevailed.  7-day weeks are ubiquitous in the supported calendars but since no-one has missed these methods they are unneeded.
I agree with Stephen in retaining plusWeeks and its use in the implementation of plus(long, unit).

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

PR Comment: https://git.openjdk.org/jdk/pull/20250#issuecomment-2273493709

From duke at openjdk.org  Wed Aug  7 13:55:10 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 7 Aug 2024 13:55:10 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v2]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <br8ifavyo6rPS-WDeaM6cBidy_gmmOUalcNTh0q8bF0=.08952e42-4ef7-4e0f-8005-4c6dea200265@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

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

 - Merge branch 'openjdk:master' into patchLeftShift
 - Removed trailing whitespace
 - MutableBigInteger.leftShift(int) optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/05514c5b..0f7c8f3d

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

  Stats: 45275 lines in 1479 files changed: 26215 ins; 12187 del; 6873 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

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

From bpb at openjdk.org  Wed Aug  7 15:34:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:34:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v3]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <vfXDNsXH6ayjYSajCqItlH5E0k9DXhNrcRHhQboKF4Y=.03249396-b128-46e2-bf01-3373de8c3f78@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

  8337143: Removed dependency of libjava on headers in libnio/ch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/48519737..7e8a02e3

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

  Stats: 305 lines in 17 files changed: 141 ins; 151 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From bpb at openjdk.org  Wed Aug  7 15:34:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:34:38 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
Message-ID: <7wiOsnhOQIZL7-64yFcJYwWS95gOM7NeaU3IcOZUCUo=.b65933fd-ce5c-4c81-8f39-395f4b4ee33b@github.com>

On Fri, 26 Jul 2024 19:40:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

As part of 7e8a02e, the `nio_util.h` header files were modified. One unused symbolic constant was removed. Symbolic constants used in only one file were moved to that file. Function declarations that were only used where the function is defined were removed. Function declarations used in only one file other than the one where the function is defined were moved to an `extern` in that file. On Unix, one function declaration used in three files was moved to a new header file `Net.h`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2273748931

From bpb at openjdk.org  Wed Aug  7 15:59:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:59:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/7e8a02e3..e28a4f57

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

  Stats: 23454 lines in 774 files changed: 12481 ins; 7665 del; 3308 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From bpb at openjdk.org  Wed Aug  7 15:59:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:59:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
 <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
 <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>
Message-ID: <pDyI_GgnI1YL8jKxJm8g8ffaF7vWPMXjRgG_TElQhfI=.d93950b5-c588-49d3-82ea-901cf6d158aa@github.com>

On Mon, 5 Aug 2024 15:37:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 57:
>> 
>>> 55:     OPTIMIZATION := HIGH, \
>>> 56:     EXTRA_HEADER_DIRS := \
>>> 57:         libnio/ch, \
>> 
>> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this. 
>> 
>> Maybe the libnio/ch code also should move to libjava? Or, perhaps at least the header files. Conceptually, I'd feel better about having a dependency on libnio as a "downstream" library on libjava source code, than the other way around.
>
>> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this.
> 
> I'll look into improving it.

Fixed in 7e8a02e

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \
>> 
>> Please keep libraries alphabetically sorted.
>
> Thanks for pointing this out; I will fix it.

Fixed in 7e8a02e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707325897
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707326484

From ihse at openjdk.org  Wed Aug  7 15:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:59:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
Message-ID: <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>

On Wed, 7 Aug 2024 15:56:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

make/modules/java.base/lib/CoreLibraries.gmk line 71:

> 69:         -framework Foundation \
> 70:         -framework SystemConfiguration, \
> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \

Are these libraries still required to build libnio, or can they be removed from that library now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707327953

From naoto at openjdk.org  Wed Aug  7 16:00:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Aug 2024 16:00:37 GMT
Subject: RFR: 8337603: Change in behavior with
 -Djava.locale.useOldISOCodes=true
In-Reply-To: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
References: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
Message-ID: <Em81aVKs1xuboXOyXcC5itHLsX-CFWIAlIASPyi81GY=.b0dbbec9-00f5-4159-a63e-13177f39a54a@github.com>

On Tue, 6 Aug 2024 00:50:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the removal of the legacy locale data. Legacy locale data happened to have resource bundle for "he" language (new ISO code) with the launguage name for "iw" (old ISO code). CLDR does not have it, thus the name fell back to English.

Thanks for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/20474#issuecomment-2273802879

From naoto at openjdk.org  Wed Aug  7 16:00:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Aug 2024 16:00:37 GMT
Subject: Integrated: 8337603: Change in behavior with
 -Djava.locale.useOldISOCodes=true
In-Reply-To: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
References: <66OH4P-Eo2u2WcQgl3RSYwGhc9nvfYLsCbfl9XGM2zM=.1cb04f45-27cd-4cd5-b16e-6d271142d3f8@github.com>
Message-ID: <ZHNmcm7oiBmFUo-g404-o2KoYsz8mKTWc7EcIs_ls3U=.b3ac2d76-4042-4a9b-9397-69ff420f0473@github.com>

On Tue, 6 Aug 2024 00:50:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing a regression caused by the removal of the legacy locale data. Legacy locale data happened to have resource bundle for "he" language (new ISO code) with the launguage name for "iw" (old ISO code). CLDR does not have it, thus the name fell back to English.

This pull request has now been integrated.

Changeset: d19ba81c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d19ba81ce12a99de1114c1bfe67392f5aee2104e
Stats:     45 lines in 2 files changed: 42 ins; 0 del; 3 mod

8337603: Change in behavior with -Djava.locale.useOldISOCodes=true

Reviewed-by: iris, bpb

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

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

From bpb at openjdk.org  Wed Aug  7 16:03:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:03:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
Message-ID: <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>

On Wed, 7 Aug 2024 15:56:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge
>>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava
>
> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
> 
> Are these libraries still required to build libnio, or can they be removed from that library now?

I will check. Thanks for noticing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707337157

From bpb at openjdk.org  Wed Aug  7 16:06:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:06:35 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
Message-ID: <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>

On Wed, 7 Aug 2024 16:00:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
>> 
>> Are these libraries still required to build libnio, or can they be removed from that library now?
>
> I will check. Thanks for noticing it.

`CoreServices` is still necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707344003

From rriggs at openjdk.org  Wed Aug  7 16:44:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Aug 2024 16:44:31 GMT
Subject: RFR: 8337840: Remove redundant null check in
 ObjectOutputStream.writeProxyDesc
In-Reply-To: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
References: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
Message-ID: <5BRLw_E8seb25rcnSz4huAEYu-yD2sM7UVYBR_GlXuw=.7b3c51e9-2143-4842-97f2-747638564333@github.com>

On Fri, 26 Jul 2024 13:09:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is implicit null check in line before.
> 
> https://github.com/openjdk/jdk/blob/431d4f7e18369466eedd00926a5162a1461d0b25/src/java.base/share/classes/java/io/ObjectOutputStream.java#L1267-L1277
> 
> 'cl' can't be null after that.

lgtm
Hotspot would have elided this check anyway based on the previous implicit check.
The review overhead is higher than the value add to the source.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20351#pullrequestreview-2225694241

From bpb at openjdk.org  Wed Aug  7 18:16:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 18:16:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
Message-ID: <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>

On Wed, 7 Aug 2024 16:03:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will check. Thanks for noticing it.
>
> `CoreServices` is still necessary ([Uniform Type Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).

The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:

- ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
- ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1707599113

From rriggs at openjdk.org  Wed Aug  7 19:31:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Aug 2024 19:31:40 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail with
 ConcurrentModificationException
Message-ID: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>

The original test fails intermittently, the reproducer failed consistently.
With the fix, the failure was not observed in the test or reproducer.

In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

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

Commit messages:
 - 8336926: jdk/internal/util/ReferencedKeyTest.java can fail with ConcurrentModificationException

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

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

From bpb at openjdk.org  Wed Aug  7 20:28:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 20:28:31 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <tofso-rJvucXWQObguLiB8RvN8TviXsh_x0c_P-7eaE=.c02ecf00-9d0d-4bc7-ba38-e4dd22f66d0b@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

Looks reasonable.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20499#pullrequestreview-2226124320

From liach at openjdk.org  Wed Aug  7 21:46:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Aug 2024 21:46:34 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
Message-ID: <dws9t23lwI65ydsSBS-EzSQXmNSDwRfVDaE41FG-3mA=.b8f9e965-f76f-4263-8f73-6a31d9fa6326@github.com>

On Fri, 26 Jul 2024 21:06:31 GMT, Turkhan <duke at openjdk.org> wrote:

> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
> 
> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20363#pullrequestreview-2226251803

From cushon at openjdk.org  Wed Aug  7 22:30:32 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 7 Aug 2024 22:30:32 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <Bc2zrDKvSh0rXimWxxp3vP9hYG-9aPhpMcLbY0I8Q-Y=.e11e51f8-8ec0-4b91-af94-85fe3b87e852@github.com>

On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

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

I still think it'd be slightly worthwhile to fix the built-in sunapi implementation to handle this case, but if the feeling is that it isn't worth spending time on and the possible disruption to `-Werror`, that's also OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2274455669

From darcy at openjdk.org  Thu Aug  8 02:10:01 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Aug 2024 02:10:01 GMT
Subject: RFR: 8338015: Fix "Java Java" typo in package info file of
 java.lang.classfile
Message-ID: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>

Easy fix of an accidentally repeated "Java".

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

Commit messages:
 - JDK-8338015: Fix "Java Java" typo in package info file of java.lang.classfile

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

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

From jiefu at openjdk.org  Thu Aug  8 02:21:35 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 8 Aug 2024 02:21:35 GMT
Subject: RFR: 8338015: Fix "Java Java" typo in package info file of
 java.lang.classfile
In-Reply-To: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
References: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
Message-ID: <TYppVJDfoOR_vCZ773CMOA8oZHLsO_a8xflv7Oryh1o=.c33419e2-094e-4501-9702-c3431ba0dccf@github.com>

On Thu, 8 Aug 2024 02:04:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Easy fix of an accidentally repeated "Java".

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20505#pullrequestreview-2226726552

From jpai at openjdk.org  Thu Aug  8 02:29:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Aug 2024 02:29:32 GMT
Subject: RFR: 8338015: Fix "Java Java" typo in package info file of
 java.lang.classfile
In-Reply-To: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
References: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
Message-ID: <qIg8XqI3tu-bUB078XmxK7K-7OQH2KCCSqM0MHEWx0k=.b087084d-014d-4727-b4ce-b62edec01c64@github.com>

On Thu, 8 Aug 2024 02:04:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Easy fix of an accidentally repeated "Java".

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20505#pullrequestreview-2226737958

From liach at openjdk.org  Thu Aug  8 02:34:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Aug 2024 02:34:30 GMT
Subject: RFR: 8338015: Fix "Java Java" typo in package info file of
 java.lang.classfile
In-Reply-To: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
References: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
Message-ID: <GGRrd2DyGvnyoe5egHBklAO4VR-1yy4iR8dtbaFsi3U=.c8e90785-be4d-4022-9773-6785eda562a1@github.com>

On Thu, 8 Aug 2024 02:04:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Easy fix of an accidentally repeated "Java".

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20505#pullrequestreview-2226743125

From duke at openjdk.org  Thu Aug  8 02:48:39 2024
From: duke at openjdk.org (Turkhan)
Date: Thu, 8 Aug 2024 02:48:39 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <dws9t23lwI65ydsSBS-EzSQXmNSDwRfVDaE41FG-3mA=.b8f9e965-f76f-4263-8f73-6a31d9fa6326@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
 <dws9t23lwI65ydsSBS-EzSQXmNSDwRfVDaE41FG-3mA=.b8f9e965-f76f-4263-8f73-6a31d9fa6326@github.com>
Message-ID: <wbYbBJtLd6nS8Z51RYhVyCG_AXwDwQpXN1wHGj4iH1w=.559c62cc-7113-4eff-9715-7f0508464cf0@github.com>

On Wed, 7 Aug 2024 21:44:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
>> 
>> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.
>
> Marked as reviewed by liach (Reviewer).

@liach, thanks for reviewing and approving.

Regarding the bot's comment. Double-checked, the commit has full name. Should be fine to merge.

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

PR Comment: https://git.openjdk.org/jdk/pull/20363#issuecomment-2274846108

From liach at openjdk.org  Thu Aug  8 04:17:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Aug 2024 04:17:32 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
Message-ID: <eRLIeNsBSpaPdTK-BhuAgX7MVXfyPDGqjp-tbmptEps=.92f5b07c-3f71-44fb-9325-db423f367790@github.com>

On Fri, 26 Jul 2024 21:06:31 GMT, Turkhan <duke at openjdk.org> wrote:

> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
> 
> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

Yep, there's a bot command to integrate a patch. Please check https://wiki.openjdk.org/display/SKARA#Skara-Pullrequestcommands

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

PR Comment: https://git.openjdk.org/jdk/pull/20363#issuecomment-2274917448

From jpai at openjdk.org  Thu Aug  8 05:07:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Aug 2024 05:07:31 GMT
Subject: RFR: 8337972: Problem list
 jdk/internal/util/ReferencedKeyTest.java
In-Reply-To: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
References: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
Message-ID: <VA0gwLH6FWolkySRSmx0c1ofaTcobbije7j9B80Rhug=.5705ec6e-94b4-4259-917e-bae560e23782@github.com>

On Wed, 7 Aug 2024 08:33:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926) is fixed to reduce the noise in testing.

Hello @dougxc, there's now a PR open to fix JDK-8336926 https://github.com/openjdk/jdk/pull/20499.

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

PR Comment: https://git.openjdk.org/jdk/pull/20488#issuecomment-2274959391

From duke at openjdk.org  Thu Aug  8 05:26:32 2024
From: duke at openjdk.org (duke)
Date: Thu, 8 Aug 2024 05:26:32 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
Message-ID: <0SEWf87LJymrXKXkVdW7g10WtxGOYzbuapKjOtHct1E=.0ae03294-854e-4ab0-9c49-53d0d21fac01@github.com>

On Fri, 26 Jul 2024 21:06:31 GMT, Turkhan <duke at openjdk.org> wrote:

> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
> 
> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

@tbadalov 
Your change (at version 583071219fe33bac04237ff83df7734bbdc433a9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20363#issuecomment-2274976616

From liach at openjdk.org  Thu Aug  8 05:37:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Aug 2024 05:37:41 GMT
Subject: RFR: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
Message-ID: <HXtXV1u5iQtw6Daxy_SBapHkbuewASbpZaHr7NJMOAQ=.a404e263-2ea2-47a8-8ca3-ce96bbd0d6cd@github.com>

On Fri, 26 Jul 2024 21:06:31 GMT, Turkhan <duke at openjdk.org> wrote:

> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
> 
> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

Thanks for this typo fix!

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

PR Comment: https://git.openjdk.org/jdk/pull/20363#issuecomment-2274986904

From duke at openjdk.org  Thu Aug  8 05:37:41 2024
From: duke at openjdk.org (Turkhan)
Date: Thu, 8 Aug 2024 05:37:41 GMT
Subject: Integrated: 8337205: Typo in Stack vs Deque Method table in Deque
 specification
In-Reply-To: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
References: <MrS5Vmaw8LvtafqAvTz6E6QWwrvEenPyD9U1g2xWNzE=.4907c251-621a-46da-9a52-106a5212a55a@github.com>
Message-ID: <SetDsRVDlyNIwrA6XN5RPYp2fR5Ltw39vE9MZwO_lIo=.245a159e-f9f2-4688-a8fc-582c0645020b@github.com>

On Fri, 26 Jul 2024 21:06:31 GMT, Turkhan <duke at openjdk.org> wrote:

> This PR fixes `java.util.Deque`'s specification to name `peekFirst()` as an equivalent to Stack's `peek()` method since both of them don't throw when a collection is empty. This is not the case with the current `getFirst()` method.
> 
> Please let me know if I have to fix something in the PR. Will appreciate your guidance since this is my first PR to JDK.

This pull request has now been integrated.

Changeset: 1846a65e
Author:    Turkhan Badalov <badalov.turxan at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1846a65e32624f6da691c1072f44fcb762b43233
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8337205: Typo in Stack vs Deque Method table in Deque specification

Reviewed-by: liach

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

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

From dnsimon at openjdk.org  Thu Aug  8 06:05:40 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Aug 2024 06:05:40 GMT
Subject: RFR: 8337972: Problem list
 jdk/internal/util/ReferencedKeyTest.java
In-Reply-To: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
References: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
Message-ID: <Dq9lxHAvWRiiNPhyyozeWM_Ja5H655pkegI_RJwdD3k=.5d453062-7776-4df5-a47b-f4dacf442e2f@github.com>

On Wed, 7 Aug 2024 08:33:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926) is fixed to reduce the noise in testing.

Great, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20488#issuecomment-2275017545

From dnsimon at openjdk.org  Thu Aug  8 06:05:40 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Aug 2024 06:05:40 GMT
Subject: Withdrawn: 8337972: Problem list
 jdk/internal/util/ReferencedKeyTest.java
In-Reply-To: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
References: <9Ee7RYMsquZPe_lmVhVvWOVfGCzcjMbVj-J_WGllNFg=.2542a8a6-671a-4e5c-9e59-423926247ec7@github.com>
Message-ID: <rwNGzRLIT_T4NSljAOISZ5cJP597YAqUB-GpOAcAieE=.22707a5c-e07f-4d59-a4b9-e78f7f0a0b56@github.com>

On Wed, 7 Aug 2024 08:33:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Problem list until [JDK-8336926](https://bugs.openjdk.org/browse/JDK-8336926) is fixed to reduce the noise in testing.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Aug  8 07:15:07 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 8 Aug 2024 07:15:07 GMT
Subject: RFR: 8336856: Optimize String Concat [v38]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <xDSMqfmVZHCuoY8qik_CXD1QWD29AWiTCjMoCBZ47ak=.a3c9b309-6573-43f8-bf8b-687f2e5ec4cd@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/b260874a..6895db8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=36-37

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

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

From dfuchs at openjdk.org  Thu Aug  8 09:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 09:19:41 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
Message-ID: <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>

On Wed, 7 Aug 2024 15:59:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge
>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

Disclaimer: I have not tried to understand the proposed change in details. However I have spotted a small oddity.

src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:

> 152:     static {
> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
> 154:     }

I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?

src/java.base/windows/native/libjava/IOUtil.c line 37:

> 35: #include "nio.h"
> 36: #include "nio_util.h"
> 37: /* #include "net_util.h" */

Is this change intended or is this a left over from some experimentation?

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

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2227299000
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709024031
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709029492

From shade at openjdk.org  Thu Aug  8 09:25:31 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Aug 2024 09:25:31 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <iBnnRbZG1aRGyBrn20cjiYIzZN-tsalPfslO2cMik30=.2d0cd720-6a0c-41a4-9c01-cf67bbc53e2e@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

Looks good. Comprehension check: only the methods that call back to `ReferencedKeyMap.get` are affected. So methods like `filterKeySet` itself are not affected, because they do `ReferenceKey::get`, not `ReferenceKeyMap::get`.

Wait a sec, I think this PR should include the un-problemlisting, e.g. reverting #20488?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20499#pullrequestreview-2227324243
Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20499#pullrequestreview-2227326298

From shade at openjdk.org  Thu Aug  8 09:45:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Aug 2024 09:45:32 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <6fKbtVJr_ThNp_YKq-CymcVIGmCbXFnaPD4yfq-luMY=.f95d28ef-d0ff-45f4-918c-3b22363c9ef0@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

All right then. I got confused by the PR status.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20499#pullrequestreview-2227373897

From jpai at openjdk.org  Thu Aug  8 09:45:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 8 Aug 2024 09:45:32 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <2NecsOdXxQDT_3Rd8ZbREMMd3FJLliUSyFoxWFKb2mU=.344fddf2-0ee7-49de-95e4-0e411b20b8ef@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

Hello Aleksey,
> Wait a sec, I think this PR should include the un-problemlisting, e.g. reverting #20488?

#20488 wasn't integrated and was instead closed in favour of this current PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20499#issuecomment-2275393112

From duke at openjdk.org  Thu Aug  8 11:43:07 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 8 Aug 2024 11:43:07 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/6895db8a..9f483767

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=37-38

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

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

From ihse at openjdk.org  Thu Aug  8 12:20:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Aug 2024 12:20:36 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
Message-ID: <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>

On Wed, 7 Aug 2024 18:13:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `CoreServices` is still necessary ([Uniform Type Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).
>
> The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:
> 
> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
> - ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```

And pthread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709362110

From duke at openjdk.org  Thu Aug  8 13:05:39 2024
From: duke at openjdk.org (duke)
Date: Thu, 8 Aug 2024 13:05:39 GMT
Subject: Withdrawn: 8326227: Rounding error that may distort
 computeNextGaussian results
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <-SrpMyN3nj5kzdREQGoGCAd7_qex5t2MIdSKckn0huU=.dd650031-5710-4fa2-a494-7ee1278363c5@github.com>

On Mon, 5 Feb 2024 04:25:16 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.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Thu Aug  8 13:35:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Aug 2024 13:35:34 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v7]
In-Reply-To: <If4E-nt-VM_sg_7yTZnKfPD1wiKZaeVxYeONnR1AzPk=.34a8be90-522a-4d70-bbf1-44295e247a0d@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <If4E-nt-VM_sg_7yTZnKfPD1wiKZaeVxYeONnR1AzPk=.34a8be90-522a-4d70-bbf1-44295e247a0d@github.com>
Message-ID: <m4fx7iNauI9k0cPD1QO2sFOQh9pO3DGfWPVf6OiLoNg=.7717ebbe-81dc-4436-a0a0-e8ef4a010248@github.com>

On Tue, 9 Jul 2024 23:17:47 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/util/Collection/MOAT.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

keep-alive while we evaluate the impact...

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

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2275845189

From dfuchs at openjdk.org  Thu Aug  8 13:59:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 13:59:40 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <pKa0HX7swobccMM8eSHEhJP9a52aUU4NuZ_xo89I0V4=.caf0cafa-d0d1-4a0c-810d-ae4b20fe706d@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

The proposed changes look reasonable to me. Those seem to be the only methods where removeStaleReferences() could have been indirectly called while looping over the entries.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20499#pullrequestreview-2227972196

From rriggs at openjdk.org  Thu Aug  8 14:15:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 8 Aug 2024 14:15:31 GMT
Subject: RFR: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <Tiu4ztUjI9Qfge6d3XfDR78itAYeNlDSkI28P3MZCuQ=.f1bbd9c9-cfa2-4427-afcd-d7507ca982ea@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

The robustness of the non-collecting parts of the test as suggested in the Jira comments is covered by a new issue JDK-8338060.

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

PR Comment: https://git.openjdk.org/jdk/pull/20499#issuecomment-2275938107

From bpb at openjdk.org  Thu Aug  8 14:35:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 14:35:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
Message-ID: <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>

On Thu, 8 Aug 2024 12:18:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:
>> 
>> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
>> - ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```
>
> And pthread?

I will check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709642993

From bpb at openjdk.org  Thu Aug  8 14:35:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 14:35:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
Message-ID: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>

On Thu, 8 Aug 2024 09:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge
>>  - 8337143: Removed dependency of libjava on headers in libnio/ch
>>  - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
>>  - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava
>
> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
> 
>> 152:     static {
>> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
>> 154:     }
> 
> I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?

I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?

> src/java.base/windows/native/libjava/IOUtil.c line 37:
> 
>> 35: #include "nio.h"
>> 36: #include "nio_util.h"
>> 37: /* #include "net_util.h" */
> 
> Is this change intended or is this a left over from some experimentation?

It could be leftover. There was a lot of wrangling in this. Probably line 37 could just be deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709645656
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709647530

From dfuchs at openjdk.org  Thu Aug  8 15:19:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 15:19:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
Message-ID: <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>

On Thu, 8 Aug 2024 14:32:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
>> 
>>> 152:     static {
>>> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
>>> 154:     }
>> 
>> I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?
>
> I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?

It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709742606

From darcy at openjdk.org  Thu Aug  8 15:54:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Aug 2024 15:54:36 GMT
Subject: Integrated: 8338015: Fix "Java Java" typo in package info file of
 java.lang.classfile
In-Reply-To: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
References: <ZbMAExQ6IGZG6ectooC8RbbBnzwtB8WCg7VDKny7C-c=.430b4a56-c27a-4718-9004-57b535f92877@github.com>
Message-ID: <49V9g3N8wO4G7YrZVemK74wPYwo6rFXpC6jqGg_8JKc=.b28a4e29-c6b4-4dbf-b1ba-48d51b5882f8@github.com>

On Thu, 8 Aug 2024 02:04:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Easy fix of an accidentally repeated "Java".

This pull request has now been integrated.

Changeset: 78773b17
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78773b1769922611318243b6680d59518ed4e015
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8338015: Fix "Java Java" typo in package info file of java.lang.classfile

Reviewed-by: jiefu, jpai, liach

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

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

From bpb at openjdk.org  Thu Aug  8 16:12:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:12:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
Message-ID: <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>

On Thu, 8 Aug 2024 15:16:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?
>
> It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.

How would you suggest testing this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709847199

From dfuchs at openjdk.org  Thu Aug  8 16:24:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 16:24:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
Message-ID: <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>

On Thu, 8 Aug 2024 16:09:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.
>
> How would you suggest testing this?

I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709861717

From bpb at openjdk.org  Thu Aug  8 16:24:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:24:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
Message-ID: <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>

On Thu, 8 Aug 2024 16:18:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How would you suggest testing this?
>
> I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
> Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.

I'll have to investigate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709866669

From bpb at openjdk.org  Thu Aug  8 16:31:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:31:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
Message-ID: <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>

On Thu, 8 Aug 2024 14:31:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> And pthread?
>
> I will check.

`pthread` is still needed:

open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709879806

From dfuchs at openjdk.org  Thu Aug  8 16:42:38 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 16:42:38 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
Message-ID: <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>

On Thu, 8 Aug 2024 16:21:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
>> Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.
>
> I'll have to investigate.

Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 

InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.

And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.

I am not an expert on library loading though :-(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709897049

From bpb at openjdk.org  Thu Aug  8 16:51:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:51:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
Message-ID: <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>

On Thu, 8 Aug 2024 16:39:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I'll have to investigate.
>
> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 
> 
> InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.
> 
> And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.
> 
> I am not an expert on library loading though :-(

Thanks for the suggestions. I will look into it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709910288

From rriggs at openjdk.org  Thu Aug  8 16:56:36 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 8 Aug 2024 16:56:36 GMT
Subject: Integrated: 8336926: jdk/internal/util/ReferencedKeyTest.java can fail
 with ConcurrentModificationException
In-Reply-To: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
References: <SMWXd4uB8OPH5Jd4L_jdaKeyC63I6rGPETv0_SduLgg=.90ee3732-1ddb-48bd-8025-51996e48cb5c@github.com>
Message-ID: <YIXzTRI4uPfxg9edMy9f_R03cEz4Z5GHr72qTm8rxnA=.bcdf8a68-fc31-4d7c-a153-38457184ee61@github.com>

On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
> 
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods, avoid removing stale references that would modify the keyset while it is being iterated over. 
> If GC removes the key, iterating or streaming over the keyset might get a ConcurrentModificationException.

This pull request has now been integrated.

Changeset: bfb75b96
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfb75b96266f4c5840e2edea13f9aa2c801518cf
Stats:     11 lines in 1 file changed: 7 ins; 1 del; 3 mod

8336926: jdk/internal/util/ReferencedKeyTest.java can fail with ConcurrentModificationException

Reviewed-by: bpb, shade, dfuchs

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

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

From jbhateja at openjdk.org  Thu Aug  8 17:00:05 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 8 Aug 2024 17:00:05 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
Message-ID: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>

Hi All,

As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.


     . SATURATING_UADD   : Saturating unsigned addition.
     . SATURATING_ADD    :  Saturating signed addition. 
     . SATURATING_USUB   : Saturating unsigned subtraction.
     . SATURATING_SUB    : Saturating signed subtraction.
     . UMAX              : Unsigned max
     . UMIN              : Unsigned min.
     

New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.

As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.

Summary of changes:
- Java side implementation of new vector operators.
- Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
- C2 compiler IR and inline expander changes.
- Optimized x86 backend implementation for new vector operators and their predicated counterparts.
- Extends existing VectorAPI Jtreg test suite to cover new operations.

Kindly review and share your feedback.

Best Regards,
PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.

[1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

Commit messages:
 - Removed redundant comment
 - 8338021: Support saturating vector operators in VectorAPI

Changes: https://git.openjdk.org/jdk/pull/20507/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338021
  Stats: 9013 lines in 67 files changed: 8923 ins; 28 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From jbhateja at openjdk.org  Thu Aug  8 17:02:05 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 8 Aug 2024 17:02:05 GMT
Subject: RFR: 8338023: Support two vector selectFrom API
Message-ID: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>

Hi All,

As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.


Declaration:-
    Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)


Semantics:-
    Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  

Summary of changes:
-  Java side implementation of new selectFrom API.
-  C2 compiler IR and inline expander changes.
-  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
-  Optimized x86 backend implementation for AVX512 and legacy target.
-  Function tests covering new API.

JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]


  Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.244          ops/ms
SelectFromBenchmark.selectFromLongVector        1024  thrpt    2   5856.859          ops/ms
SelectFromBenchmark.selectFromLongVector        2048  thrpt    2   1513.378          ops/ms
SelectFromBenchmark.selectFromShortVector       1024  thrpt    2  17888.617          ops/ms
SelectFromBenchmark.selectFromShortVector       2048  thrpt    2   9079.565          ops/ms


Kindly review and share your feedback.

Best Regards,
Jatin

[1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

Commit messages:
 - Adding Benchmark
 - 8338023: Support two vector selectFrom API

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

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

From jbhateja at openjdk.org  Thu Aug  8 17:20:06 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 8 Aug 2024 17:20:06 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SATURATING_UADD   : Saturating unsigned addition.
>      . SATURATING_ADD    :  Saturating signed addition. 
>      . SATURATING_USUB   : Saturating unsigned subtraction.
>      . SATURATING_SUB    : Saturating signed subtraction.
>      . UMAX              : Unsigned max
>      . UMIN              : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8338201
 - Removed redundant comment
 - 8338021: Support saturating vector operators in VectorAPI

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/1ffe4c68..5468e72b

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

  Stats: 3609 lines in 32 files changed: 177 ins; 3316 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

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

From bpb at openjdk.org  Thu Aug  8 21:28:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 21:28:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
Message-ID: <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>

On Thu, 8 Aug 2024 16:48:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 
>> 
>> InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.
>> 
>> And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.
>> 
>> I am not an expert on library loading though :-(
>
> Thanks for the suggestions. I will look into it.

Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:

java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)

This is on Unix (Linux, macOS) only, not on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1710316659

From iklam at openjdk.org  Thu Aug  8 23:07:05 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 8 Aug 2024 23:07:05 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases
Message-ID: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>

This is the first PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).

Add the following command-line options as specified in JEP 483:


- `-XX:AOTMode=off/record/create/auto/on`
- `-XX:AOTConfiguration=<file>.aotconfig`
- `-XX:AOTCache=<file>.aot`

These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.

Please see the CSR (TODO) for detailed specification.






-----
See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

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

Commit messages:
 - Fixed whitespaces
 - 8338017: Add AOT command-line flag aliases

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

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

From duke at openjdk.org  Fri Aug  9 02:47:37 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 9 Aug 2024 02:47:37 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
Message-ID: <DcqvqATFk_AiTtYH6H2RksOoXJP7b0KlKhc-tqUKrNA=.26772437-b440-4094-8faa-bf62e3a990da@github.com>

On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

I have reviewed the code several times and fixed anything I thought could be improved. 

I didn't find a way to test class unloading. For example, I dynamically loaded a method with string concatenation from byte[] code, and then allocated a very large array to trigger OutOfMemoryError, but the class of InlineHiddenClassStrategy.CACHE was still not removed.

Below is my test code:

* Concat Class
Compile the following code into a class and rename it to .clazz as a resource file


public class Concat {
    public static String concat(String a, String b, int i, long j) {
        return a + b + i + j;
    }
}


* TestClass

import org.apache.commons.io.FileUtils;

import java.io.File;
import java.lang.reflect.Method;
import java.net.URL;

public class ClassLoadingTest {
    public static void main(String[] args) throws Throwable {
        for (int i = 0; i < 10_000_000; i++) {
            perf(i);
        }
    }

    public static void perf(int i) throws Throwable {
        URL resource = ClassLoadingTest.class.getClassLoader().getResource("Concat.clazz");
        byte[] code = FileUtils.readFileToByteArray(new File(resource.getFile()));

        MyClassLoader classLoader = new MyClassLoader();
        Class<?> concatClass = classLoader.defineClass("Concat", code);
        Method concat = concatClass.getMethod("concat", String.class, String.class, int.class, long.class);
        Object result = concat.invoke(null, "abc", "d", i, 0L);
        gc();
        if (i % 1000 == 0) {
            System.out.println(result);
        }
    }

    public static void gc() {
        try {
            long[] array = new long[Integer.MAX_VALUE];
            System.out.println(array.length);
            System.gc();
        } catch (OutOfMemoryError ignored) {
            // skip
        }
    }

    static class MyClassLoader extends ClassLoader {
        public Class<?> defineClass(String name, byte[] b) {
            return defineClass(name, b, 0, b.length);
        }
    }
}


* Script to check for class unloading

jps | grep ClassLoadingTest

jmap -histo <pid> | grep StringConcat

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2277042311

From jkarthikeyan at openjdk.org  Fri Aug  9 03:31:38 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Fri, 9 Aug 2024 03:31:38 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
Message-ID: <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>

On Thu, 8 Aug 2024 17:20:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SATURATING_UADD   : Saturating unsigned addition.
>>      . SATURATING_ADD    :  Saturating signed addition. 
>>      . SATURATING_USUB   : Saturating unsigned subtraction.
>>      . SATURATING_SUB    : Saturating signed subtraction.
>>      . UMAX              : Unsigned max
>>      . UMIN              : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8338201
>  - Removed redundant comment
>  - 8338021: Support saturating vector operators in VectorAPI

src/hotspot/share/opto/type.cpp line 495:

> 493:   TypeInt::POS1    = TypeInt::make(1,max_jint,   WidenMin); // Positive values
> 494:   TypeInt::INT     = TypeInt::make(min_jint,max_jint, WidenMax); // 32-bit integers
> 495:   TypeInt::UINT    = TypeInt::make(0, max_juint, WidenMin); // Unsigned ints

This would make an illegal type, right? Since `TypeInt` is signed using `max_juint` as the hi value would end up as signed -1, resulting in the type `0..-1`, an empty type. I wonder if there's a better way to handle this, since in the type system empty types are in a sense equivalent to `TOP`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1710642379

From liach at openjdk.org  Fri Aug  9 04:34:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 Aug 2024 04:34:33 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v3]
In-Reply-To: <QF6We-mvzM73X-Ib_LENQe_lqACvlaOCXrg-IDpmAn0=.e0331e4c-06ce-4f14-be66-332020f4053c@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <QF6We-mvzM73X-Ib_LENQe_lqACvlaOCXrg-IDpmAn0=.e0331e4c-06ce-4f14-be66-332020f4053c@github.com>
Message-ID: <kCxFEEy-eebOwnJXU8nccqTfICcM0lIK-gZB_NND38Q=.5eef68b2-909a-4b14-b759-12a0a93d7cf6@github.com>

On Mon, 10 Jun 2024 10:09:38 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:
> 
>   Copy-paste error; CONDY_INVOKE returns Object. Fixes TestDynamicConstant.java

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19598#pullrequestreview-2229290816

From duke at openjdk.org  Fri Aug  9 05:58:40 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 9 Aug 2024 05:58:40 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
Message-ID: <DcOvpdD5Vpzx6wP1E4vKn9jr5-eEP5laRF8kXIeANy0=.26ed79a5-dfa8-4778-b9ba-7f0b8cf4f38c@github.com>

On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

I've found a way to verify that unloading of the hidden concat classes works.

Run the following code:


import java.lang.invoke.*;

public class HiddenClassUnloading {
    public static void main(String[] args) throws Throwable {
        MethodHandles.Lookup lookup = MethodHandles.lookup();

        Class<?>[] types = new Class[] {
                int.class, long.class, double.class, float.class, char.class, boolean.class, String.class,
        };
        Object[] values = new Object[] {
                1, 1L, 1D, 1F, 'C', true, "A",
        };

        int sum = 0;
        for (int i = 0; i < 1_000_000; i++) {
            int radix = types.length;
            String str = Integer.toString(i, radix);
            int length = str.length();
            String recipe = "\1".repeat(length);
            Class<?>[] ptypes = new Class[length];
            Object[] pvalues = new Object[length];
            for (int j = 0; j < length; j++) {
                int index = Integer.parseInt(str.substring(j, j + 1), radix);
                ptypes[j] = types[index];
                pvalues[j] = values[index];
            }
            MethodType concatType = MethodType.methodType(String.class, ptypes);
            CallSite callSite = StringConcatFactory.makeConcatWithConstants(
                    lookup,
                    "concat",
                    concatType,
                    recipe,
                    new Object[0]
            );
            MethodHandle mh = callSite.dynamicInvoker();
            String result = switch (length) {
                case 1 -> (String) mh.invoke(pvalues[0]);
                case 2 -> (String) mh.invoke(pvalues[0], pvalues[1]);
                case 3 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2]);
                case 4 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3]);
                case 5 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3], pvalues[4]);
                case 6 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3], pvalues[4], pvalues[5]);
                case 7 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3], pvalues[4], pvalues[5], pvalues[6]);
                case 8 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3], pvalues[4], pvalues[5], pvalues[6], pvalues[7]);
                case 9 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3], pvalues[4], pvalues[5], pvalues[6], pvalues[7], pvalues[8]);
                case 10 -> (String) mh.invoke(pvalues[0], pvalues[1], pvalues[2], pvalues[3], pvalues[4], pvalues[5], pvalues[6], pvalues[7], pvalues[8], pvalues[9]);
                default -> throw new RuntimeException("length too large " + length);
            };
            sum += result.length();
        }
        System.out.println(sum);
    }
}


We use jmap -histo to observe whether the number of hidden classes is growing continuously.

# get pid
jps | grep HiddenClassUnloading

# Count the number of hidden classes
jmap -histo <pid> | grep -c "StringConcat/0"


The result is as follows, the number of hidden classes does not keep growing, so the unloading of hidden classes is working.

? jmap -histo 1037 | grep -c "StringConcat/0"
17
? jmap -histo 1037 | grep -c "StringConcat/0"
43
? jmap -histo 1037 | grep -c "StringConcat/0"
77
? jmap -histo 1037 | grep -c "StringConcat/0"
92
? jmap -histo 1037 | grep -c "StringConcat/0"
110
? jmap -histo 1037 | grep -c "StringConcat/0"
133
? jmap -histo 1037 | grep -c "StringConcat/0"
159
? jmap -histo 1037 | grep -c "StringConcat/0"
2
? jmap -histo 1037 | grep -c "StringConcat/0"

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2277202933

From aturbanov at openjdk.org  Fri Aug  9 07:22:37 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 9 Aug 2024 07:22:37 GMT
Subject: RFR: 8337840: Remove redundant null check in
 ObjectOutputStream.writeProxyDesc
In-Reply-To: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
References: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
Message-ID: <wB38NzmAbYQa068gIveLBU_TXFAIpApSQBFnpFyxuQ8=.7cbf248a-5297-4569-beaf-4584220b642b@github.com>

On Fri, 26 Jul 2024 13:09:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is implicit null check in line before.
> 
> https://github.com/openjdk/jdk/blob/431d4f7e18369466eedd00926a5162a1461d0b25/src/java.base/share/classes/java/io/ObjectOutputStream.java#L1267-L1277
> 
> 'cl' can't be null after that.

Thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/20351#issuecomment-2277305580

From aturbanov at openjdk.org  Fri Aug  9 07:22:37 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 9 Aug 2024 07:22:37 GMT
Subject: Integrated: 8337840: Remove redundant null check in
 ObjectOutputStream.writeProxyDesc
In-Reply-To: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
References: <AhNwovFB26UW4For9NOM5A1RMAqqaSJIb00xhO6P2Ak=.6053ef7d-08c0-48b1-ba38-1d3fad258b66@github.com>
Message-ID: <RZov0VBNvgV535zm9qWdhnclshFnT7G1H95psS2aTZI=.6a984eed-9f51-4914-b3cf-14e847692abe@github.com>

On Fri, 26 Jul 2024 13:09:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is implicit null check in line before.
> 
> https://github.com/openjdk/jdk/blob/431d4f7e18369466eedd00926a5162a1461d0b25/src/java.base/share/classes/java/io/ObjectOutputStream.java#L1267-L1277
> 
> 'cl' can't be null after that.

This pull request has now been integrated.

Changeset: 82d5768c
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82d5768c1bdccfaf97a41f32a8bfcfd03a0fb378
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8337840: Remove redundant null check in ObjectOutputStream.writeProxyDesc

Reviewed-by: rriggs

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

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

From dfuchs at openjdk.org  Fri Aug  9 09:08:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Aug 2024 09:08:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
Message-ID: <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>

On Thu, 8 Aug 2024 21:23:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Thanks for the suggestions. I will look into it.
>
> Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:
> 
> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
> 	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)
> 
> This is on Unix (Linux, macOS) only, not on Windows.

OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.

            var impl = new Inet6AddressImpl();

It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711100272

From ihse at openjdk.org  Fri Aug  9 09:43:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Aug 2024 09:43:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
 <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
Message-ID: <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>

On Thu, 8 Aug 2024 16:29:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will check.
>
> `pthread` is still needed:
> 
> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'

Ok then. Thank you for your thorough checking!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711154512

From bpb at openjdk.org  Fri Aug  9 15:08:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 15:08:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
 <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
 <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>
Message-ID: <mrZPe0z2rhoHe3rKhS5bqy6-2wZCFJrUDDQ_ktdUnu4=.7e35f805-21e1-48ca-b819-3fd9bc542485@github.com>

On Fri, 9 Aug 2024 09:40:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> `pthread` is still needed:
>> 
>> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'
>
> Ok then. Thank you for your thorough checking!

Thank you for suggesting it!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711643521

From bpb at openjdk.org  Fri Aug  9 15:11:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 15:11:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
Message-ID: <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>

On Fri, 9 Aug 2024 09:05:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:
>> 
>> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
>> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
>> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
>> 	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)
>> 
>> This is on Unix (Linux, macOS) only, not on Windows.
>
> OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.
> 
>             var impl = new Inet6AddressImpl();
> 
> It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?

Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711648714

From chen.l.liang at oracle.com  Fri Aug  9 15:21:19 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 9 Aug 2024 15:21:19 +0000
Subject: Costs of caught exceptions during method handle resolve
In-Reply-To: <CA+W24BWsW7Pyki=gTp1P=5wh4DS3LM6HzpMXa5ewHLeRtXhnyQ@mail.gmail.com>
References: <CA+W24BWsW7Pyki=gTp1P=5wh4DS3LM6HzpMXa5ewHLeRtXhnyQ@mail.gmail.com>
Message-ID: <SJ2PR10MB766907AA270C79B2F280AA0BA2BA2@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Jan, thank you so much for this report!
java.lang.invoke is part of core libraries, so I replied to the core-libs list instead.
I see the bottom-up view of MethodHandleNatives.resolve missing, but I need a top-down view to understand better what's happening. Is InvokerBytecodeGenerator.lookupPregenerated part of this flame graph?

Fyi, there's a preexisting problem with pre-generated MethodHandle infrastructure lookup; we use that resolve, but internally JVM will create Error instances and throw them (as part of regular method resolution) which will call this stacktrace filling. The stack will look weird but here's how they are generated and eliminated in case you are interested: https://github.com/openjdk/jdk/blob/3cf3f300de1e9d2c8767877ed3a26679e34b7d22/src/hotspot/share/prims/methodHandles.cpp#L792

If this is the problem you are encountering, we are currently thinking about generating a list of present methods so we don't go through VM's resolution. A temporary workaround is to generate a CDS (Class Data Sharing (oracle.com)<https://docs.oracle.com/en/java/javase/22/vm/class-data-sharing.html>) archive from a boot run so these methods will be present, and it will also slightly improve your startup speed. Or you can generate a jlink image (which is more complicated). Both solutions are not valid for the libraries. (You can try grasp how these two work at https://github.com/openjdk/jdk/pull/19164)

Maybe another way to verify the problem is to run with the system property -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true, which jli will start printing if it can resolve methods; each time it fails, it will go through this error creation and stacktrace filling, unfortunately. If you have CDS archive, these resolution may print success if those infrastructures are generated in the run that generated the CDS archive.

Finally, before we take action, I still need you to verify my said issue is the root cause; you can confirm either by looking at the callers to MHN.resolve, or by running with -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true and check its outputs. I would prefer you to test on the latest versions, such as 22 or the test builds at https://jdk.java.net/23, in addition to your baseline supported version 17. I am more than glad to help if you encounter further issues, or if this turns out not to be the cause. And again, thank you for taking your time to diagnose and report!

Best regards,
Chen Liang
________________________________
From: discuss <discuss-retn at openjdk.org> on behalf of Jan Bernitt <jaanbernitt at gmail.com>
Sent: Friday, August 9, 2024 6:15 AM
To: discuss at openjdk.org <discuss at openjdk.org>
Subject: Costs of caught exceptions during method handle resolve

Hi everyone!

I recently found a performance issue in my library that goes back to large numbers of exceptions being thrown and caught where the costs are dominated by filling in the stack trace and resolving method handles.

So I investigated ways to avoid causing the exceptions. One of the reasons for the exceptions
was somewhere internally in the method handle resolve. I ended up caching the method handles to avoid this happening over and over again as my library uses method handles all the time :D

As far as I can tell this should be something the JDK can solve differently internally to avoid the cost of throwing and catching the exception which should improve performance of method handles significantly if you use them (including the lookup) in a hot loop. You can find more details here https://github.com/dhis2/json-tree/pull/66

If this is of interest to some feel free to ask for more details.
Also if anyone sees that I am just using methods handles wrong and therefore cause the internal exception please let me know.

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

From duke at openjdk.org  Fri Aug  9 15:23:48 2024
From: duke at openjdk.org (duke)
Date: Fri, 9 Aug 2024 15:23:48 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
Message-ID: <3r3BVhGKPPKpcHX9Xfz2nBwWnod3-FrolykXcf9EQPc=.65a6e150-f33d-4dd6-a5e3-3058427c821f@github.com>

On Thu, 6 Oct 2022 06:28:04 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> 8289552: Make intrinsic conversions between bit representations of half precision values and floats
>
> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated instruct to use kmovw

@smita-kamath 
Your change (at version a00c3ecdab6b2c8ca6883e92bb51e3fa99544a17) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/9781#issuecomment-1275006152

From epeter at openjdk.org  Fri Aug  9 15:23:48 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 9 Aug 2024 15:23:48 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <cxn5tjWHWpBzE7cOSGkqvriYsku5W6097w4bua8UtNw=.fb7e49b5-2da6-4bad-a671-6d466c1da7e3@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
 <66be8SJdxPOqmqsQ1YIwS4zM4GwPerypGIf8IbfxhRs=.1d03c94a-f3e5-40ae-999e-bdd5f328170d@github.com>
 <cxn5tjWHWpBzE7cOSGkqvriYsku5W6097w4bua8UtNw=.fb7e49b5-2da6-4bad-a671-6d466c1da7e3@github.com>
Message-ID: <ZogAHCiPZbkKspocA2tAjdX3KJbGMtfbSlMF4zwgo94=.83bcc283-b96b-4dd6-a33a-724add514f46@github.com>

On Tue, 11 Oct 2022 17:00:53 GMT, Smita Kamath <svkamath at openjdk.org> wrote:

>> I started new testing.
>
> @vnkozlov Thank you for reviewing the patch.

@smita-kamath I think I just found another regression of this feature: https://bugs.openjdk.org/browse/JDK-8338126
Can you please have a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/9781#issuecomment-2278194773

From dfuchs at openjdk.org  Fri Aug  9 15:51:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Aug 2024 15:51:36 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
Message-ID: <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>

On Fri, 9 Aug 2024 15:09:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.
>> 
>>             var impl = new Inet6AddressImpl();
>> 
>> It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?
>
> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.

I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.

In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.

The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.

So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711706176

From rriggs at openjdk.org  Fri Aug  9 15:59:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Aug 2024 15:59:41 GMT
Subject: RFR: 8338060: jdk/internal/util/ReferencedKeyTest should be more
 robust
Message-ID: <qfbAbYOckNgamO32M_hr_eihCimaxEXLel1g_TXLaWs=.3a6d06b0-e6fb-4eb6-8644-34a45f4ac6a5@github.com>

Addressing latent issues with ReferencedKeyTest
- During the `methods()` tests the keys should be strongly held to avoid inadvertent GC collection and subsequent test failures (JDK-8336926)
- Merge changes from Valhalla to use String (identity objects) for keys instead of Integer and Long that are value objects. (JDK-8336390)

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

Commit messages:
 - 8338060: jdk/internal/util/ReferencedKeyTest should be more robust

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

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

From bpb at openjdk.org  Fri Aug  9 16:01:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 16:01:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
 <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
Message-ID: <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>

On Fri, 9 Aug 2024 15:47:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.
>
> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.
> 
> In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.
> 
> The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.
> 
> So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.

Thanks. I'll try adding it to the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711723045

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

  8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/e28a4f57..f57b6f13

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

  Stats: 11 lines in 3 files changed: 4 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
 <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
 <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>
Message-ID: <3uXhrkj0U16cG1Lf-JGCkagHJD0MLFcbcEI6ZsBxBiw=.774775bc-3ddf-4882-872a-29292daea008@github.com>

On Fri, 9 Aug 2024 15:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.
>> 
>> In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.
>> 
>> The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.
>> 
>> So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.
>
> Thanks. I'll try adding it to the test.

In f57b6f1 I reverted the Inet6AddressImpl change and added the "net" library load to NullCharInHostname.java. With this change the test passed on Unix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711895017

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
Message-ID: <a7W6SwWulATRx-mtErRTwW-ZznoeuYwXKDIwzUBoVys=.afa3463d-053c-4340-adb0-17139ff35391@github.com>

On Thu, 8 Aug 2024 14:33:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/native/libjava/IOUtil.c line 37:
>> 
>>> 35: #include "nio.h"
>>> 36: #include "nio_util.h"
>>> 37: /* #include "net_util.h" */
>> 
>> Is this change intended or is this a left over from some experimentation?
>
> It could be leftover. There was a lot of wrangling in this. Probably line 37 could just be deleted.

Line 37 deleted in f57b6f1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1711892358

From svkamath at openjdk.org  Fri Aug  9 18:02:49 2024
From: svkamath at openjdk.org (Smita Kamath)
Date: Fri, 9 Aug 2024 18:02:49 GMT
Subject: RFR: 8289552: Make intrinsic conversions between bit
 representations of half precision values and floats [v13]
In-Reply-To: <ZogAHCiPZbkKspocA2tAjdX3KJbGMtfbSlMF4zwgo94=.83bcc283-b96b-4dd6-a33a-724add514f46@github.com>
References: <jSD6qbxQoXW38OmtLWXZUBQ1ntARgrmhFs3vz45Oehs=.fd1a2fd2-dd39-4c5c-ad18-dcf80d459ff9@github.com>
 <dlR1hXuQFlInPmQJnRhc-h0kVh-vjxQ_iDHdaOAutY8=.dbac1fc9-5a12-4b4b-91ac-d542a828a92d@github.com>
 <66be8SJdxPOqmqsQ1YIwS4zM4GwPerypGIf8IbfxhRs=.1d03c94a-f3e5-40ae-999e-bdd5f328170d@github.com>
 <cxn5tjWHWpBzE7cOSGkqvriYsku5W6097w4bua8UtNw=.fb7e49b5-2da6-4bad-a671-6d466c1da7e3@github.com>
 <ZogAHCiPZbkKspocA2tAjdX3KJbGMtfbSlMF4zwgo94=.83bcc283-b96b-4dd6-a33a-724add514f46@github.com>
Message-ID: <_PlJd1cbdiMGb1yUCWWZDf13xpTIBH2FtPcJ62VduhE=.36f54fc6-2c4f-488d-8d41-874cbf24d722@github.com>

On Fri, 9 Aug 2024 15:21:22 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @vnkozlov Thank you for reviewing the patch.
>
> @smita-kamath I think I just found another regression of this feature: https://bugs.openjdk.org/browse/JDK-8338126
> Can you please have a look?

@eme64, Sure will look into it. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/9781#issuecomment-2278462816

From duke at openjdk.org  Fri Aug  9 19:12:49 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 19:12:49 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v5]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <UatD4PcFFWa9SBV3e7JE7gQiIXS4kBRq3-gXIPJlybg=.d75373af-2d56-4097-a12d-37b7369ef18e@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 incrementally with one additional commit since the last revision:

  Update RandomSupportTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/4743d2bf..d391b96a

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

  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 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 duke at openjdk.org  Fri Aug  9 19:12:49 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 19:12:49 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <m-pnIboOayQs3MDIfRjNPYh7IkLiCjyuglVeys3u22U=.020582b0-89ad-4db7-ab75-8eac418e67d3@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>
 <m-pnIboOayQs3MDIfRjNPYh7IkLiCjyuglVeys3u22U=.020582b0-89ad-4db7-ab75-8eac418e67d3@github.com>
Message-ID: <L0DcvD1eCIRq9xx7fWJzhd_balpdj028XRzdP1y_R9o=.9e37374a-5164-4d80-8fdc-9de50829f7e5@github.com>

On Wed, 12 Jun 2024 10:08:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

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

@jaikiran Thanks for these results; I'll take another look at the test over the weekend.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2278574602

From duke at openjdk.org  Fri Aug  9 19:12:49 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 19:12:49 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <ydAPTl9qq1McwfqKeh39LRynljlcTemTzwg5man_3f4=.204d73ff-7182-411e-a95f-20b5258d0a5e@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
 <ydAPTl9qq1McwfqKeh39LRynljlcTemTzwg5man_3f4=.204d73ff-7182-411e-a95f-20b5258d0a5e@github.com>
Message-ID: <CKZNqoxnoTxeJQByZFaBzGlhPdbVsRW-XdhZP9CQbTM=.96c9a0c4-c4ec-45e9-8571-f33354340edb@github.com>

On Wed, 12 Jun 2024 09:23:23 GMT, Jaikiran Pai <jpai 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
>
> 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

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1712018244

From bpb at openjdk.org  Fri Aug  9 21:25:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 21:25:43 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com>
 <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>
Message-ID: <CMEneLagY0Ru5EeggWc3pS5swtt6RUP5573Wx_hsGvI=.56996229-57ca-4c1f-ade6-502f99ab2e3f@github.com>

On Fri, 26 Jul 2024 21:34:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use.
> 
> Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by classes involved in networking?

Another option is `NIONetUtil` but the `NIO` prefix is redundant with the package name.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2278773773

From duke at openjdk.org  Fri Aug  9 22:43:27 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 22:43:27 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v6]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <QRTfcwdINQyBZd7S14MgxzE0AgJcbyj3zTYnmCFNVCw=.484e4b44-01ce-42bd-867d-c650583cd0d9@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 incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/d391b96a..6af12383

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

  Stats: 4 lines in 2 files changed: 2 ins; 1 del; 1 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 duke at openjdk.org  Fri Aug  9 22:43:29 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 22:43:29 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <I7TTiiAVgMXJLiUXnjq3TBkbvWmYoqcbit2PpSqmQ54=.b2666bdb-4a72-4a4d-94d2-78f90c0397f2@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
 <I7TTiiAVgMXJLiUXnjq3TBkbvWmYoqcbit2PpSqmQ54=.b2666bdb-4a72-4a4d-94d2-78f90c0397f2@github.com>
Message-ID: <2IFJbDLXEeB5B16hgBLMcBDAxut_KW131f8DS8BzU1c=.78525d86-47b2-46c6-a1c1-2531ad48475c@github.com>

On Wed, 12 Jun 2024 08:16:25 GMT, Jaikiran Pai <jpai 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
>
> 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 
 uncertain whether the change to this if block is guaranteed or likely to save computation time.

Updated to return `maxValue` instead. Now it's unambiguously a performance optimization.

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

Is Guy saying it's impossible for `maxExtraMinus1` to be too small even without this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1712306048
PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1712308075

From duke at openjdk.org  Fri Aug  9 22:51:54 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 22:51:54 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v3]
In-Reply-To: <4ypNrlSXMpskXb_r2Swz29F-b-6fnmj816_VzZNf5SY=.73a76345-170f-47b8-bf2c-fe3a9718b745@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <At-2-pCkpOZRRYsCcyet13TQ7p8RBY0jSiKi4MGiVME=.e512a201-eedb-4aa4-a5e3-da70622ab886@github.com>
 <4ypNrlSXMpskXb_r2Swz29F-b-6fnmj816_VzZNf5SY=.73a76345-170f-47b8-bf2c-fe3a9718b745@github.com>
Message-ID: <cFT7xQ395a6ceyhHDDCz2Hpa3QVC-jvOgBm8kGMVvGk=.4f1ef180-f5f8-48c2-95b5-7e03884d0f39@github.com>

On Wed, 12 Jun 2024 09:35:12 GMT, Jaikiran Pai <jpai 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
>
> 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);
> System.out.println("got " + val + " for max " + 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.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17703#discussion_r1712323293

From duke at openjdk.org  Fri Aug  9 22:56:21 2024
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 9 Aug 2024 22:56:21 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v7]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <OFhBOTIxjj3cmezn0-EnNaxp4Xh2CTLESPDMRnei7Us=.a574b9a3-141f-44e1-b4c2-2cbceb3a8abb@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 incrementally with one additional commit since the last revision:

  Test with larger powers of 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/6af12383..bdd78170

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

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 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 naoto at openjdk.org  Fri Aug  9 23:32:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Aug 2024 23:32:36 GMT
Subject: RFR: 8337839: Make a few fields in MergeCollation static
In-Reply-To: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>
References: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>
Message-ID: <CsIXzQjQ85XCiYuvZ-fgTF-7HRTnQjLHajkvGl3vg2w=.b83d82c2-d8cc-408c-8df3-b4b210e6634e@github.com>

On Thu, 25 Jul 2024 08:59:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in java.text.MergeCollation could be made 'static':
> 1. BITARRAYMASK
> 2. BYTEPOWER
> 3. BYTEMASK

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20323#pullrequestreview-2231258576

From duke at openjdk.org  Sat Aug 10 00:06:08 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sat, 10 Aug 2024 00:06:08 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v8]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <g4XK15DLX_AGmAYC6dMyi6Ci5Nbe3vx6boVV9nnXhMM=.ae590048-9e7a-43fd-b1e6-0934eb572867@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 incrementally with one additional commit since the last revision:

  Fix a test bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/bdd78170..101ac0e9

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

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 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 duke at openjdk.org  Sat Aug 10 01:17:03 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sat, 10 Aug 2024 01:17:03 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v9]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <_qZRap96MLyvSDHyFO58moBedd7FowuVZLGnnF4QaHU=.81b1e3d9-4186-4a60-b405-9deb8c848d36@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 incrementally with one additional commit since the last revision:

  Fix a syntax error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/101ac0e9..20565c50

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 duke at openjdk.org  Sat Aug 10 03:00:10 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sat, 10 Aug 2024 03:00:10 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v10]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <tURXyMEKEQ6hCWUbuB1oCbxO6PcNNlcpMwIdc1hWArc=.ce58aa27-4587-4f8e-b962-068c559abd54@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 incrementally with one additional commit since the last revision:

  Fix: must add 1 *after* dividing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/20565c50..1ca49fcb

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

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 duke at openjdk.org  Sat Aug 10 03:22:34 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sat, 10 Aug 2024 03:22:34 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v10]
In-Reply-To: <tURXyMEKEQ6hCWUbuB1oCbxO6PcNNlcpMwIdc1hWArc=.ce58aa27-4587-4f8e-b962-068c559abd54@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <tURXyMEKEQ6hCWUbuB1oCbxO6PcNNlcpMwIdc1hWArc=.ce58aa27-4587-4f8e-b962-068c559abd54@github.com>
Message-ID: <Xzqkkpf6cloDaAUYrO8IeUio9jeJ9eCw-HKYzAUPPgU=.8e7afac4-e3ed-4e61-b8ee-c8399589be0e@github.com>

On Sat, 10 Aug 2024 03:00:10 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as 12.0, it won't actually return a value larger than `1.5 * exponentialX0` (11.353912041222094); and the error gets worse as we go further into the tail. (This affects slightly less than 12 outputs per million for an ideal RNG.) 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:
> 
>   Fix: must add 1 *after* dividing

@GuySteele Thanks for your earlier feedback; I've now verified the problem and quantified the rate at which `computeNextExponential` is affected.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2278958913

From duke at openjdk.org  Sun Aug 11 02:07:10 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 11 Aug 2024 02:07:10 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v11]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <ZR82Kepwi6JOrZYBtnC--CZcCTuUJc88Kv2YkpDp_pc=.022dd1dc-14c2-492e-b1c3-0cfb177babc1@github.com>

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as 12.0, it won't actually return a value larger than `1.5 * exponentialX0` (11.353912041222094); and the error gets worse as we go further into the tail. (This affects slightly less than 12 outputs per million for an ideal RNG.) 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 (with probability $$e^{-2^{63} exponentialX0} \approx 10^{-3.022 \times 10^{19}}$$ for an ideal RNG); 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:

  Fix?

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/1ca49fcb..5e29b6f9

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

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 duke at openjdk.org  Sun Aug 11 02:12:20 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 11 Aug 2024 02:12:20 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v12]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <BVPoR1jIhnJi7hj8_0VaEfAJql6rCC38pZgouarlJb0=.b2928897-9fa4-460e-8c70-4fc92cb0ff1f@github.com>

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as 12.0, it won't actually return a value larger than `1.5 * exponentialX0` (11.353912041222094); and the error gets worse as we go further into the tail. (This affects slightly less than 12 outputs per million for an ideal RNG.) 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 (with probability $$e^{-2^{63} exponentialX0} \approx 10^{-3.022 \times 10^{19}}$$ for an ideal RNG); 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 five additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into patch-2
 - Merge pull request #2 from Pr0methean/revert-1-whitesource/configure
   
   Revert "Configure WhiteSource Bolt for GitHub"
 - Revert "Configure WhiteSource Bolt for GitHub"
 - Merge pull request #1 from Pr0methean/whitesource/configure
   
   Configure WhiteSource Bolt for GitHub
 - Add .whitesource configuration file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/5e29b6f9..ddccfa6f

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 duke at openjdk.org  Sun Aug 11 03:24:10 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 11 Aug 2024 03:24:10 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v13]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <gbT0HMddw4bAiMjDmNOpNiEQUMsefLLHCTaGq9oitK0=.49fd4a42-deb6-4a68-a3f7-fae78bb04937@github.com>

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as 12.0, it won't actually return a value larger than `1.5 * exponentialX0` (11.353912041222094); and the error gets worse as we go further into the tail. (This affects slightly less than 12 outputs per million for an ideal RNG.) This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making `nextGaussian` loop infinitely in the worst case (with probability $$e^{-2^{63} exponentialX0} \approx 10^{-3.022 \times 10^{19}}$$ for an ideal RNG); 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:

  Fix?

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/ddccfa6f..080f3ea8

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Sun Aug 11 07:30:12 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 11 Aug 2024 07:30:12 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v14]
In-Reply-To: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
Message-ID: <T2Uz16GtZrm8BRHjuxNzxoE36gGBV7sp89pV2HK3wd4=.00390817-db70-4931-9579-99969ee54658@github.com>

> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as 12.0, it won't actually return a value larger than `1.5 * exponentialX0` (11.353912041222094); and the error gets worse as we go further into the tail. (This affects slightly less than 12 outputs per million for an ideal RNG.) This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making `nextGaussian` loop infinitely in the worst case (with probability $$e^{-2^{63} exponentialX0} \approx 10^{-3.022 \times 10^{19}}$$ for an ideal RNG); 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 three additional commits since the last revision:

 - Lower limit to fix timeout
 - Fix?
 - Revert "Fix?"
   
   This reverts commit 5e29b6f924269410b800c4f5a367d7bc259be5b2.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17703/files
  - new: https://git.openjdk.org/jdk/pull/17703/files/080f3ea8..efc3dc4c

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

  Stats: 9 lines in 2 files changed: 1 ins; 0 del; 8 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 olivier.cailloux at gmail.com  Sun Aug 11 09:42:59 2024
From: olivier.cailloux at gmail.com (Olivier Cailloux)
Date: Sun, 11 Aug 2024 11:42:59 +0200
Subject: Negation of a regular expression in a Pattern
Message-ID: <4f69cb0dabef9e4b1d2757d2a41be469a919a98a.camel@gmail.com>

Dear list,

The?Pattern Javadoc?does not specify whether ?Any character? includes
line terminators in ?Any character except a, b, or c (negation)?
([^abc]) or ?Any character except one in the Greek block (negation)?
(\P{InGreek}), or whether it depends on DOTALL or MULTILINE being set.

As a result, it seems to me impossible from the doc to deduce, for
example, whether the Pattern "[^a]" will match a line terminator
(spoiler alert:?it does).?This discussion?illustrates the confusion.

Would an addition to the doc be considered?

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

From scolebourne at openjdk.org  Sun Aug 11 10:01:38 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sun, 11 Aug 2024 10:01:38 GMT
Subject: RFR: 8337279: Optimize format instant [v3]
In-Reply-To: <TqSGxLtidk6LhthFo2Yz1qoHLrN_3wZCeKvXOKZJew8=.b37a8e79-cc7f-4695-9b08-560b5a2be6a9@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <TqSGxLtidk6LhthFo2Yz1qoHLrN_3wZCeKvXOKZJew8=.b37a8e79-cc7f-4695-9b08-560b5a2be6a9@github.com>
Message-ID: <ol9BFjTmzsjP78skurj5jvv8quisgFvQNGBFLMy7TX4=.a7876455-667e-4b8a-a86c-b06f6224fce8@github.com>

On Sun, 28 Jul 2024 15:52:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. fix handle fraction == -1
>   2. Split two methods to make codeSize less than 325

I'm still skeptical of some parts of this PR as it makes the code harder to folow. The new tests are a good addition and should be merged.

Have you tried the performance of simply breaking out the currentEra/beforeCurrentEra methods *without making any other changes*? Since the logic to produce the nano fraction is going to stay in this method, I don't really see the advantage in trying to get LocalDateTime to do the fraction some of the time.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 3818:

> 3816:             if (fractionalDigits == 0) {
> 3817:                 inNano = 0;
> 3818:             }

Suggestion:

            if (fractionalDigits == 0) {
                inNano = 0;
            }
            boolean printNanoInLocalDateTime = fractionalDigits == -2
                    || (inNano == 0 && (fractionalDigits == 0 || fractionalDigits == -1));

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

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2231779313
PR Review Comment: https://git.openjdk.org/jdk/pull/20353#discussion_r1712950065

From duke at openjdk.org  Sun Aug 11 10:13:12 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 11 Aug 2024 10:13:12 GMT
Subject: RFR: 8337279: Optimize format instant [v4]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <tewlz6ls6dar24fOMiBnLMfN8cIOFOxE0bhFjTU8EpE=.c4dce236-9a63-4ebd-9675-aebdae0803d5@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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

  Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
  
  Co-authored-by: Stephen Colebourne <scolebourne at joda.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/75798425..a5abb542

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

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

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

From duke at openjdk.org  Sun Aug 11 10:17:08 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 11 Aug 2024 10:17:08 GMT
Subject: RFR: 8337279: Optimize format instant [v5]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <8ZZCEQNu7k0Ggx-Hc_oLz5UtgWxcm00R4F8uuuKPE_g=.b858d20c-2196-45a6-9b30-b32c4118af07@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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

  copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/a5abb542..87566614

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

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

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

From scolebourne at openjdk.org  Sun Aug 11 10:17:08 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sun, 11 Aug 2024 10:17:08 GMT
Subject: RFR: 8337279: Optimize format instant [v4]
In-Reply-To: <tewlz6ls6dar24fOMiBnLMfN8cIOFOxE0bhFjTU8EpE=.c4dce236-9a63-4ebd-9675-aebdae0803d5@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <tewlz6ls6dar24fOMiBnLMfN8cIOFOxE0bhFjTU8EpE=.c4dce236-9a63-4ebd-9675-aebdae0803d5@github.com>
Message-ID: <CGO2mZCHNADPxezlauZ85BH-QQjIbBMangNMYanZJmI=.bbc1a44b-aff8-4053-891b-cd384676e6eb@github.com>

On Sun, 11 Aug 2024 10:13:12 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>   
>   Co-authored-by: Stephen Colebourne <scolebourne at joda.org>

A more productive direction might be to move `LocalDate.formatTo` and `LocalTime.formatTo` to a JDK internal class (eg. in `jdk.internal.util`?), and then edit `LocalTime.formatTo` to handle `fractionalDigits` directly as another method parameter. This would allow the formatters in `DateTimeFormatterBuilder` to directly use the `formatTo` methods without adding any new public APIs.

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2282706467

From scolebourne at openjdk.org  Sun Aug 11 10:28:37 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sun, 11 Aug 2024 10:28:37 GMT
Subject: RFR: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <8kkgNlHiHVBWPhgef1_8qkkPOGrh16qfVi0yf3Mu81U=.e0af77b0-8962-48b1-ad39-f30f040167ce@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

Change looks fine, but is it actually faster?

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

Marked as reviewed by scolebourne (Author).

PR Review: https://git.openjdk.org/jdk/pull/20368#pullrequestreview-2231785832

From duke at openjdk.org  Sun Aug 11 11:16:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 11 Aug 2024 11:16:36 GMT
Subject: RFR: 8337279: Optimize format instant [v5]
In-Reply-To: <8ZZCEQNu7k0Ggx-Hc_oLz5UtgWxcm00R4F8uuuKPE_g=.b858d20c-2196-45a6-9b30-b32c4118af07@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <8ZZCEQNu7k0Ggx-Hc_oLz5UtgWxcm00R4F8uuuKPE_g=.b858d20c-2196-45a6-9b30-b32c4118af07@github.com>
Message-ID: <VYKiiKk4btBB_cKLTG3is_4T3NbZQUqGhVu6NEO2-cw=.6280df67-88b1-4d5d-9f01-a3b037bab17d@github.com>

On Sun, 11 Aug 2024 10:17:08 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

> I'm still skeptical of some parts of this PR as it makes the code harder to folow. The new tests are a good addition and should be merged.
> 
> Have you tried the performance of simply breaking out the currentEra/beforeCurrentEra methods _without making any other changes_? Since the logic to produce the nano fraction is going to stay in this method, I don't really see the advantage in trying to get LocalDateTime to do the fraction some of the time.


git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline with test
git checkout 85ee5de07dd9f45a4e1659e17f9a52e69fa77df3
make test TEST="micro:java.time.ToStringBench.instantToString"

Benchmark                       Mode  Cnt  Score   Error   Units
ToStringBench.instantToString  thrpt   15  4.749 ? 0.624  ops/ms

# current version
git checkout 875666143e6d717634f2a3cc3c397b2ca8b63e63
make test TEST="micro:java.time.ToStringBench.instantToString"

Benchmark                       Mode  Cnt  Score   Error   Units
ToStringBench.instantToString  thrpt   15  5.713 ? 0.474  ops/ms +20.29%

# baseline with simply breaking out the currentEra/beforeCurrentEra methods without making any other changes
git fbf66307f738cd40e061c6d26fa05c062ccd048b
make test TEST="micro:java.time.ToStringBench.instantToString"

Benchmark                       Mode  Cnt  Score   Error   Units
ToStringBench.instantToString  thrpt   15  4.716 ? 0.569  ops/ms -0.69%


In the branch `fbf66307f738cd40e061c6d26fa05c062ccd048b`, the benchmark results are very unstable because the test data includes currentEra and beforeCurrentEra. The current version has the best performance and can handle currentEra and beforeCurrentEra

The result is somewhat unexpected. I thought the performance improvement was mainly due to codeSize < 325. The specific reason needs further analysis.

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2282722011

From duke at openjdk.org  Sun Aug 11 11:37:32 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 11 Aug 2024 11:37:32 GMT
Subject: RFR: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <2Xkf420rgoF4ULsUW4A2zAkMe8oBpH3rWMKoQ_oGI9k=.b39d1f25-b160-4b09-ad98-193d7b7982bf@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

Below are the performance numbers on the MacBook M1 Pro. In the zonedDateTimeToString scenario, the performance is improved by 44.81%


#baseline 
git checkout 034297a6bd9bfcea7fa48792f54c84a6e976b319
make test TEST="micro:java.time.ToStringBench.zonedDateTimeToString"

Benchmark                             Mode  Cnt  Score   Error   Units
ToStringBench.zonedDateTimeToString  thrpt   15  8.979 ? 0.206  ops/ms

# current
git checkout 9d7cc54c449d4e12d0eb30c103e8aa3aaf206b6d
make test TEST="micro:java.time.ToStringBench.zonedDateTimeToString"

Benchmark                             Mode  Cnt   Score   Error   Units
ToStringBench.zonedDateTimeToString  thrpt   15  13.003 ? 0.214  ops/ms +44.81%

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

PR Comment: https://git.openjdk.org/jdk/pull/20368#issuecomment-2282727944

From duke at openjdk.org  Sun Aug 11 11:43:37 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 11 Aug 2024 11:43:37 GMT
Subject: RFR: 8337279: Optimize format instant [v4]
In-Reply-To: <CGO2mZCHNADPxezlauZ85BH-QQjIbBMangNMYanZJmI=.bbc1a44b-aff8-4053-891b-cd384676e6eb@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <tewlz6ls6dar24fOMiBnLMfN8cIOFOxE0bhFjTU8EpE=.c4dce236-9a63-4ebd-9675-aebdae0803d5@github.com>
 <CGO2mZCHNADPxezlauZ85BH-QQjIbBMangNMYanZJmI=.bbc1a44b-aff8-4053-891b-cd384676e6eb@github.com>
Message-ID: <t5wik0Zgq-AkCNYL44WGNuFN0ySm2mrtClZdCufVH1A=.142aa4c3-6923-439d-9f68-245b91f566c2@github.com>

On Sun, 11 Aug 2024 10:13:35 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

> A more productive direction might be to move `LocalDate.formatTo` and `LocalTime.formatTo` to a JDK internal class (eg. in `jdk.internal.util`?), and then edit `LocalTime.formatTo` to handle `fractionalDigits` directly as another method parameter. This would allow the formatters in `DateTimeFormatterBuilder` to directly use the `formatTo` methods without adding any new public APIs.

I prefer to provide JavaTimeAccess in SharedSecrets, which will require less changes. This depends on https://github.com/openjdk/jdk/pull/20368

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2282729464

From jpai at openjdk.org  Sun Aug 11 11:54:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 11 Aug 2024 11:54:39 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v8]
In-Reply-To: <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
Message-ID: <4pE1YNShjsqihQJfLg4ddNogAW7-U6oNCIalOdZDt40=.527674ea-2aa9-4192-8ad9-e3ddb026f9dd@github.com>

On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java).
>  - Add GZIP input test for various gzip(1) command outputs.

Hello Archie,

> That sounds reasonable. Importantly it doesn't specify the swallowing of IOException's, which means hopefully someday we can stop doing that...
>
> Would you guys recommend including some kind of additional statement like this?
> If an IOException is thrown while attempting to read or decode a GZIP header following a previous GZIP stream's trailer...

We should leave out any mention of IOException from the javadoc specification. That will then make this an implementation detail and like you note, it will then allow us to decide in future how we want to deal with that specific part of the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2282732551

From duke at openjdk.org  Sun Aug 11 13:34:13 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 11 Aug 2024 13:34:13 GMT
Subject: RFR: 8337279: Optimize format instant [v6]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <GC9-gj7lHrL0TgDE0ny4H23TVFMoubkUGGYoXhhKvnE=.72457c6d-83fe-4490-9233-3cc49bfebcc9@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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

  breaking out the printNano methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/87566614..ccbd6b5a

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

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

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

From scolebourne at joda.org  Sun Aug 11 14:17:57 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 11 Aug 2024 15:17:57 +0100
Subject: Package.getPackage deprecation
Message-ID: <CACzrW9DSPwBR=bpib1tUCf+BFNouAAQKciDooC+vqpU93uNrpg@mail.gmail.com>

I make use of Package.getPackage in Joda-Convert but the method has
now been deprecated. I'd like to update my code, but AFAICT the
suggested alternative does not work.

The Joda-Convert code allows a user to convert a Package object to a
String, and back again. Reading the deprecation, I'm aware that this
may not work perfectly, but I do have to maintain compatibility as
best I can.

The deprecation asks users to use ClassLoader#getDefinedPackage
instead. To do this properly, users have to loop up the ClassLoader
parent list. However, the boot class loader is generally returned as
null, and it is obviously impossible to call getDefinedPackage on a
null reference.

ie.
Package.getPackage("java.util") works OK, but is deprecated

The suggested replacement is this code, but it does not work because
the boot class loader is returned as null:
 private static Package parsePackage(String str) {
  var loader = JDKStringConverter.class.getClassLoader();
  var pkg = (Package) null;
  while (loader != null && pkg == null) {
    pkg = loader.getDefinedPackage(str);
    loader = loader.getParent();
  }
  return pkg;
 }

Am I misunderstanding things?

See also https://stackoverflow.com/questions/77259364/how-to-get-a-package-from-its-path-in-java

My current workaround is to call Package.getAllPackages() and search
for "java.util" manually, which appears to work OK.

thanks
Stephen

From alan.bateman at oracle.com  Sun Aug 11 16:18:53 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 11 Aug 2024 17:18:53 +0100
Subject: Package.getPackage deprecation
In-Reply-To: <CACzrW9DSPwBR=bpib1tUCf+BFNouAAQKciDooC+vqpU93uNrpg@mail.gmail.com>
References: <CACzrW9DSPwBR=bpib1tUCf+BFNouAAQKciDooC+vqpU93uNrpg@mail.gmail.com>
Message-ID: <70f3de17-6034-4d9e-9db4-f7fe6ed53a5a@oracle.com>

On 11/08/2024 15:17, Stephen Colebourne wrote:
> I make use of Package.getPackage in Joda-Convert but the method has
> now been deprecated. I'd like to update my code, but AFAICT the
> suggested alternative does not work.
>
> The Joda-Convert code allows a user to convert a Package object to a
> String, and back again. Reading the deprecation, I'm aware that this
> may not work perfectly, but I do have to maintain compatibility as
> best I can.
>
> The deprecation asks users to use ClassLoader#getDefinedPackage
> instead. To do this properly, users have to loop up the ClassLoader
> parent list. However, the boot class loader is generally returned as
> null, and it is obviously impossible to call getDefinedPackage on a
> null reference.
>
> ie.
> Package.getPackage("java.util") works OK, but is deprecated
>
> The suggested replacement is this code, but it does not work because
> the boot class loader is returned as null:
>   private static Package parsePackage(String str) {
>    var loader = JDKStringConverter.class.getClassLoader();
>    var pkg = (Package) null;
>    while (loader != null && pkg == null) {
>      pkg = loader.getDefinedPackage(str);
>      loader = loader.getParent();
>    }
>    return pkg;
>   }
>
> Am I misunderstanding things?

Package.getPackage is deprecated a long time, I don't think we've seen 
too many complaints. Nowadays it's probably not too useful except to get 
to package annotations (everything else in that API dates from JDK 1.2 
and the since removed extension mechanism).

The set of package names for packages in the modules defined to the boot 
loader can be obtained with code like this:

 ??? ModuleLayer.boot()
 ??????????????? .modules()
 ??????????????? .stream()
 ??????????????? .filter(m -> m.getClassLoader() == null)
 ??????????????? .flatMap(m -> m.getPackages().stream())
 ??????????????? .collect(Collectors.toSet());

which I think is what you are looking for here.

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

From acobbs at openjdk.org  Sun Aug 11 18:58:05 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 11 Aug 2024 18:58:05 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v9]
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: <uCe-ROsBsSqWzakkOT1bIP0RyKuPNDRzKg3mQsEWcUE=.ed7fdaed-8285-4062-ba97-495f0ccc9278@github.com>

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
> 
> There are several issues with this:
> 
> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
> 
> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
> 
> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

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

  Revert all functional changes, leaving only tests & Javadoc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18385/files
  - new: https://git.openjdk.org/jdk/pull/18385/files/f3939c05..a69bf2a9

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

  Stats: 133 lines in 3 files changed: 18 ins; 84 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18385/head:pull/18385

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

From acobbs at openjdk.org  Sun Aug 11 18:58:06 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 11 Aug 2024 18:58:06 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v8]
In-Reply-To: <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
Message-ID: <poNRwd1RUkhCqLfUPqRW7IGeGO0c5DInvYzjwk9BhK0=.4bff5582-af1f-40c7-bce5-97c69d0c9f27@github.com>

On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java).
>  - Add GZIP input test for various gzip(1) command outputs.

OK I've reverted any functional changes. The net result should just be additional Javadoc and two new unit tests. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2282855270

From duke at openjdk.org  Sun Aug 11 19:18:34 2024
From: duke at openjdk.org (duke)
Date: Sun, 11 Aug 2024 19:18:34 GMT
Subject: Withdrawn: 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: <Ur1rWCD3KNCw63DHYgGZT_O0nswgxxM57LBFTvaSYeU=.2d408ee0-aa24-403c-8734-582af167353f@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.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Sun Aug 11 21:44:41 2024
From: duke at openjdk.org (Chris Hennick)
Date: Sun, 11 Aug 2024 21:44:41 GMT
Subject: RFR: 8326227: Rounding error that may distort computeNextGaussian
 results [v14]
In-Reply-To: <T2Uz16GtZrm8BRHjuxNzxoE36gGBV7sp89pV2HK3wd4=.00390817-db70-4931-9579-99969ee54658@github.com>
References: <mG562d8Xt55WPLUaLOI7f0UcsgUSnOld4tlbJNVlnFI=.a6220bee-54e3-41e0-afde-2df71a91dfdc@github.com>
 <T2Uz16GtZrm8BRHjuxNzxoE36gGBV7sp89pV2HK3wd4=.00390817-db70-4931-9579-99969ee54658@github.com>
Message-ID: <7lFnLNMkpgrUn4l_-QEs1i9L0R4fEQwKwPmkkZkdB1I=.a8aec83c-aaff-48c3-8f51-eddd9ac093a6@github.com>

On Sun, 11 Aug 2024 07:30:12 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This provides a slightly more accurate bounding limit for `computeNextExponentialSoftCapped`. Currently, if the maximum is specified as 12.0, it won't actually return a value larger than `1.5 * exponentialX0` (11.353912041222094); and the error gets worse as we go further into the tail. (This affects slightly less than 12 outputs per million for an ideal RNG.) This could cause the `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in `computeNextGaussian` on line 1402 to always be true, making `nextGaussian` loop infinitely in the worst case (with probability $$e^{-2^{63} exponentialX0} \approx 10^{-3.022 \times 10^{19}}$$ for an ideal RNG); 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 three additional commits since the last revision:
> 
>  - Lower limit to fix timeout
>  - Fix?
>  - Revert "Fix?"
>    
>    This reverts commit 5e29b6f924269410b800c4f5a367d7bc259be5b2.

Update: having read the McFarland paper, I'm no longer confident this bug actually exists or that any performance improvements are possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-2282898111

From winterhalter at openjdk.org  Sun Aug 11 22:31:43 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Sun, 11 Aug 2024 22:31:43 GMT
Subject: RFR: 8337302: Undefined type variable results in null
Message-ID: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>

When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

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

Commit messages:
 - JDK-8337302: Throw exception upon search for type variable without representation.

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

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

From scolebourne at joda.org  Sun Aug 11 22:49:04 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 11 Aug 2024 23:49:04 +0100
Subject: Package.getPackage deprecation
In-Reply-To: <70f3de17-6034-4d9e-9db4-f7fe6ed53a5a@oracle.com>
References: <CACzrW9DSPwBR=bpib1tUCf+BFNouAAQKciDooC+vqpU93uNrpg@mail.gmail.com>
 <70f3de17-6034-4d9e-9db4-f7fe6ed53a5a@oracle.com>
Message-ID: <CACzrW9CnAjp3dtdX4dzvNSfCa_=KgC-AiMW_OxAV4515Mi6SeA@mail.gmail.com>

On Sun, 11 Aug 2024 at 17:19, Alan Bateman <alan.bateman at oracle.com> wrote:
> Package.getPackage is deprecated a long time, I don't think we've seen too many complaints. Nowadays it's probably not too useful except to get to package annotations (everything else in that API dates from JDK 1.2 and the since removed extension mechanism).
>
> The set of package names for packages in the modules defined to the boot loader can be obtained with code like this:
>
>     ModuleLayer.boot()
>                 .modules()
>                 .stream()
>                 .filter(m -> m.getClassLoader() == null)
>                 .flatMap(m -> m.getPackages().stream())
>                 .collect(Collectors.toSet());
>
> which I think is what you are looking for here.

That doesn't quite work as it returns String package names, not
Package objects (I need the Package object to maintain compatibility).
Sounds like Package.getPackages() is the only current workaround.

FWIW I do think there is a case to review the deprecation text of
Package.getPackage(String).

thanks
Stephen

From liangchenblue at gmail.com  Mon Aug 12 00:43:09 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Sun, 11 Aug 2024 19:43:09 -0500
Subject: Package.getPackage deprecation
In-Reply-To: <CACzrW9CnAjp3dtdX4dzvNSfCa_=KgC-AiMW_OxAV4515Mi6SeA@mail.gmail.com>
References: <CACzrW9DSPwBR=bpib1tUCf+BFNouAAQKciDooC+vqpU93uNrpg@mail.gmail.com>
 <70f3de17-6034-4d9e-9db4-f7fe6ed53a5a@oracle.com>
 <CACzrW9CnAjp3dtdX4dzvNSfCa_=KgC-AiMW_OxAV4515Mi6SeA@mail.gmail.com>
Message-ID: <CABe8uE3NpGL6LvXVwdDdBtFQ7PsmTPTVp=txyn7keTNCutRtjA@mail.gmail.com>

Hi Stephen,
I agree: there's no way to get defined packages for the boot class loader
directly via Package.getDefinedPackage. They are not accessible via the
system or platform class loaders. The alternative approaches via
Package.getDefinedPackages() or getPackage() can be intercepted by custom
class loaders as well.
Since the introduction of the Module system, package is now seen more like
a property, that a package in a class loader always maps to one module.
(This trick has been useful in defining classes with MethodHandles.Lookup)

I think we probably need a way to work around this restriction; it indeed
makes little sense that regular java code cannot access the boot loader
packages reliably. I think we can do this as easy as making
ClassLoader.getPackages() and getPackage() public like getDefinedPackages()
or getDefinedPackage(), but the impact is unsure.

P.S. About the package class itself, we can probably upgrade its nested
VersionInfo class to a record, and make Package itself final.

Chen Liang

On Sun, Aug 11, 2024 at 5:50?PM Stephen Colebourne <scolebourne at joda.org>
wrote:

> On Sun, 11 Aug 2024 at 17:19, Alan Bateman <alan.bateman at oracle.com>
> wrote:
> > Package.getPackage is deprecated a long time, I don't think we've seen
> too many complaints. Nowadays it's probably not too useful except to get to
> package annotations (everything else in that API dates from JDK 1.2 and the
> since removed extension mechanism).
> >
> > The set of package names for packages in the modules defined to the boot
> loader can be obtained with code like this:
> >
> >     ModuleLayer.boot()
> >                 .modules()
> >                 .stream()
> >                 .filter(m -> m.getClassLoader() == null)
> >                 .flatMap(m -> m.getPackages().stream())
> >                 .collect(Collectors.toSet());
> >
> > which I think is what you are looking for here.
>
> That doesn't quite work as it returns String package names, not
> Package objects (I need the Package object to maintain compatibility).
> Sounds like Package.getPackages() is the only current workaround.
>
> FWIW I do think there is a case to review the deprecation text of
> Package.getPackage(String).
>
> thanks
> Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240811/b197cd90/attachment.htm>

From liach at openjdk.org  Mon Aug 12 00:47:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 00:47:40 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: <GAroHTOptf4khg0EJGA8L9DcFU7MjJ6zCcF8N5hYoiA=.8449a453-b239-4a66-aaad-6c5b38816ebf@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

With merge stores, you can probably reimplement these two classes with direct array writes instead of Unsafe, for ease of maintenance.

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

PR Comment: https://git.openjdk.org/jdk/pull/19616#issuecomment-2282957595

From liach at openjdk.org  Mon Aug 12 00:54:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 00:54:40 GMT
Subject: RFR: 8337302: Undefined type variable results in null
In-Reply-To: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
Message-ID: <m2QBi6v9-k1oIzuuylDp-bJ4YAkKX3o7tltbMEpK5zM=.38b00924-98dc-4f6e-9bc2-ae2fe47c93e4@github.com>

On Sun, 11 Aug 2024 22:25:40 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

src/java.base/share/classes/java/lang/TypeNotPresentException.java line 37:

> 35:  * this exception is unchecked.
> 36:  *
> 37:  * <p>Note that this exception may be used when undefined type variables

Seems we can remove this note, now that we moved it to the last paragraph :)

test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 40:

> 38: 
> 39:     public static void main(String[] args) throws Exception {
> 40:         ClassWriter classWriter = new ClassWriter(ClassWriter.COMPUTE_MAXS);

We currently use ClassFile API to quickly dump classes and there's a test infrastructure class `ByteCodeLoader` once you declare `@library /test/lib` jtreg directive. See example here: https://github.com/openjdk/jdk/pull/19281/files#diff-6407a097383e3239602ee0621dcf17e8a90ba2d990a4546e4ea4ff89ad9b89d5 Updated `TestBadSignatures.java`

P.S. accidentally commented on your commit instead of here as a review comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1713093516
PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1713094798

From pkoppula at openjdk.org  Mon Aug 12 05:15:15 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Mon, 12 Aug 2024 05:15:15 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v2]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <ZZJrEvTWuwtJWssZMMNZwp-bm66lalq35NZEk1FMPsE=.a1bc7f0e-b8dc-4490-8747-fef05b622940@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

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

  JDK-8329251

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/22bc6e00..e23a70d6

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

  Stats: 13 lines in 3 files changed: 1 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20414/head:pull/20414

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

From pkoppula at openjdk.org  Mon Aug 12 05:17:37 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Mon, 12 Aug 2024 05:17:37 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <cCyCvgViblDu0S0dnxz1EFHXQC2Rzvd4Sd6mvCqGDlA=.a77710c5-a754-4b08-8381-a77e266f0293@github.com>

On Thu, 1 Aug 2024 04:11:24 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Please hold on the review, I'm trying to add debug statements to TLS code.

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

PR Comment: https://git.openjdk.org/jdk/pull/20414#issuecomment-2283127192

From jbhateja at openjdk.org  Mon Aug 12 06:32:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 12 Aug 2024 06:32:33 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
Message-ID: <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>

On Fri, 9 Aug 2024 03:28:53 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8338201
>>  - Removed redundant comment
>>  - 8338021: Support saturating vector operators in VectorAPI
>
> src/hotspot/share/opto/type.cpp line 495:
> 
>> 493:   TypeInt::POS1    = TypeInt::make(1,max_jint,   WidenMin); // Positive values
>> 494:   TypeInt::INT     = TypeInt::make(min_jint,max_jint, WidenMax); // 32-bit integers
>> 495:   TypeInt::UINT    = TypeInt::make(0, max_juint, WidenMin); // Unsigned ints
> 
> This would make an illegal type, right? Since `TypeInt` is signed using `max_juint` as the hi value would end up as signed -1, resulting in the type `0..-1`, an empty type. I wonder if there's a better way to handle this, since in the type system empty types are in a sense equivalent to `TOP`.

@jaskarth , its usage in existing patch is limited to [type comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542). 

My plan is to address intrinsification of new core lib APIs, associated value range folding optimization (since unsigned numbers have different value range of [0, MAX_VALUE) vs signed [-MIN_VALUE/2, +MAX_VALUE/2) numbers) and auto-vectorization in a follow up patch.

**Notes on C2 type system:**  
Unlike Type::FLOAT, integral type ranges are specified using _lo and _hi value range, these ranges are pruned using flow functions associated with each operation IR.  Constraining the value ranges allows logic pruning, e.g.  in1[TypeInt]  & 0x7FFFFFFF  will chop off -ve values ranges from in1,  thus a constrol structure like . `if (in1 < 0) { true_path ; } else { false_path; } `  which uses in1 as a flow condition will sweepout the true path.

C2 type system only maintains value ranges for integral types i.e. long and int, any sub-word type which as per JVM specification has an int storage "word" only constrains the value range of TypeInt.  

A type which represent a constant value has same _hi and _lo value.

Floating point types Type::FLOAT / DOUBLE cannot maintain upper  / lower value ranges due to rounding constraints.
Thus a C2 type system maintains a separate type TypeF and TypeD which are singletons and represent a constant value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1713220777

From winterhalter at openjdk.org  Mon Aug 12 07:31:09 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Mon, 12 Aug 2024 07:31:09 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v2]
In-Reply-To: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
Message-ID: <9BxGHDh9wyMMjYEPcvglh5Uj91A9ZugvshVx2sANlD0=.607999df-d0e2-43bd-881d-e14c4d262d10@github.com>

> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8337302: Undefined type variable results in null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20535/files
  - new: https://git.openjdk.org/jdk/pull/20535/files/d9b6ccf1..932dd9a1

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

  Stats: 32 lines in 2 files changed: 4 ins; 12 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20535.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20535/head:pull/20535

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

From duke at openjdk.org  Mon Aug 12 09:35:19 2024
From: duke at openjdk.org (Oussama Louati)
Date: Mon, 12 Aug 2024 09:35:19 GMT
Subject: RFR: 8307818: Convert Indify tool to Classfile API [v17]
In-Reply-To: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
References: <tCFk9yrCtcoBnzvNIgceY0eOaXg9ZiN9nkCuhHIyMyw=.9cc5f994-8d35-411a-bb39-7c3f2ac34dda@github.com>
Message-ID: <01yQYlCZs1Jgiu0YV-8xJ0T17aZBGb1grDYbGDt8asw=.b431ec8a-b072-4c4e-9d0b-8f4635553f6e@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.
> ### 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 10 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>
 - 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>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18841/files
  - new: https://git.openjdk.org/jdk/pull/18841/files/02347415..8cedaeaf

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

  Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 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 raffaello.giulietti at oracle.com  Mon Aug 12 13:34:28 2024
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Mon, 12 Aug 2024 15:34:28 +0200
Subject: Negation of a regular expression in a Pattern
In-Reply-To: <4f69cb0dabef9e4b1d2757d2a41be469a919a98a.camel@gmail.com>
References: <4f69cb0dabef9e4b1d2757d2a41be469a919a98a.camel@gmail.com>
Message-ID: <6206128f-ce67-47d7-b00d-93a865f202cf@oracle.com>

I'm not sure what's unclear in "any character except a, b, or c" or "any 
character except one in the Greek block".
A line terminator is neither 'a' nor 'b' nor 'c', nor is it in the Greek 
block.

Your example works the same in JDK 8, 11, 17, 21, 22, with or without 
the additional MULTILINE or DOTALL flags.

(BTW, if you look carefully, the example in the Stack Overflow 
discussion you are referring to builds a matcher over a string that does 
_not_ contain any line terminator.)

As documented (and implied by the name), DOTALL refers to the pattern "."

Similarly, MULTILINE refers to the "^" and "$" boundary matchers.



If you feel the doc is incorrect, you might consider filing a bug report
https://bugs.java.com/bugdatabase/




On 2024-08-11 11:42, Olivier Cailloux wrote:
> Dear list,
> 
> The Pattern Javadoc <https://docs.oracle.com/en/java/javase/22/docs/api/ 
> java.base/java/util/regex/Pattern.html>?does not specify whether ?Any 
> character? includes line terminators in ?Any character except |a|, |b|, 
> or |c| (negation)? ([^abc]) or ?Any character except one in the Greek 
> block (negation)? (\P{InGreek}), or whether it depends on DOTALL or 
> MULTILINE being set.
> 
> As a result, it seems to me impossible from the doc to deduce, for 
> example, whether the Pattern "[^a]" will match a line terminator 
> (spoiler alert: it does <https://onecompiler.com/java/42nuaa4bd>). This 
> discussion <https://stackoverflow.com/questions/64383917/>?illustrates 
> the confusion.
> 
> Would an addition to the doc be considered?
> 


From sgehwolf at openjdk.org  Mon Aug 12 13:44:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Aug 2024 13:44:35 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v4]
In-Reply-To: <ZUmCX2Tqmw_48beJOefsyDEgjElCZWV6IVl7SMZi4r0=.37d3a4ee-2740-4745-ae47-766da3b7fb6e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <ZUmCX2Tqmw_48beJOefsyDEgjElCZWV6IVl7SMZi4r0=.37d3a4ee-2740-4745-ae47-766da3b7fb6e@github.com>
Message-ID: <KFHRLAlKos--oyr5fL_-baIgmQMk5QCJohgysvGDCLc=.1a4ca42f-5682-46bd-ba44-f1c85e3eb8f1@github.com>

On Thu, 11 Jul 2024 16:46:13 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 six additional commits since the last revision:
> 
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

Please keep it open, bot.

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

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

From vklang at openjdk.org  Mon Aug 12 13:47:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 12 Aug 2024 13:47:03 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire
 when failing due to a LinkageError or other errors
Message-ID: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>

8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

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

Commit messages:
 - Improve resilience of AQS and AQLS acquire in the face of errors

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

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

From vklang at openjdk.org  Mon Aug 12 13:47:04 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 12 Aug 2024 13:47:04 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors
In-Reply-To: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
Message-ID: <HWm6MqMB-KRF4r1orsH342d7vdXi1UCl5JOkNOvLsP0=.890f16ed-9b22-4a7c-8b0b-fee2a5e461e9@github.com>

On Mon, 12 Aug 2024 13:41:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

@DougLea @AlanBateman FYI

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

PR Comment: https://git.openjdk.org/jdk/pull/20548#issuecomment-2284029040

From liach at openjdk.org  Mon Aug 12 13:54:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 13:54:36 GMT
Subject: RFR: 8336267: Method and Constructor signature parsing can be
 shared on the root object
In-Reply-To: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
References: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
Message-ID: <YiqPHEL8cWJeDkltFL6GVoxUIv9PS1x2bsocrVRVx_k=.8e0d449c-c32f-4a01-b8ad-d4736157b587@github.com>

On Mon, 15 Jul 2024 04:05:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared.

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/20179#issuecomment-2284052180

From liach at openjdk.org  Mon Aug 12 13:54:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 13:54:39 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v2]
In-Reply-To: <9BxGHDh9wyMMjYEPcvglh5Uj91A9ZugvshVx2sANlD0=.607999df-d0e2-43bd-881d-e14c4d262d10@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <9BxGHDh9wyMMjYEPcvglh5Uj91A9ZugvshVx2sANlD0=.607999df-d0e2-43bd-881d-e14c4d262d10@github.com>
Message-ID: <jdIhNAm73bwEdtIErZtXIQZ3uQBsxCQZOEXx5P_D6W4=.a4eeec91-f3b2-49c4-9fb2-65100ad579ab@github.com>

On Mon, 12 Aug 2024 07:31:09 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8337302: Undefined type variable results in null

test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 54:

> 52:         Class<?> missing = ByteCodeLoader.load("sample.MissingVariable", bytes);
> 53:         try {
> 54:             Type type = missing.getField("f").getGenericType();

Suggestion:

            Type type = missing.getDeclaredField("f").getGenericType();

This field is package-private, causing this test's failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1713823191

From alanb at openjdk.org  Mon Aug 12 14:05:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Aug 2024 14:05:33 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors
In-Reply-To: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
Message-ID: <ogkX4Q_VzLpcwit1g0V4xofVyxV2T7RXv65OG7N8p2A=.d75787f9-4c8a-41ee-be5a-a6b60a447490@github.com>

On Mon, 12 Aug 2024 13:41:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 381:

> 379:                     else
> 380:                         break;
> 381:                 } catch (Error ex) {            // rethrow VM errors

Part of me things this should be Throwable to allow for possible runtime exceptions when timed-parking virtual threads. There is a separate work needed to ensure a runtime exception is never throw but it would at least cancel here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1713841572

From sgehwolf at openjdk.org  Mon Aug 12 14:21:58 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Aug 2024 14:21:58 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: <TXlNz6vzjx1NgAPCzlTqR1MYihOI2iUnrigwX3DJhFI=.c769621e-e5c1-425f-b0ea-2020828c29b1@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

Please keep it open bot.

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

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

From redestad at openjdk.org  Mon Aug 12 14:27:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 14:27:36 GMT
Subject: RFR: 8336267: Method and Constructor signature parsing can be
 shared on the root object
In-Reply-To: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
References: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
Message-ID: <G_vjaLy2NV-5BhLZEJ8sLWCzrCYQ-E169oZK13vK87I=.fca5cf8b-bc13-4f00-8a4f-3133e8c9d0cf@github.com>

On Mon, 15 Jul 2024 04:05:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared.

There are a lot of transient volatile fields in this code. Could anything be done to make the various `Repository` classes more `final` and less `transient`/`volatile` here so that they can be safely published without synchronization, making it more obviously correct that we can safely pick them up from a shared root node (which might more typically be accessed concurrently and thus more exposed to races)?

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

PR Comment: https://git.openjdk.org/jdk/pull/20179#issuecomment-2284130733

From aboldtch at openjdk.org  Mon Aug 12 14:41:23 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Aug 2024 14:41:23 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <3m5N_Fh65MVy7vRvO0wq3qFlzxjbCLHhbTBJe8OJorw=.eb61b3bd-5aca-45cd-8e88-389ae86a599b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <OCv6QKq_A8dUaKUbnzSdEnlEqrMIcb6pUyLfObBFq-o=.1d78e62f-151c-403d-a291-fbab38c5f4d6@github.com>
 <3m5N_Fh65MVy7vRvO0wq3qFlzxjbCLHhbTBJe8OJorw=.eb61b3bd-5aca-45cd-8e88-389ae86a599b@github.com>
Message-ID: <RWR_R_rpAnhgo99Em5LpeLfzzxSYaS-1GUzX0sZFtOI=.1c3cdb68-e65d-4b7c-a3c0-77003689c279@github.com>

On Tue, 23 Jul 2024 13:20:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77:
>> 
>>> 75:   using ConcurrentTable = ConcurrentHashTable<Config, MEMFLAGS::mtObjectMonitor>;
>>> 76: 
>>> 77:   ConcurrentTable* _table;
>> 
>> So you have a class ObjectMonitorWorld, which references the ConcurrentTable, which, internally also has its actual table. This is 3 dereferences to get to the actual table, if I counted correctly. I'd try to eliminate the outermost ObjectMonitorWorld class, or at least make it a global flat structure instead of a reference to a heap-allocated object. I think, because this is a structure that is global and would exist throughout the lifetime of the Java program anyway, it might be worth figuring out how to do the actual ConcurrentHashTable flat in the global structure, too.
>
> This is a really good suggestion and might help a lot with the performance problems that we see with the table with heavily contended locking.  I think we should change this in a follow-on patch (which I'll work on).

I inlined the table in the surrounding object as it is a trivial change. 

Removing both indirections and creating static storage I would require more work (some conditional deferred creation, similar to an optional).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1713909990

From aboldtch at openjdk.org  Mon Aug 12 14:41:22 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Aug 2024 14:41:22 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v10]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <7BlK_mX-oDELURZVR0Haq7NCPUv18Q4Dk7Nblicdvn4=.1e06f523-0943-4dcd-9807-584d48b239ed@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

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

 - Remove extra whitespace in UseObjectMonitorTableTest.java
 - Inline _table
 - Rename ObjectMonitorWorld to ObjectMonitorTable
 - Update comment basicLock.hpp
 - Remove const for InflateCause parameters in lightweightSynchronizer
 - Use [inc/dec]_no_safepoint_count directly instead of a conditionally created NoSafepointVerifier
 - Remove unnecessary assert
 - Rename _table_count to _items_count
 - Revert instanceKlass.cpp comment change
 - Merge tag 'jdk-24+10' into JDK-8315884
   
   Added tag jdk-24+10 for changeset 16df9c33
 - ... and 26 more: https://git.openjdk.org/jdk/compare/0cb42d5f...92a88366

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/ebf11542..92a88366

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

  Stats: 42239 lines in 1406 files changed: 24413 ins; 11582 del; 6244 mod
  Patch: https://git.openjdk.org/jdk/pull/20067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067

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

From aboldtch at openjdk.org  Mon Aug 12 14:41:23 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Aug 2024 14:41:23 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <1FImJurji3MUi1rauLpFYqETg45LmnlxLrRijzXBukg=.7125982a-3507-4711-922e-2c7c9706d87c@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <1FImJurji3MUi1rauLpFYqETg45LmnlxLrRijzXBukg=.7125982a-3507-4711-922e-2c7c9706d87c@github.com>
Message-ID: <Qbj6XWV-yQATV7jlDXlb7YnWerQ3Q440B1IpedJ9o_M=.45c85e86-e6fc-43f5-a064-3dc7f6e9fd10@github.com>

On Wed, 17 Jul 2024 06:48:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Remove try_read
>>  - Add explicit to single parameter constructors
>>  - Remove superfluous access specifier
>>  - Remove unused include
>>  - Update assert message OMCache::set_monitor
>>  - Fix indentation
>>  - Remove outdated comment LightweightSynchronizer::exit
>>  - Remove logStream include
>>  - Remove strange comment
>>  - Fix javaThread include
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 60:
> 
>> 58: 
>> 59: // ConcurrentHashTable storing links from objects to ObjectMonitors
>> 60: class ObjectMonitorWorld : public CHeapObj<MEMFLAGS::mtObjectMonitor> {
> 
> OMWorld describes the project not the hashtable, this should be called ObjectMonitorTable or some such.

I agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1713909770

From aboldtch at openjdk.org  Mon Aug 12 14:41:23 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Aug 2024 14:41:23 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6]
In-Reply-To: <u2VLk8hKBH5V6331fMIPCwusNARMd_v-q_wL_7r0AOA=.99b9b9f1-ac37-4cb6-9ad0-4e019fe3c1fe@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <wRW8TABXS8LovbQ9qF8fosFD7FxYzpJdrG2LOvR6xDk=.19d62ec7-b2e4-41a1-8443-0480761288bf@github.com>
 <H1xx5Q5Wsuz3cl0FP1fwX4kL-jYdqbQ3skKwYcd54vo=.bd7abee8-0300-4253-a8b4-428ae8da1a0e@github.com>
 <u2VLk8hKBH5V6331fMIPCwusNARMd_v-q_wL_7r0AOA=.99b9b9f1-ac37-4cb6-9ad0-4e019fe3c1fe@github.com>
Message-ID: <2CVx8D98FuzuqhebUabz7AACiTl_pJCV6v1-cr6YzV0=.0d4dc6ca-c911-47d2-a13c-35686d7b3bf9@github.com>

On Mon, 15 Jul 2024 00:45:25 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477:
>> 
>>> 475:     if (obj->mark_acquire().has_monitor()) {
>>> 476:       if (_length > 0 && _contended_oops[_length-1] == obj) {
>>> 477:         // assert(VM_Version::supports_recursive_lightweight_locking(), "must be");
>> 
>> Uncomment or remove assert?
>
> Yeah not sure why it was ever uncommented. To me it seems like that the assert should be invariant. But will investigate.

I probably wanted to remove this. It is a tautology on all platforms but arm32 (or other with zero) right now. 
So removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1713909109

From aboldtch at openjdk.org  Mon Aug 12 14:41:23 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Aug 2024 14:41:23 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6]
In-Reply-To: <C-YWboakmVWLsm8fDywpBlSsKQyiB31SXInOEh2qY5o=.c954ee95-79f4-48cf-8a49-5ebabd1325c7@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <wRW8TABXS8LovbQ9qF8fosFD7FxYzpJdrG2LOvR6xDk=.19d62ec7-b2e4-41a1-8443-0480761288bf@github.com>
 <H1xx5Q5Wsuz3cl0FP1fwX4kL-jYdqbQ3skKwYcd54vo=.bd7abee8-0300-4253-a8b4-428ae8da1a0e@github.com>
 <u2VLk8hKBH5V6331fMIPCwusNARMd_v-q_wL_7r0AOA=.99b9b9f1-ac37-4cb6-9ad0-4e019fe3c1fe@github.com>
 <C-YWboakmVWLsm8fDywpBlSsKQyiB31SXInOEh2qY5o=.c954ee95-79f4-48cf-8a49-5ebabd1325c7@github.com>
Message-ID: <czummSlLDmbkSTjU8QiT1UJcVz9yFgjjhklsq1NCxY8=.02fed36d-7e92-465d-af40-4ef055f4116b@github.com>

On Tue, 23 Jul 2024 16:44:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I wanted to avoid having to add `NoSafepointVerifier` implementation details in the synchroniser code. I guess `ContinuationWrapper` already does this. 
>> 
>> Simply creating a `NoSafepointVerifier` when you expect no safepoint is more obvious to me, shows the intent better.
>
> This looks strange to me also, but it's be better than changing the no_safepoint_count directly, since NSV handles when the current thread isn't a JavaThread, so you'd have to duplicate that in this VerifyThreadState code too.
> 
>     NoSafepointVerifier::NoSafepointVerifier() : _thread(Thread::current()) {
>       if (_thread->is_Java_thread()) {
>         JavaThread::cast(_thread)->inc_no_safepoint_count();
>       }
>     }

It was the call to `[inc/dec]_no_safepoint_count` I wanted to avoid. But I will switch the conditionally created NSV to the `[inc/dec]_no_safepoint_count` calls instead.

>> Yeah. The only effect is has is that you cannot reassign the variable. It was the style taken from [synchronizer.hpp](https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.hpp) where all `InflateCause` parameters are const.
>
> Do you get this for inflate_fast_locked_object also?

Yes. I'll just remove the const from all lightweightSynchronizer parameters.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1713909267
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1713909417

From redestad at openjdk.org  Mon Aug 12 14:44:36 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 14:44:36 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
Message-ID: <WYraoMO1Asa64P3ijGuQVTXt_n0GLBo1H8voo5WQtBY=.cca7e72d-54a9-4225-a68f-31942ae60f6a@github.com>

On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

The unbound `CallSite`s should put up the concat classes for GC as soon as they go out of scope, so this doesn't even lean on the instigating classloader being GC'd. Excellent!

I think we should try to create a jtreg test from this. @DanHeidinga suggested offline that we could consider using `j.l.instrument.Instrumentation::getAllLoadedClasses()` - which should enumerate all classes, including hidden ones. Perhaps that's easy to mix in with your test above. 

But having verified that classes *can* be unloaded manually then perhaps we can file an RFE to have such a test worked out later and move ahead with this PR without such in-depth testing. I think such a test might have some challenges to get exactly right since you need to set it up and tune it so that unloading actually happens reliably on all platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2284174629

From asotona at openjdk.org  Mon Aug 12 15:12:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Aug 2024 15:12:38 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v5]
In-Reply-To: <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
 <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
Message-ID: <cp1x2IWrHbqUFysMwQs1RrYaDnqI6xyKkRy5jGwYIkY=.56eb6fe8-676b-48b1-9be6-5da60f67e5be@github.com>

On Fri, 2 Aug 2024 16:31:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
>> 2. Improved value specification to specify their tags.
>> 3. Improved value factories to return their specific types instead of `OfConstant`
>> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
>> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another failing test

Looks good to me, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20436#pullrequestreview-2233337319

From dfuchs at openjdk.org  Mon Aug 12 15:14:34 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Aug 2024 15:14:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <jeA6snOedvNP-wP-5Aw4RWMKAqJZ_SGFOZYTHCrDoNE=.27f8f41e-0637-446c-b2e7-7b0b98fa73a0@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

The changes to the java/net code look OK to me now. Thanks Brian. I am approving these changes - but please also get a Reviewer for the NIO and build side of these.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2233341338

From redestad at openjdk.org  Mon Aug 12 15:29:40 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 15:29:40 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
Message-ID: <Rz4UtnqxK639wgHRFmKeUaHv5LmUG2d9UnPZMyQe9RU=.18360ebd-44a0-404f-9873-7a84d82eb047@github.com>

On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

This is looking very good now, and I think we have something here that is good enough to replace the current default strategy across all arities.

Collected some nits, at least some of which should be fixed before approval. Thanks!

src/java.base/share/classes/java/lang/StringConcatHelper.java line 83:

> 81: 
> 82:         @ForceInline
> 83:         private final String concat(char value) {

These mostly help avoid a bit of class spinning on startup, right? I think it's fine to add these now, but we should perhaps consider ways to pre-generate concat shapes more deliberately (e.g. using `GenerateJLIClassesHelper/-Plugin` to pre-spin concat classes when jlinking an image) rather than manually stamping out code here. If small arity concats benefit in throughput tests from a subtly different code shape then that should be reflected in the code generator.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1073:

> 1071:      * Bytecode strategy.
> 1072:      *
> 1073:      * <p>This strategy emits StringBuilder chains as similar as possible

Outdated comment

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1082:

> 1080: 
> 1081:         static final ClassDesc CD_StringConcatHelper = ClassDesc.ofDescriptor("Ljava/lang/StringConcatHelper;");
> 1082:         static final ClassDesc CD_DecimalDigits      = ClassDesc.ofDescriptor("Ljdk/internal/util/DecimalDigits;");

Unused

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1099:

> 1097:         static final MethodTypeDesc MTD_String_Object   = MethodTypeDesc.of(CD_String, CD_Object);
> 1098: 
> 1099:         static final MethodTypeDesc MTD_GET_BYTES        = MethodTypeDesc.of(CD_void, CD_Array_byte, CD_int, CD_byte);

Unused

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1424:

> 1422:                         bufSlot       = cb.allocateLocal(TypeKind.from(byte[].class)),
> 1423:                         constantsSlot = cb.allocateLocal(TypeKind.from(String[].class)),
> 1424:                         suffixSlot    = cb.allocateLocal(TypeKind.from(String.class));

Suggestion:

                    int lengthSlot    = cb.allocateLocal(TypeKind.IntType),
                        coderSlot     = cb.allocateLocal(TypeKind.ByteType),
                        bufSlot       = cb.allocateLocal(TypeKind.ReferenceType),
                        constantsSlot = cb.allocateLocal(TypeKind.ReferenceType),
                        suffixSlot    = cb.allocateLocal(TypeKind.ReferenceType);

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1463:

> 1461:                             if (maybeUTF16(cl)) {
> 1462:                                 if (cl == char.class) {
> 1463:                                     cb.loadLocal(TypeKind.from(cl), cb.parameterSlot(i));

Suggestion:

                                    cb.loadLocal(TypeKind.CharType, cb.parameterSlot(i));

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1530:

> 1528:                         if (needStringOf(cl)) {
> 1529:                             paramSlot = stringSlots[i];
> 1530:                             kind = TypeKind.from(String.class);

Suggestion:

                            kind = TypeKind.ReferenceType;

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1679:

> 1677:                             methodTypeDesc = PREPEND_char;
> 1678:                         } else {
> 1679:                             kind = TypeKind.from(String.class);

Suggestion:

                            kind = TypeKind.ReferenceType;

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

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2233278967
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713928423
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713971752
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713973032
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713973228
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713959662
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713960801
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713962187
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1713963024

From dl at openjdk.org  Mon Aug 12 15:31:31 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 12 Aug 2024 15:31:31 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors
In-Reply-To: <ogkX4Q_VzLpcwit1g0V4xofVyxV2T7RXv65OG7N8p2A=.d75787f9-4c8a-41ee-be5a-a6b60a447490@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <ogkX4Q_VzLpcwit1g0V4xofVyxV2T7RXv65OG7N8p2A=.d75787f9-4c8a-41ee-be5a-a6b60a447490@github.com>
Message-ID: <5vuRhR3i35Y_L0MrlJJrgN3z27wLGB_lMOb54BsSubs=.7c1c3e96-8ea4-4ea0-ad1b-d10de08483e5@github.com>

On Mon, 12 Aug 2024 14:02:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors
>
> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 381:
> 
>> 379:                     else
>> 380:                         break;
>> 381:                 } catch (Error ex) {            // rethrow VM errors
> 
> Part of me things this should be Throwable to allow for possible runtime exceptions when timed-parking virtual threads. There is a separate work needed to ensure a runtime exception is never throw but it would at least cancel here.

Or use (Error | RuntimeException ex)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1713993675

From ihse at openjdk.org  Mon Aug 12 15:35:35 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Aug 2024 15:35:35 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <be3LT-XgLWSRAmNaJgWOEwhpTXZsHDYvrO1T8tg4tsw=.1f73b219-19d7-4222-8163-1e71d1de574f@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2233398100

From alanb at openjdk.org  Mon Aug 12 15:48:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Aug 2024 15:48:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

I plan to review this, please do not integrate this change until I get time to make sure that the placement and naming is workable in these areas.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2284326641

From duke at openjdk.org  Mon Aug 12 15:57:52 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 15:57:52 GMT
Subject: RFR: 8336856: Optimize String Concat [v40]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <VI_DCtUd21PJL1FlPdHasSXRMJxUznLsK42Btyq1Op0=.6a7d468a-1e1f-45a0-a7f5-802bc8053fab@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/9f483767..3dd9e658

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=38-39

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

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

From aboldtch at openjdk.org  Mon Aug 12 15:58:14 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 12 Aug 2024 15:58:14 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v11]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Missing DEBUG_ONLY

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/92a88366..d020bc9b

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

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

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

From alanb at openjdk.org  Mon Aug 12 16:00:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Aug 2024 16:00:33 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors
In-Reply-To: <5vuRhR3i35Y_L0MrlJJrgN3z27wLGB_lMOb54BsSubs=.7c1c3e96-8ea4-4ea0-ad1b-d10de08483e5@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <ogkX4Q_VzLpcwit1g0V4xofVyxV2T7RXv65OG7N8p2A=.d75787f9-4c8a-41ee-be5a-a6b60a447490@github.com>
 <5vuRhR3i35Y_L0MrlJJrgN3z27wLGB_lMOb54BsSubs=.7c1c3e96-8ea4-4ea0-ad1b-d10de08483e5@github.com>
Message-ID: <swQbH4A9ekX5OqZQY0s0NwpR4pAZMaLJ7455ZaUJhnc=.a3c2f27b-aae4-46db-8740-26fac8c4cc2c@github.com>

On Mon, 12 Aug 2024 15:28:47 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 381:
>> 
>>> 379:                     else
>>> 380:                         break;
>>> 381:                 } catch (Error ex) {            // rethrow VM errors
>> 
>> Part of me things this should be Throwable to allow for possible runtime exceptions when timed-parking virtual threads. There is a separate work needed to ensure a runtime exception is never throw but it would at least cancel here.
>
> Or use (Error | RuntimeException ex)?

That would be okay too as there are no checked exceptions here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1714039963

From vklang at openjdk.org  Mon Aug 12 16:05:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 12 Aug 2024 16:05:31 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors
In-Reply-To: <swQbH4A9ekX5OqZQY0s0NwpR4pAZMaLJ7455ZaUJhnc=.a3c2f27b-aae4-46db-8740-26fac8c4cc2c@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <ogkX4Q_VzLpcwit1g0V4xofVyxV2T7RXv65OG7N8p2A=.d75787f9-4c8a-41ee-be5a-a6b60a447490@github.com>
 <5vuRhR3i35Y_L0MrlJJrgN3z27wLGB_lMOb54BsSubs=.7c1c3e96-8ea4-4ea0-ad1b-d10de08483e5@github.com>
 <swQbH4A9ekX5OqZQY0s0NwpR4pAZMaLJ7455ZaUJhnc=.a3c2f27b-aae4-46db-8740-26fac8c4cc2c@github.com>
Message-ID: <GZtK9zRoRTCbKcr-RZkwuRep6s5cXX1mMu0gOojQQwk=.ad50bdae-d79c-4915-8ad0-b6761727675b@github.com>

On Mon, 12 Aug 2024 15:57:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Or use (Error | RuntimeException ex)?
>
> That would be okay too as there are no checked exceptions here.

@AlanBateman If we really want it airtight I think we need to catch Throwable and sneaky-rethrow it? ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1714047111

From vklang at openjdk.org  Mon Aug 12 16:11:46 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 12 Aug 2024 16:11:46 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
Message-ID: <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>

> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

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

  Catching both Error and RuntimeException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20548/files
  - new: https://git.openjdk.org/jdk/pull/20548/files/40310fe3..70f8b496

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

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

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

From vklang at openjdk.org  Mon Aug 12 16:11:46 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 12 Aug 2024 16:11:46 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
Message-ID: <1qYJBG2Rf-toxOh9wT8RpAtByDkPjZW-oOYJcdD0nEE=.70eba6f7-87e0-47bd-abab-af1b17f4035d@github.com>

On Mon, 12 Aug 2024 16:08:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catching both Error and RuntimeException

src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 381:

> 379:                     else
> 380:                         break;
> 381:                 } catch (Error | RuntimeException ex) {

@DougLea @AlanBateman Changed to Error | RuntimeException here and for AQS

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1714053732

From duke at openjdk.org  Mon Aug 12 16:16:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 16:16:10 GMT
Subject: RFR: 8336856: Optimize String Concat [v41]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - fix comments
 - remove unused code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/3dd9e658..9beb8c6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=40
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=39-40

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

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

From never at openjdk.org  Mon Aug 12 16:23:31 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 12 Aug 2024 16:23:31 GMT
Subject: RFR: 8338060: jdk/internal/util/ReferencedKeyTest should be more
 robust
In-Reply-To: <qfbAbYOckNgamO32M_hr_eihCimaxEXLel1g_TXLaWs=.3a6d06b0-e6fb-4eb6-8644-34a45f4ac6a5@github.com>
References: <qfbAbYOckNgamO32M_hr_eihCimaxEXLel1g_TXLaWs=.3a6d06b0-e6fb-4eb6-8644-34a45f4ac6a5@github.com>
Message-ID: <hv-P2v9oSdgcxEeKODeuAGSLihAlbNrMwqDcsPBsxOY=.fb869477-cc65-4ff5-9d3f-41e7009e99c8@github.com>

On Fri, 9 Aug 2024 15:54:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Addressing latent issues with ReferencedKeyTest
> - During the `methods()` tests the keys should be strongly held to avoid inadvertent GC collection and subsequent test failures (JDK-8336926)
> - Merge changes from Valhalla to use String (identity objects) for keys instead of Integer and Long that are value objects. (JDK-8336390)

The changes look good to me.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20527#pullrequestreview-2233515552

From duke at openjdk.org  Mon Aug 12 16:55:36 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 16:55:36 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <Rz4UtnqxK639wgHRFmKeUaHv5LmUG2d9UnPZMyQe9RU=.18360ebd-44a0-404f-9873-7a84d82eb047@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
 <Rz4UtnqxK639wgHRFmKeUaHv5LmUG2d9UnPZMyQe9RU=.18360ebd-44a0-404f-9873-7a84d82eb047@github.com>
Message-ID: <Z54zwRzLnXghtgkP2id47GI6LhEz4sqs_P9WhNUc0dI=.7d3935b3-ea0c-4e76-a28b-86d682ae3add@github.com>

On Mon, 12 Aug 2024 14:47: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:
>> 
>>   fix comments
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 83:
> 
>> 81: 
>> 82:         @ForceInline
>> 83:         private final String concat(char value) {
> 
> These mostly help avoid a bit of class spinning on startup, right? I think it's fine to add these now, but we should perhaps consider ways to pre-generate concat shapes more deliberately (e.g. using `GenerateJLIClassesHelper/-Plugin` to pre-spin concat classes when jlinking an image) rather than manually stamping out code here. If small arity concats benefit in throughput tests from a subtly different code shape then that should be reflected in the code generator.

The current implementation generates length and coder methods, which slows down the startup. The built-in concat1 is to improve the startup speed. 1 parameter is a very common scenario. The current implementation does not need to add more classes. It is a lightweight implementation, so I keep it. In addition, I also need to learn how GenerateJLIClassesHelper works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714106975

From dl at openjdk.org  Mon Aug 12 17:12:41 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 12 Aug 2024 17:12:41 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
Message-ID: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>

The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8338146
 - Copyedit
 - Address review suggestions
 - Initial re-implementation

Changes: https://git.openjdk.org/jdk/pull/20554/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20554&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338146
  Stats: 423 lines in 3 files changed: 94 ins; 172 del; 157 mod
  Patch: https://git.openjdk.org/jdk/pull/20554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20554/head:pull/20554

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

From bpb at openjdk.org  Mon Aug 12 17:14:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 Aug 2024 17:14:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>
Message-ID: <oaXC9bmYWzhk0cmHn2O7K8SySeDsjNCsK-3h790GtTs=.20455ccb-59a5-4264-9818-072ae6d42fc4@github.com>

On Mon, 12 Aug 2024 15:46:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> please do not integrate this change until I get time

Sure, of course I will not.

Thanks to @magicus and @dfuch for helping to make it better.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2284529067

From redestad at openjdk.org  Mon Aug 12 17:21:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 17:21:44 GMT
Subject: RFR: 8336856: Optimize String Concat [v39]
In-Reply-To: <Z54zwRzLnXghtgkP2id47GI6LhEz4sqs_P9WhNUc0dI=.7d3935b3-ea0c-4e76-a28b-86d682ae3add@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <TTLP4O3gQDHrIfCDqe1xmgcsajxs8CrgnMreXhz2ZRI=.09bc419f-ef5a-4135-ab71-3ba64ae6ee71@github.com>
 <Rz4UtnqxK639wgHRFmKeUaHv5LmUG2d9UnPZMyQe9RU=.18360ebd-44a0-404f-9873-7a84d82eb047@github.com>
 <Z54zwRzLnXghtgkP2id47GI6LhEz4sqs_P9WhNUc0dI=.7d3935b3-ea0c-4e76-a28b-86d682ae3add@github.com>
Message-ID: <04q_rLzGPOYWx-KDlQOYq20I0D4z0ovgkZrn8Mi3J98=.72186f03-23b0-41d2-9a3a-dc38c1e2c875@github.com>

On Mon, 12 Aug 2024 16:52:53 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 83:
>> 
>>> 81: 
>>> 82:         @ForceInline
>>> 83:         private final String concat(char value) {
>> 
>> These mostly help avoid a bit of class spinning on startup, right? I think it's fine to add these now, but we should perhaps consider ways to pre-generate concat shapes more deliberately (e.g. using `GenerateJLIClassesHelper/-Plugin` to pre-spin concat classes when jlinking an image) rather than manually stamping out code here. If small arity concats benefit in throughput tests from a subtly different code shape then that should be reflected in the code generator.
>
> The current implementation generates length and coder methods, which slows down the startup. The built-in concat1 is to improve the startup speed. 1 parameter is a very common scenario. The current implementation does not need to add more classes. It is a lightweight implementation, so I keep it. In addition, I also need to learn how GenerateJLIClassesHelper works.

Right, what you have is OK here. I'll think a bit about a follow-up to integrate with the plugin to support arbitrary concat class pre-generation in jlink. This is something I had hoped to get done in the previous implementation, but I ran into a few road blocks there and then had to work on other things. With this implementation doing pre-generation will likely be way more straightforward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714135667

From redestad at openjdk.org  Mon Aug 12 17:39:38 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 17:39:38 GMT
Subject: RFR: 8336856: Optimize String Concat [v41]
In-Reply-To: <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>
Message-ID: <vt7_zv_0wwBUdoXYd_xzOmZR4xN6GGkxEhy23PIXayk=.39787fa9-a377-4d9e-9925-34d8b3a34db6@github.com>

On Mon, 12 Aug 2024 16:16:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix comments
>  - remove unused code

Marked as reviewed by redestad (Reviewer).

I suggest renaming this RFE to something like "Implement efficient hidden class strategy for String concatenation"

I'll approve in a second, but will first mark this as needing an additional Reviewer since part of the code here is mine and I can't be the Reviewer of my own code. ?

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

PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2233668699
PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2284571671

From duke at openjdk.org  Mon Aug 12 17:44:50 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 17:44:50 GMT
Subject: RFR: 8336856: Optimize String Concat [v42]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <u-6sYMMnR65op_MSs_4OomTFXt3c2VpOKMM64MJXCc0=.c3ff2cdd-8890-485e-a935-41627eadefb6@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/9beb8c6a..8a6f32ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=40-41

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

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

From rriggs at openjdk.org  Mon Aug 12 18:20:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Aug 2024 18:20:34 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <-hWR8SELSSfdXbSKq5oeo7dN-w1Hi8ClUbteaSuttUg=.6bfb1f64-116d-4b0d-94e7-9657b40c2767@github.com>

On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

The tests should include serializing some sample JDK classes that include a hierarchy of 2-4 levels.
I would help fles any interactions in the sequencing of calling the default serialization for each of a concrete class's supertypes.

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

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2284641550

From szaldana at openjdk.org  Mon Aug 12 18:35:42 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Mon, 12 Aug 2024 18:35:42 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
Message-ID: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>

Hi all, 

This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 

Thanks, 
Sonia

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8338014
 - Copyright update
 - 8338014: Improve usage of @jvms tags in class file API

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

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

From duke at openjdk.org  Mon Aug 12 18:38:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 18:38:38 GMT
Subject: RFR: 8336856: Optimize String Concat [v42]
In-Reply-To: <u-6sYMMnR65op_MSs_4OomTFXt3c2VpOKMM64MJXCc0=.c3ff2cdd-8890-485e-a935-41627eadefb6@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <u-6sYMMnR65op_MSs_4OomTFXt3c2VpOKMM64MJXCc0=.c3ff2cdd-8890-485e-a935-41627eadefb6@github.com>
Message-ID: <TF7FQpeSpxj5qM8M9S5jQUAeY--xNT1NGVmBVwdwpTQ=.409facff-e722-416e-b1d8-4be4e4678300@github.com>

On Mon, 12 Aug 2024 17:44:50 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

Should we change the title of the PR to `Implementing an efficient string concatenation hidden class strategy based on ClassFile API`?

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2284670355

From darcy at openjdk.org  Mon Aug 12 18:47:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Aug 2024 18:47:37 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
Message-ID: <TBrakFUTbn8N3TWQEG4ArUqQDsFwScbsFslbeBMMtQg=.7b97f376-3883-4195-9688-95eef9785d6f@github.com>

On Thu, 8 Aug 2024 18:15:29 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
> 
> Thanks, 
> Sonia

Looks fine; increasing review count to also include someone who more directly maintains this API.

If you haven't done so already, I recommend also doing a quick check for an analagous issue with `@jls` tags in this API.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20513#pullrequestreview-2233780253

From liach at openjdk.org  Mon Aug 12 18:47:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 18:47:43 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
Message-ID: <vDp0eNtXauwnawTkVN9U2wANfkJDVZfXE1S-CW9Ew6E=.e384b6f7-d7ed-4408-bbeb-f87a929a4817@github.com>

On Thu, 8 Aug 2024 18:15:29 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
> 
> Thanks, 
> Sonia

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/lang/classfile/Attribute.java line 69:

> 67: 
> 68: /**
> 69:  * Models a classfile attribute JVMS {@jvms 4.7}.  Many, though not all, subtypes of

Suggestion:

 * Models a classfile attribute (JVMS {@jvms 4.7}).  Many, though not all, subtypes of

Same as for all other attributes.

src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java line 63:

> 61: 
> 62: /**
> 63:  * Models an annotation on a type use, as defined in JVMS {@jvms 4.7.19} and JVMS {@jvms 4.7.20}.

Suggestion:

 * Models an annotation on a type use, as defined in JVMS {@jvms 4.7.19} and {@jvms 4.7.20}.

src/java.base/share/classes/java/lang/classfile/attribute/SyntheticAttribute.java line 37:

> 35: 
> 36: /**
> 37:  * Models the {@code Synthetic} attribute JVMS {@jvms 4.7.8}, which can appear on

These occurrences should be `(JVMS {@jvms x.x.x})`.

src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 368:

> 366:      * returned.
> 367:      *
> 368:      * @param refKind the reference kind of the method handle JVMS {@jvms 4.4.8}

Same, these occurrences are not part of a sentence, so enclose in parentheses like `(JVMS {@jvms 4.4.8})`

src/java.base/share/classes/java/lang/classfile/package-info.java line 1:

> 1: /*

These 2 changes are redundant and wrong. Please review your changes before submitting it after mechanical replacements.

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

PR Review: https://git.openjdk.org/jdk/pull/20513#pullrequestreview-2233779488
PR Review Comment: https://git.openjdk.org/jdk/pull/20513#discussion_r1714226622
PR Review Comment: https://git.openjdk.org/jdk/pull/20513#discussion_r1714226304
PR Review Comment: https://git.openjdk.org/jdk/pull/20513#discussion_r1714224992
PR Review Comment: https://git.openjdk.org/jdk/pull/20513#discussion_r1714225652
PR Review Comment: https://git.openjdk.org/jdk/pull/20513#discussion_r1714224171

From redestad at openjdk.org  Mon Aug 12 18:49:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 18:49:43 GMT
Subject: RFR: 8336856: Optimize String Concat [v42]
In-Reply-To: <TF7FQpeSpxj5qM8M9S5jQUAeY--xNT1NGVmBVwdwpTQ=.409facff-e722-416e-b1d8-4be4e4678300@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <u-6sYMMnR65op_MSs_4OomTFXt3c2VpOKMM64MJXCc0=.c3ff2cdd-8890-485e-a935-41627eadefb6@github.com>
 <TF7FQpeSpxj5qM8M9S5jQUAeY--xNT1NGVmBVwdwpTQ=.409facff-e722-416e-b1d8-4be4e4678300@github.com>
Message-ID: <CbvgmzzHiO2AdhKphjM0UDJJUluRHrPgIf13hl7pKc0=.27210a7b-17de-4c3e-b9e5-b32126da2fc4@github.com>

On Mon, 12 Aug 2024 18:35:45 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Should we change the title of the PR to `Implementing an efficient string concatenation hidden class strategy based on ClassFile API`?

Yes, or something shorter like `"8336856: Efficient hidden class-based string concatenation strategy"`. 

(The use of ClassFile API is a choice; using hidden classes is necessary for this to be on par with the MH-heavy baseline)

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2284689833

From sgehwolf at openjdk.org  Mon Aug 12 18:49:46 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 12 Aug 2024 18:49:46 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v19]
In-Reply-To: <UJEH6O85W5S7EPcsD74dXIcXqmYamjdsDuKeSb0ID-Y=.492ccb0e-85eb-41d4-a9ad-3f4fc47a1bb4@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <UJEH6O85W5S7EPcsD74dXIcXqmYamjdsDuKeSb0ID-Y=.492ccb0e-85eb-41d4-a9ad-3f4fc47a1bb4@github.com>
Message-ID: <al8-84qIReC0un3wrpfUBFS8d2Xbfzxc4yqCVaWkzlY=.958d09a8-afc1-41fb-8dce-e6adb9823dee@github.com>

On Tue, 30 Jul 2024 07:47:55 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Fix by  Severin Gehwolf.
>> Testcase by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Inline adjust_controller() twice
>  - Revert "Unify 4 copies of adjust_controller()"
>    
>    This reverts commit 77a81d07d74c8ae9bf34bfd8df9bcaca451ede9a.

Changes seem OK. The test needs some cleanup, though.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 103:

> 101:             Asserts.assertEQ(0, exitValue, "Process returned unexpected exit code: " + exitValue);
> 102:             return output;
> 103:         }

This could be simplified to just `ProcessTools.executeProcess(new ProcessBuilder(args));`

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 120:

> 118:             args.add(jdkTool);
> 119:             args.add("-cp");
> 120:             args.add(System.getProperty("java.class.path"));

Should probably be `test.classes` instead of `java.class.path`.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 145:

> 143:                 }
> 144:                 throw e;
> 145:             }

This should no longer be needed since we have the `@requires` line.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 193:

> 191:             System.err.println(LINE_DELIM + " " + (isCgroup2 ? "cgroup2" : "cgroup1") + " mount point: " + sysFsCgroup);
> 192:             memory_max_filename = isCgroup2 ? "memory.max" : "memory.limit_in_bytes";
> 193:             Files.writeString(Path.of(sysFsCgroup + "/" + CGROUP_OUTER + "/" + memory_max_filename), "" + MEMORY_MAX_OUTER);

This still doesn't work on cgv1 (hybrid). The reg-ex pattern matching is wrong. I'd suggest to simplify this by using `cgget` and `cgset` with forked processes. Something like this (depending on the version use `memory.max` or `memory.limit_in_bytes`):


$ cgcreate -g memory:/jdktest128331
$ cgcreate -g memory:/jdktest128331/inner
$ cgset -r memory.limit_in_bytes=512000 /jdktest128331/inner
$ cgget -n -v -r memory.limit_in_bytes /jdktest128331/inner
512000

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 210:

> 208:         public Limits hook(List<String> cgexec) throws IOException {
> 209:             // CgroupV1Subsystem::read_memory_limit_in_bytes considered hierarchical_memory_limit only when inner memory.limit_in_bytes is unlimited.
> 210:             Files.writeString(Path.of(sysFsCgroup + "/" + CGROUP_OUTER + "/" + CGROUP_INNER + "/" + memory_max_filename), "" + MEMORY_MAX_INNER);

This should be done using `cgset`.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 217:

> 215: 
> 216:             // KFAIL - verify the CgroupSubsystem::initialize_hierarchy() and jdk.internal.platform.CgroupSubsystem.initializeHierarchy() bug
> 217:             // TestTwoLimits does not see the lower MEMORY_MAX_OUTER limit.

Remove this obsolete(?) comment.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 247:

> 245:             self_verbose.add("-version");
> 246:             pSystem(self_verbose);
> 247:         }

Instead of disabling the memory controller that way, consider creating only the cpu controller (using `cgcreate`) and test for memory limits?

test/jtreg-ext/requires/VMProps.java line 141:

> 139:         map.put("vm.flagless", this::isFlagless);
> 140:         map.put("jdk.foreign.linker", this::jdkForeignLinker);
> 141:         map.put("vm.cgroup.tools", this::cgroupTools);

Why the `vm` prefix? Could be just `cgroup.tools` no? This isn't a JVM property.

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

PR Review: https://git.openjdk.org/jdk/pull/17198#pullrequestreview-2233709616
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714213497
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714218948
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714219641
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714181908
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714221143
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714221815
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714226775
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1714228598

From jjg at openjdk.org  Mon Aug 12 18:52:31 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 12 Aug 2024 18:52:31 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <TBrakFUTbn8N3TWQEG4ArUqQDsFwScbsFslbeBMMtQg=.7b97f376-3883-4195-9688-95eef9785d6f@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <TBrakFUTbn8N3TWQEG4ArUqQDsFwScbsFslbeBMMtQg=.7b97f376-3883-4195-9688-95eef9785d6f@github.com>
Message-ID: <FEUtyzibuybNf1wAzhQYDO4R4yQmNiRIIl9_QPpWu5M=.2f5c42e2-d97c-4dd1-8475-30b03eb9cfde@github.com>

On Mon, 12 Aug 2024 18:42:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> Looks fine; increasing review count to also include someone who more directly maintains this API.
> 
> If you haven't done so already, I recommend also doing a quick check for an analagous issue with `@jls` tags in this API.

@jddarcy Perhaps we should revisit the inline forms of `@jls` and `@jvms` tags to come up with similar and more consistent usage.

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

PR Comment: https://git.openjdk.org/jdk/pull/20513#issuecomment-2284691419

From darcy at openjdk.org  Mon Aug 12 18:52:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Aug 2024 18:52:33 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <vDp0eNtXauwnawTkVN9U2wANfkJDVZfXE1S-CW9Ew6E=.e384b6f7-d7ed-4408-bbeb-f87a929a4817@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <vDp0eNtXauwnawTkVN9U2wANfkJDVZfXE1S-CW9Ew6E=.e384b6f7-d7ed-4408-bbeb-f87a929a4817@github.com>
Message-ID: <ZexR3BPR7lMX-rlcQvEYlehLirIU0l8WGq7fkNR1itU=.d2bb0944-f1b5-4e97-aa95-269a06d5cf70@github.com>

On Mon, 12 Aug 2024 18:42:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> src/java.base/share/classes/java/lang/classfile/attribute/SyntheticAttribute.java line 37:
> 
>> 35: 
>> 36: /**
>> 37:  * Models the {@code Synthetic} attribute JVMS {@jvms 4.7.8}, which can appear on
> 
> These occurrences should be `(JVMS {@jvms x.x.x})`.

I agree that structure would be better and more consistent with `@jmvs` usage elsewhere in core libs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20513#discussion_r1714232145

From liach at openjdk.org  Mon Aug 12 18:57:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 18:57:38 GMT
Subject: RFR: 8336856: Optimize String Concat [v41]
In-Reply-To: <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>
Message-ID: <hGyjZtS5voR9rdME_ROO-rYMtNRdaA2kq3N8njO9GxA=.e1ee79e4-9e55-4b01-a00a-7e27cc2b02cd@github.com>

On Mon, 12 Aug 2024 16:16:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix comments
>  - remove unused code

src/java.base/share/classes/java/lang/StringConcatHelper.java line 48:

> 46:         final int length;
> 47:         final byte coder;
> 48:         protected StringConcatBase(String[] constants) {

Suggestion:

        StringConcatBase(String[] constants) {

Package-private class. Also this feels a bit weird that this is not abstract, a bit of code smell...

src/java.base/share/classes/java/lang/invoke/MemberName.java line 961:

> 959:                     return null;
> 960:                 }
> 961:                 if (allowedModes != LM_TRUSTED) {

? You must revert changes to permission checks before a potential integration. This can involve security and massively increase the review complexity and risk of conformance violation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714075309
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714070528

From liach at openjdk.org  Mon Aug 12 18:57:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 18:57:40 GMT
Subject: RFR: 8336856: Optimize String Concat [v42]
In-Reply-To: <u-6sYMMnR65op_MSs_4OomTFXt3c2VpOKMM64MJXCc0=.c3ff2cdd-8890-485e-a935-41627eadefb6@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <u-6sYMMnR65op_MSs_4OomTFXt3c2VpOKMM64MJXCc0=.c3ff2cdd-8890-485e-a935-41627eadefb6@github.com>
Message-ID: <ahL6yZzwvVUPrWhoUD6IHJiCr3mwWfBLiG-I6Xsbu70=.1274d99d-837d-4c1a-812b-f5f8724d73c6@github.com>

On Mon, 12 Aug 2024 17:44:50 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments

src/java.base/share/classes/java/lang/StringConcatHelper.java line 61:

> 59: 
> 60:         @ForceInline
> 61:         private String concat0(String value) {

I think we should make the base class abstract and add a `final class StringConcat1` with all these single-argument concat private methods, and that class is exposed via JLA instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714231500

From liach at openjdk.org  Mon Aug 12 18:57:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 18:57:40 GMT
Subject: RFR: 8336856: Optimize String Concat [v11]
In-Reply-To: <LlaO7c_2QFHelzz9yTqJV2fTZd39KMstCQ1j52lRjjQ=.1fe1c20c-cdc5-4a6d-a8c2-c286221c7bb2@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Pv6KtpPuYVyscqbphdhEVpdo4HV8-TgFEjPAS8AqBaM=.bf1b245f-a6a0-4b17-9c50-5f4af1af3b0c@github.com>
 <LmGxUohf1cX0gaLBaCsMHFF8KJ6b7xO3fCbxcmPhh30=.3132b89a-82eb-4ba2-92dd-38863bf0db4d@github.com>
 <R4wNnmYhi6J_oIVQ0wn3td4DepzAWhIi1VYQeySbYuI=.d3fcdc16-c810-4cf9-a3da-11263f335e3f@github.com>
 <qLjsxrtkqZOfyRqnonXUxp03SjvpwfTD9BU-FKZFmUo=.81d78036-d848-4f52-aca4-8405bce46dfc@github.com>
 <LlaO7c_2QFHelzz9yTqJV2fTZd39KMstCQ1j52lRjjQ=.1fe1c20c-cdc5-4a6d-a8c2-c286221c7bb2@github.com>
Message-ID: <YSgljej4Dl8TY2FBTL4lCs3SDhs8zQspaqLghKUoNwI=.9be0e5d6-328b-4ca0-a164-f30005b111cf@github.com>

On Thu, 25 Jul 2024 00:43:09 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The solution is to call `.erase()` on the input method handle, and call `viewAsType` on the result method handle.
>
> Sorry, I don't understand what you mean. The following code can't solve the above build error
> 
> 
> public static CallSite makeConcatWithConstants() {
> // line 383
>                 return new ConstantCallSite(
>                         SimpleStringBuilderStrategy.generate(lookup, concatType, constantStrings)
>                                 .viewAsType(concatType, true));

Even something like `new Lookup(String.class)` is better for encapsulation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714233628

From darcy at openjdk.org  Mon Aug 12 18:58:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 12 Aug 2024 18:58:38 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <TBrakFUTbn8N3TWQEG4ArUqQDsFwScbsFslbeBMMtQg=.7b97f376-3883-4195-9688-95eef9785d6f@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <TBrakFUTbn8N3TWQEG4ArUqQDsFwScbsFslbeBMMtQg=.7b97f376-3883-4195-9688-95eef9785d6f@github.com>
Message-ID: <APZF5bj6Q8rtmnY_QjVb14hmQ7IbrXe_mKf3Mi8IHM8=.51b009b5-ca58-4362-b0a7-52268de17597@github.com>

On Mon, 12 Aug 2024 18:42:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> Looks fine; increasing review count to also include someone who more directly maintains this API.
> 
> If you haven't done so already, I recommend also doing a quick check for an analagous issue with `@jls` tags in this API.

> @jddarcy Perhaps we should revisit the inline forms of `@jls` and `@jvms` tags to come up with similar and more consistent usage.

Certainly a variant do generate the most common usage pattern would be helpful -- brainstorming --

`{@jvms cite 1.2.3}`

to generate

(JVMVS 1.2.3)

where "1.2.3" was the expected link.

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

PR Comment: https://git.openjdk.org/jdk/pull/20513#issuecomment-2284704350

From coleenp at openjdk.org  Mon Aug 12 18:58:44 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Aug 2024 18:58:44 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v11]
In-Reply-To: <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>
Message-ID: <5r33aU_dXazxa8Lahw6JCsbt5aLwcjCp1N6vkcTm_yI=.f47905ec-aa19-447f-ba28-658c6c94003a@github.com>

On Mon, 12 Aug 2024 15:58:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing DEBUG_ONLY

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:

> 339: };
> 340: 
> 341: ObjectMonitorTable* LightweightSynchronizer::_omworld = nullptr;

I preferred my version where ObjectMonitorTable was AllStatic which gets rid of _omworld-> everwhere, but the internal table is the pointer.  You can remove more omworld names also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714238075

From duke at openjdk.org  Mon Aug 12 19:08:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 19:08:10 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v43]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <4rwPsxI4OphqelqkRTYgjzNuL4pqnBe8npxPOR0Knto=.f6cfa754-20ce-4030-a1cc-06fb03b1623c@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  Update src/java.base/share/classes/java/lang/StringConcatHelper.java
  
  Co-authored-by: Chen Liang <liach at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/8a6f32ba..c7dacccc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=41-42

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

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

From duke at openjdk.org  Mon Aug 12 19:13:34 2024
From: duke at openjdk.org (jengebr)
Date: Mon, 12 Aug 2024 19:13:34 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]
In-Reply-To: <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
Message-ID: <nErKWKncugAvz2mOO4j7EqyBaOGt7r8qUhshDC2HGAk=.3175d8d6-fd72-4418-917c-6006aa28fbfb@github.com>

On Thu, 20 Jun 2024 19:17:25 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:
> 
>   Expanding coverage of remove()

Still waiting for reviews.

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

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

From duke at openjdk.org  Mon Aug 12 19:15:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 19:15:14 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v44]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <UQvJv7jDQ1NXZGUkcHUcN2mTFU0fcQn47KdAkzFE0XU=.a3ded99e-2e01-4372-8040-fbfa799dab5a@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  StringConcat1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/c7dacccc..2fdd6614

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=42-43

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

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

From liach at openjdk.org  Mon Aug 12 19:18:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 19:18:32 GMT
Subject: RFR: 8336267: Method and Constructor signature parsing can be
 shared on the root object
In-Reply-To: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
References: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
Message-ID: <1b0egvdGpzSxipVscF3YJtJodecZsLFDrtuMCUPi-4I=.8e4abcf4-6d12-4ad4-82e8-863de9811c38@github.com>

On Mon, 15 Jul 2024 04:05:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared.

Yep, there's #19281 exactly for that purpose: https://github.com/openjdk/jdk/pull/19281/files#diff-5106bd8a6cf3197be7eaee467983c8992981a615bedb66efa50dd97c60cb0041 Uses `volatile @Stable` instead (or just `StableValue` once #19625 is ready)

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

PR Comment: https://git.openjdk.org/jdk/pull/20179#issuecomment-2284736868

From liach at openjdk.org  Mon Aug 12 19:27:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 19:27:35 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
Message-ID: <G9_w97EsbHKJ_r7uLf4gpf_E_vdOHG8kW_VP6qEJ14M=.f759252e-8ccc-4b84-b5c9-455bb370bfb8@github.com>

On Thu, 8 Aug 2024 18:15:29 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
> 
> Thanks, 
> Sonia

I think we can just make `{@jvms }` inline versions emit JVMS and JLS prefix if there's some other text in the body, like `{@jvms 4.7.20 The {@code RuntimeVisibleTypeAnnotations} attribute}` may render

JVMS 4.7.20 The `RuntimeVisibleTypeAnnotations` attribute

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

PR Comment: https://git.openjdk.org/jdk/pull/20513#issuecomment-2284750345

From rriggs at openjdk.org  Mon Aug 12 19:31:42 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Aug 2024 19:31:42 GMT
Subject: Integrated: 8338060: jdk/internal/util/ReferencedKeyTest should be
 more robust
In-Reply-To: <qfbAbYOckNgamO32M_hr_eihCimaxEXLel1g_TXLaWs=.3a6d06b0-e6fb-4eb6-8644-34a45f4ac6a5@github.com>
References: <qfbAbYOckNgamO32M_hr_eihCimaxEXLel1g_TXLaWs=.3a6d06b0-e6fb-4eb6-8644-34a45f4ac6a5@github.com>
Message-ID: <mAKQmMMQn2qfOzq6wvJav5lxvNCKbUkKc3QfeetdkMQ=.3705ce88-46c6-4edd-895c-31f7d2864e51@github.com>

On Fri, 9 Aug 2024 15:54:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Addressing latent issues with ReferencedKeyTest
> - During the `methods()` tests the keys should be strongly held to avoid inadvertent GC collection and subsequent test failures (JDK-8336926)
> - Merge changes from Valhalla to use String (identity objects) for keys instead of Integer and Long that are value objects. (JDK-8336390)

This pull request has now been integrated.

Changeset: b93b74e3
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b93b74e3ebd220e94fb5e33d2ebc62181db97bb0
Stats:     80 lines in 1 file changed: 26 ins; 4 del; 50 mod

8338060: jdk/internal/util/ReferencedKeyTest should be more robust

Reviewed-by: never

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

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

From duke at openjdk.org  Mon Aug 12 19:31:41 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 19:31:41 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v23]
In-Reply-To: <g1hKmps1NesHfJ3POJKEW12a1IQzUiQ71QoTH9LtplM=.0661a4d1-c41f-47c8-96cc-c6e9b775641d@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
 <g1hKmps1NesHfJ3POJKEW12a1IQzUiQ71QoTH9LtplM=.0661a4d1-c41f-47c8-96cc-c6e9b775641d@github.com>
Message-ID: <5-llG-cszAxW60JdHWM3u9lF3xcFtUngOHh9DrQFuMw=.9ba9bbd4-8710-4750-a1b8-02dd5ef936f6@github.com>

On Fri, 2 Aug 2024 04:26:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix performance regression caused by args.erase()
>
> Because we load the class in the bootstrap loader so it can access java.lang; means our class cannot see user classes as a result.

@liach 
If MethodHandles.Lookup.IMPL_LOOKUP is not used, the following error will be reported

Exception in thread "main" java.lang.BootstrapMethodError: bootstrap method initialization exception
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:191)
	at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:316)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:275)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:265)
	at build.tools.symbolgenerator.CreateSymbols.doWrite(CreateSymbols.java:928)
	at build.tools.symbolgenerator.CreateSymbols.writeModule(CreateSymbols.java:859)
	at build.tools.symbolgenerator.CreateSymbols.writeModulesForVersions(CreateSymbols.java:823)
	at build.tools.symbolgenerator.CreateSymbols.createSymbols(CreateSymbols.java:265)
	at build.tools.symbolgenerator.CreateSymbols.main(CreateSymbols.java:4791)
Caused by: java.lang.invoke.StringConcatException: Generator failed
	at java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:403)
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:102)
	... 8 more
Caused by: java.lang.invoke.StringConcatException: Exception while spinning the class
	at java.base/java.lang.invoke.StringConcatFactory$InlineHiddenClassStrategy.generate(StringConcatFactory.java:1333)
	at java.base/java.lang.invoke.StringConcatFactory.makeConcatWithConstants(StringConcatFactory.java:394)
	... 9 more
Caused by: java.lang.IllegalAccessException: no such constructor: java.lang.String$$StringConcat/0x0000030000110400.<init>(String[])void/newInvokeSpecial
	at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:906)
	at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:989)
	at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3750)
	at java.base/java.lang.invoke.MethodHandles$Lookup.findConstructor(MethodHandles.java:2810)
	at java.base/java.lang.invoke.StringConcatFactory$InlineHiddenClassStrategy.generate(StringConcatFactory.java:1327)
	... 10 more
Caused by: java.lang.IllegalAccessError: class java.lang.StringConcatHelper tried to access private method 'void java.lang.String$$StringConcat/0x0000030000110400.<init>(java.lang.String[])' (java.lang.StringConcatHelper and java.lang.String$$StringConcat/0x0000030000110400 are in module java.base of loader 'bootstrap')
	at java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:957)
	at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:986)

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2284757113

From redestad at openjdk.org  Mon Aug 12 19:31:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 19:31:43 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v41]
In-Reply-To: <hGyjZtS5voR9rdME_ROO-rYMtNRdaA2kq3N8njO9GxA=.e1ee79e4-9e55-4b01-a00a-7e27cc2b02cd@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>
 <hGyjZtS5voR9rdME_ROO-rYMtNRdaA2kq3N8njO9GxA=.e1ee79e4-9e55-4b01-a00a-7e27cc2b02cd@github.com>
Message-ID: <IU2A_bmuACkoDvxE7EShoHus1wrGCjcOkDFh8U1gAYA=.9c013324-8717-4c12-a850-c1f5e3105e03@github.com>

On Mon, 12 Aug 2024 16:21:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix comments
>>  - remove unused code
>
> src/java.base/share/classes/java/lang/invoke/MemberName.java line 961:
> 
>> 959:                     return null;
>> 960:                 }
>> 961:                 if (allowedModes != LM_TRUSTED) {
> 
> ? You must revert changes to permission checks before a potential integration. This can involve security and massively increase the review complexity and risk of conformance violation.

Had missed these changes - must've been added as a workaround before we erased the method types and is probably pointless anyhow now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714270207

From redestad at openjdk.org  Mon Aug 12 19:31:44 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 12 Aug 2024 19:31:44 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v44]
In-Reply-To: <UQvJv7jDQ1NXZGUkcHUcN2mTFU0fcQn47KdAkzFE0XU=.a3ded99e-2e01-4372-8040-fbfa799dab5a@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <UQvJv7jDQ1NXZGUkcHUcN2mTFU0fcQn47KdAkzFE0XU=.a3ded99e-2e01-4372-8040-fbfa799dab5a@github.com>
Message-ID: <-l38SrOw6_iCOJx3itZ7GIoCo6VixM0gD2PzeTGR9-k=.ae507885-8703-400f-ad45-31172fac3fbe@github.com>

On Mon, 12 Aug 2024 19:15:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   StringConcat1

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 82:

> 80: 
> 81:     private ClassFileDumper(String key, String path) {
> 82:         String value = VM.getSavedProperty(key);

Could add a comment that this was necessary to avoid a bootstrap circularity issue in the java/lang/String/concat/WithSecurityManager.java test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714271440

From liach at openjdk.org  Mon Aug 12 19:32:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 19:32:32 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v2]
In-Reply-To: <9BxGHDh9wyMMjYEPcvglh5Uj91A9ZugvshVx2sANlD0=.607999df-d0e2-43bd-881d-e14c4d262d10@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <9BxGHDh9wyMMjYEPcvglh5Uj91A9ZugvshVx2sANlD0=.607999df-d0e2-43bd-881d-e14c4d262d10@github.com>
Message-ID: <zny-CN67gRklTCxUfmlFILpXGm9FmLswSa0Ck8wT9AA=.2536537d-9317-4770-93ed-c145ac999fa1@github.com>

On Mon, 12 Aug 2024 07:31:09 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8337302: Undefined type variable results in null

I have filled in the CSR for you.

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

PR Comment: https://git.openjdk.org/jdk/pull/20535#issuecomment-2284758943

From duke at openjdk.org  Mon Aug 12 19:38:51 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 19:38:51 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v45]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <dfgGaDZQPjORSOPXl_7LKlEh1cvPrpBG_vBkUADoHns=.098bae32-7ed2-4f4e-8391-6688146b3682@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/2fdd6614..0b75600f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=43-44

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

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

From liach at openjdk.org  Mon Aug 12 19:38:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Aug 2024 19:38:51 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v41]
In-Reply-To: <IU2A_bmuACkoDvxE7EShoHus1wrGCjcOkDFh8U1gAYA=.9c013324-8717-4c12-a850-c1f5e3105e03@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <dCdC7sG03sU4p4FRWUMgC7EruJVICnusrJY9bjom-TA=.d7388a28-32b0-4a5a-9bb3-543e82619957@github.com>
 <hGyjZtS5voR9rdME_ROO-rYMtNRdaA2kq3N8njO9GxA=.e1ee79e4-9e55-4b01-a00a-7e27cc2b02cd@github.com>
 <IU2A_bmuACkoDvxE7EShoHus1wrGCjcOkDFh8U1gAYA=.9c013324-8717-4c12-a850-c1f5e3105e03@github.com>
Message-ID: <y29_s3Bk5BDlQnIVnVD_SdPAIpg0Fmp12EDCzV_20BI=.c4d8f7a3-7185-4a2e-ace9-da2096101738@github.com>

On Mon, 12 Aug 2024 19:26:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MemberName.java line 961:
>> 
>>> 959:                     return null;
>>> 960:                 }
>>> 961:                 if (allowedModes != LM_TRUSTED) {
>> 
>> ? You must revert changes to permission checks before a potential integration. This can involve security and massively increase the review complexity and risk of conformance violation.
>
> Had missed these changes - must've been added as a workaround before we erased the method types and is probably pointless anyhow now?

Yep, I think we can safely remove these now that security manager and erasure are fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714278767

From duke at openjdk.org  Mon Aug 12 21:27:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 21:27:49 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v46]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <uuFLVQhfwutgB-ciMyGkhKHQ2H20OZpEZy1XglAFsaA=.2db538f3-d925-49eb-9940-ba9028c78a29@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  revert MemberName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/0b75600f..779d8be9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=44-45

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

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

From duke at openjdk.org  Mon Aug 12 21:32:52 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 21:32:52 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v47]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <vqHIpFDU2xYfNL2rBcHkNRky8Bz5ZmjJdZKXTaIKR3Q=.3e62abcf-654d-41f4-8cdf-4474b90b83e0@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  new Lookup(String.class)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/779d8be9..663d6224

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=45-46

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

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

From dl at openjdk.org  Mon Aug 12 21:40:33 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 12 Aug 2024 21:40:33 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <1qYJBG2Rf-toxOh9wT8RpAtByDkPjZW-oOYJcdD0nEE=.70eba6f7-87e0-47bd-abab-af1b17f4035d@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <1qYJBG2Rf-toxOh9wT8RpAtByDkPjZW-oOYJcdD0nEE=.70eba6f7-87e0-47bd-abab-af1b17f4035d@github.com>
Message-ID: <SFflxgp8Hbsm4ejHdEjR1cE_O1GyWqHtryWUku6gjSk=.bb0e3c1e-203e-47a9-ba9f-c167c75c3b9a@github.com>

On Mon, 12 Aug 2024 16:08:31 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Catching both Error and RuntimeException
>
> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 381:
> 
>> 379:                     else
>> 380:                         break;
>> 381:                 } catch (Error | RuntimeException ex) {
> 
> @DougLea @AlanBateman Changed to Error | RuntimeException here and for AQS

lgtm!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1714396285

From psandoz at openjdk.org  Mon Aug 12 22:06:30 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 12 Aug 2024 22:06:30 GMT
Subject: RFR: 8338023: Support two vector selectFrom API
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <z_ZtI1BJ66rCzes21Spb19ZQHYkKwhe45ZpvKV0htD8=.e1d290eb-3560-4283-94e6-3e4b792c099a@github.com>

On Thu, 8 Aug 2024 06:57:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

The results look promising. I can provide guidance on the specification e.g., we can specify the behavior in terms of rearrange, with the addition of throwing on out of bounds indexes.

Regarding the throwing of exceptions, some wider context will help to know where we are heading before we finalize the specification. I believe we are considering changing the default throwing behavior for index out of bounds to wrapping, thereby we can avoid bounds checks. If that is the case we should wait until that is done then update rather than submitting a CSR just yet?

I see you created a specific intrinsic, which will avoid the cost of shuffle creation. Should we apply the same approach (in a subsequent PR) to the single argument shuffle? Or perhaps if we manage to optimize shuffles and change the default wrapping we don't require a specific intrinsic and can just use defer to rearrange?

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

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2234095541

From psandoz at openjdk.org  Mon Aug 12 22:36:48 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 12 Aug 2024 22:36:48 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
Message-ID: <EBUFWhbaRUpDgOgDrFMX4RTMqUe2BMEwj3Ue4jnJDpI=.6aa99793-9e2b-4ce3-aed4-fdfce79621f8@github.com>

On Thu, 8 Aug 2024 17:20:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SATURATING_UADD   : Saturating unsigned addition.
>>      . SATURATING_ADD    :  Saturating signed addition. 
>>      . SATURATING_USUB   : Saturating unsigned subtraction.
>>      . SATURATING_SUB    : Saturating signed subtraction.
>>      . UMAX              : Unsigned max
>>      . UMIN              : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8338201
>  - Removed redundant comment
>  - 8338021: Support saturating vector operators in VectorAPI

Naming wise for the scalar methods i recommend the pattern of `op{Saturating}{Unsigned}`, that fits better with naming patterns used elsewhere, where we tend to be literal.

For the vector operations we should refer to unsigned consistently with the unsigned compare operation names. Here we can be more terse. Which makes me wonder if we should use `U` consistently for unsigned and `S` for saturating e.g. `SUADD`, `UGT`, `UMAX` etc. Then that flows into the names used in `VectorSupport.java` and `vectorSupport.hpp`.

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

PR Review: https://git.openjdk.org/jdk/pull/20507#pullrequestreview-2234118377

From duke at openjdk.org  Mon Aug 12 22:48:57 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 12 Aug 2024 22:48:57 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v23]
In-Reply-To: <g1hKmps1NesHfJ3POJKEW12a1IQzUiQ71QoTH9LtplM=.0661a4d1-c41f-47c8-96cc-c6e9b775641d@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <eSZfSI_VqsTipQ2Uw0P9sCc7sMwqaHODr-UGFno2R14=.e8352a0e-86c6-4391-b0c5-66c93daa4c62@github.com>
 <g1hKmps1NesHfJ3POJKEW12a1IQzUiQ71QoTH9LtplM=.0661a4d1-c41f-47c8-96cc-c6e9b775641d@github.com>
Message-ID: <aSjuEVCO9UGy5A-ThvA8mIUimAdQAtSWOu1PMjYkFwU=.17fcf375-0b9e-4c9e-93b8-72c1a687cba1@github.com>

On Fri, 2 Aug 2024 04:26:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix performance regression caused by args.erase()
>
> Because we load the class in the bootstrap loader so it can access java.lang; means our class cannot see user classes as a result.

Great! according to @liach 's suggestion, we no longer use TrustedLookup, and it is safer to run with lower permissions.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2285025974

From winterhalter at openjdk.org  Mon Aug 12 23:08:07 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Mon, 12 Aug 2024 23:08:07 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v3]
In-Reply-To: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
Message-ID: <lo5w2ZQeB_AySGepo24kLO5P4tkKPP_l3KpVZQX02v4=.d15d60f5-17a4-4ed4-bedf-6b1dc0767b6d@github.com>

> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

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

  8337302: Add missing visibility modifiers.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20535/files
  - new: https://git.openjdk.org/jdk/pull/20535/files/932dd9a1..2dbb17c6

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

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

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

From winterhalter at openjdk.org  Mon Aug 12 23:10:48 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Mon, 12 Aug 2024 23:10:48 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v2]
In-Reply-To: <jdIhNAm73bwEdtIErZtXIQZ3uQBsxCQZOEXx5P_D6W4=.a4eeec91-f3b2-49c4-9fb2-65100ad579ab@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <9BxGHDh9wyMMjYEPcvglh5Uj91A9ZugvshVx2sANlD0=.607999df-d0e2-43bd-881d-e14c4d262d10@github.com>
 <jdIhNAm73bwEdtIErZtXIQZ3uQBsxCQZOEXx5P_D6W4=.a4eeec91-f3b2-49c4-9fb2-65100ad579ab@github.com>
Message-ID: <7MPGtP72m96fSOkf-qqIy-2I-S208CKBqoy7GWgfpkE=.41818b64-4176-41a7-b34b-6299fc414445@github.com>

On Mon, 12 Aug 2024 13:51:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8337302: Undefined type variable results in null
>
> test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 54:
> 
>> 52:         Class<?> missing = ByteCodeLoader.load("sample.MissingVariable", bytes);
>> 53:         try {
>> 54:             Type type = missing.getField("f").getGenericType();
> 
> Suggestion:
> 
>             Type type = missing.getDeclaredField("f").getGenericType();
> 
> This field is package-private, causing this test's failure.

I made the type and field public instead. I struggle a bit with OpenJDK and IntelliJ, so I modified my local test setup slightly. Should work now!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1714459533

From dholmes at openjdk.org  Mon Aug 12 23:30:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Aug 2024 23:30:48 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <SFflxgp8Hbsm4ejHdEjR1cE_O1GyWqHtryWUku6gjSk=.bb0e3c1e-203e-47a9-ba9f-c167c75c3b9a@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <1qYJBG2Rf-toxOh9wT8RpAtByDkPjZW-oOYJcdD0nEE=.70eba6f7-87e0-47bd-abab-af1b17f4035d@github.com>
 <SFflxgp8Hbsm4ejHdEjR1cE_O1GyWqHtryWUku6gjSk=.bb0e3c1e-203e-47a9-ba9f-c167c75c3b9a@github.com>
Message-ID: <V1kNMtaqs9U7WwDo7iPoZgyp1HCeQOSfPH5wjPRhJ4M=.a5412543-558d-4765-beec-3e6f204c1b3e@github.com>

On Mon, 12 Aug 2024 21:37:45 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java line 381:
>> 
>>> 379:                     else
>>> 380:                         break;
>>> 381:                 } catch (Error | RuntimeException ex) {
>> 
>> @DougLea @AlanBateman Changed to Error | RuntimeException here and for AQS
>
> lgtm!

`catch (Throwable ex)` would be consistent with the similar block at line 331. Though I'm unclear how that compiles without the method declaring `throws Throwable` ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1714470560

From dholmes at openjdk.org  Mon Aug 12 23:42:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 12 Aug 2024 23:42:07 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
Message-ID: <H7J2sp-60mfI1HeTiBu7DYzAZPFk7j-WwrzGleexNa0=.b9927d35-3c74-4dcd-873e-6e023142578b@github.com>

On Mon, 12 Aug 2024 16:11:46 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catching both Error and RuntimeException

It has been a while since I knew this code reasonably well so perhaps I have just forgotten this difference between AQS and built-in monitors, but it seems that a Condition.await can return by throwing an exception without re-acquiring the associated synchronizer. Or is that handled at a higher-level?

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

PR Review: https://git.openjdk.org/jdk/pull/20548#pullrequestreview-2234191725

From duke at openjdk.org  Tue Aug 13 01:39:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 01:39:33 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v48]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <X8WfT-5I7s-U-2mFi_gi10YLz5etJSs6Zs0CfAscxGw=.52a1b38a-d37c-4e47-beb3-1515c9a67442@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  add jtreg HiddenClassUnloading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/663d6224..68506248

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=46-47

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

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

From duke at openjdk.org  Tue Aug 13 01:45:53 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 01:45:53 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v48]
In-Reply-To: <X8WfT-5I7s-U-2mFi_gi10YLz5etJSs6Zs0CfAscxGw=.52a1b38a-d37c-4e47-beb3-1515c9a67442@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <X8WfT-5I7s-U-2mFi_gi10YLz5etJSs6Zs0CfAscxGw=.52a1b38a-d37c-4e47-beb3-1515c9a67442@github.com>
Message-ID: <AWYCFTRb5wWwq9GNVnhOS9txY5x-vXPM7QKnyb_4-LU=.aa49b33f-82c3-4215-b9eb-95283825cb8f@github.com>

On Tue, 13 Aug 2024 01:39:33 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jtreg HiddenClassUnloading

Instrumentation::getAllLoadedClasses() cannot be called within the current process. I used ManagementFactory.getClassLoadingMXBean().getUnloadedClassCount(), which is not as accurate, but barely usable.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2285186006

From alanb at openjdk.org  Tue Aug 13 07:39:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Aug 2024 07:39:49 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
Message-ID: <Pea1fTKULut6i__xaPl7opPXfEPy4bb8jMco8bSEg6Q=.34da6718-ee78-4c31-b031-dbcc696c5aad@github.com>

On Mon, 12 Aug 2024 16:11:46 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catching both Error and RuntimeException

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20548#pullrequestreview-2234753657

From alanb at openjdk.org  Tue Aug 13 07:39:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Aug 2024 07:39:50 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <V1kNMtaqs9U7WwDo7iPoZgyp1HCeQOSfPH5wjPRhJ4M=.a5412543-558d-4765-beec-3e6f204c1b3e@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <1qYJBG2Rf-toxOh9wT8RpAtByDkPjZW-oOYJcdD0nEE=.70eba6f7-87e0-47bd-abab-af1b17f4035d@github.com>
 <SFflxgp8Hbsm4ejHdEjR1cE_O1GyWqHtryWUku6gjSk=.bb0e3c1e-203e-47a9-ba9f-c167c75c3b9a@github.com>
 <V1kNMtaqs9U7WwDo7iPoZgyp1HCeQOSfPH5wjPRhJ4M=.a5412543-558d-4765-beec-3e6f204c1b3e@github.com>
Message-ID: <bRe3TlPvHMJVEpURs9TPkLnzn-AdzI91cQHWv6XENcw=.2e2c1bac-ec6b-492f-b709-044238e07d88@github.com>

On Mon, 12 Aug 2024 23:28:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Though I'm unclear how that compiles without the method declaring `throws Throwable` ??

It wouldn't need that because of precise rethrow. In any case, having Error and RuntimeException are okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20548#discussion_r1714818621

From alanb at openjdk.org  Tue Aug 13 08:04:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Aug 2024 08:04:48 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <H7J2sp-60mfI1HeTiBu7DYzAZPFk7j-WwrzGleexNa0=.b9927d35-3c74-4dcd-873e-6e023142578b@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <H7J2sp-60mfI1HeTiBu7DYzAZPFk7j-WwrzGleexNa0=.b9927d35-3c74-4dcd-873e-6e023142578b@github.com>
Message-ID: <6qzN-mKRQgx5jV0o-BJgZhPXDRWBqKokbvjTrS3QC3c=.a5eea21a-dbf3-4602-8919-c91f220503b8@github.com>

On Mon, 12 Aug 2024 23:39:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> It has been a while since I knew this code reasonably well so perhaps I have just forgotten this difference between AQS and built-in monitors, but it seems that a Condition.await can return by throwing an exception without re-acquiring the associated synchronizer. Or is that handled at a higher-level?

The semantics are the same as monitor wait/notify so Condition.await must guarantee to hold the lock when it returns. If ConditionNode.block were to throw something like StackOverflowError then there would be an issue (it's a different park to the one changed in this PR but I think you do have a good point).

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

PR Comment: https://git.openjdk.org/jdk/pull/20548#issuecomment-2285609879

From redestad at openjdk.org  Tue Aug 13 08:26:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Aug 2024 08:26:57 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v48]
In-Reply-To: <X8WfT-5I7s-U-2mFi_gi10YLz5etJSs6Zs0CfAscxGw=.52a1b38a-d37c-4e47-beb3-1515c9a67442@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <X8WfT-5I7s-U-2mFi_gi10YLz5etJSs6Zs0CfAscxGw=.52a1b38a-d37c-4e47-beb3-1515c9a67442@github.com>
Message-ID: <BgZY2YzZldFM_dM31L89mq_gX9tX40zksKruc04jPOI=.e65a8189-3c53-417f-909a-42baaf6c1a43@github.com>

On Tue, 13 Aug 2024 01:39:33 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jtreg HiddenClassUnloading

Thanks for adding the test! Looks pretty good, but could perhaps be simplified a bit and run fewer iterations with the same result. 

Marking it as `@require vm.flagless` might avoid uninteresting test failures on various exotic VM configurations that higher test tiers might otherwise try out. 

(Also found a few more suggestions to the code at large)

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1226:

> 1224:                     cl = String.class;
> 1225:                 }
> 1226:                 paramTypes[i + 1] = ConstantUtils.classDesc(cl);

Suggestion:

                paramTypes[i + 1] = needString(cl) ? CD_String : ConstantUtils.classDesc(cl);

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1269:

> 1267:                             clb.withSuperclass(CD_StringConcatBase)
> 1268:                                 .withFlags(ACC_FINAL | ACC_SUPER | ACC_SYNTHETIC)
> 1269:                                 .withMethodBody(INIT_NAME, MTD_INIT, ACC_PROTECTED, CONSTRUCTOR_BUILDER)

Suggestion:

                                .withMethodBody(INIT_NAME, MTD_INIT, 0, CONSTRUCTOR_BUILDER)

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1413:

> 1411:                     int   paramCount  = concatArgs.parameterCount();
> 1412:                     int   thisSlot    = cb.receiverSlot();
> 1413:                     int[] stringSlots = new int[paramCount];

This array and the following loop strictly isn't needed: you can allocate the string slots just before astore, then derive those slots again in the two loops doing aload. They'll always start from the same slot and be in the same order.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1417:

> 1415:                         var cl = concatArgs.parameterType(i);
> 1416:                         if (needStringOf(cl)) {
> 1417:                             stringSlots[i] = cb.allocateLocal(TypeKind.from(String.class));

Suggestion:

                            stringSlots[i] = cb.allocateLocal(TypeKind.ReferenceType);

test/jdk/java/lang/String/concat/HiddenClassUnloading.java line 32:

> 30:  * @test
> 31:  * @summary Test whether the hidden class unloading of StringConcatFactory works
> 32:  *

Suggestion:

 *
 * @requires vm.flagless


I suggest we add this (slightly controversial) flag which locks down so that testing won't test this over and over at higher tiers with all manner of VM flags that this test might fail at.

test/jdk/java/lang/String/concat/HiddenClassUnloading.java line 67:

> 65:                     new Object[0]
> 66:             );
> 67:             MethodHandle mh = callSite.dynamicInvoker();

Actually invoking the concats seem unnecessary for this test; even with the rest of this method removed many thousands of classes is unloaded. We also seem to do pretty well with fewer iterations in the outer loop.

test/jdk/java/lang/String/concat/HiddenClassUnloading.java line 89:

> 87: 
> 88:         long unloadedClassCount = ManagementFactory.getClassLoadingMXBean().getUnloadedClassCount();
> 89:         if (unloadedClassCount == 0) {

Sample `getUnloadedClassCount()` before going into the loop so that we check that there's progress.

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

PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2234482233
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714815159
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714657417
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714657078
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714654215
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714870451
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714854631
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714857823

From duke at openjdk.org  Tue Aug 13 08:36:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 08:36:18 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v49]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <-tsDKRsAO4c9vF6NApfNWxWDn0Sa14hXfJwhDWFhAyg=.ca04a3d5-d679-4791-b8cd-cb29100f4774@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update test/jdk/java/lang/String/concat/HiddenClassUnloading.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/68506248..32334915

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=47-48

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

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

From redestad at openjdk.org  Tue Aug 13 08:50:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Aug 2024 08:50:18 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v49]
In-Reply-To: <-tsDKRsAO4c9vF6NApfNWxWDn0Sa14hXfJwhDWFhAyg=.ca04a3d5-d679-4791-b8cd-cb29100f4774@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <-tsDKRsAO4c9vF6NApfNWxWDn0Sa14hXfJwhDWFhAyg=.ca04a3d5-d679-4791-b8cd-cb29100f4774@github.com>
Message-ID: <i10BgciAYYz3uOcWvAgQFtrlM5vQZ4sAbJRKD1M1yfE=.b0307ae2-b292-4d58-8202-c57879358fd2@github.com>

On Tue, 13 Aug 2024 08:36:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update test/jdk/java/lang/String/concat/HiddenClassUnloading.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1191:

> 1189:                     cl = String.class;
> 1190:                 }
> 1191:                 paramTypes[i + 4] = ConstantUtils.classDesc(cl);

Suggestion:

                paramTypes[i + 4] = needStringOf(cl) ? CD_String : ConstantUtils.classDesc(cl);

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1223:

> 1221:             for (int i = 0; i < parameterCount; i++) {
> 1222:                 var cl = concatArgs.parameterType(i);
> 1223:                 paramTypes[i + 1] = needString(cl) ? CD_String : ConstantUtils.classDesc(cl);

Suggestion:

                paramTypes[i + 1] = needStringOf(cl) ? CD_String : ConstantUtils.classDesc(cl);


Typo in my previous suggestion

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714913889
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714912293

From duke at openjdk.org  Tue Aug 13 08:55:53 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 08:55:53 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v50]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <OZW1nLmJSzL1lNUijXpfmBphizv7hMv9XuQhObwfSbU=.05b508d5-c23b-4df7-8468-580c3121255c@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

 - Simplify HiddenClassUnloading
 - Remove unnecessary loops
 - fix build error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/32334915..babc76e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=48-49

  Stats: 51 lines in 2 files changed: 4 ins; 35 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

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

From duke at openjdk.org  Tue Aug 13 09:00:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 09:00:10 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v51]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <VCM4Lt8vJrkoOM2DtA-OovgQkywuj08s-iue4GmozLY=.31bcf7bc-fd27-4c30-b307-ba37621d0eee@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
  
  Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/babc76e1..14205596

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=49-50

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

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

From duke at openjdk.org  Tue Aug 13 09:00:10 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 09:00:10 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v48]
In-Reply-To: <BgZY2YzZldFM_dM31L89mq_gX9tX40zksKruc04jPOI=.e65a8189-3c53-417f-909a-42baaf6c1a43@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <X8WfT-5I7s-U-2mFi_gi10YLz5etJSs6Zs0CfAscxGw=.52a1b38a-d37c-4e47-beb3-1515c9a67442@github.com>
 <BgZY2YzZldFM_dM31L89mq_gX9tX40zksKruc04jPOI=.e65a8189-3c53-417f-909a-42baaf6c1a43@github.com>
Message-ID: <oyzUpXqED5G17KnvpJpePp-3tzVSFGzSbCXZwlYm8es=.6169b440-4b9c-4856-b23a-ecdb5d69fad4@github.com>

On Tue, 13 Aug 2024 08:04:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add jtreg HiddenClassUnloading
>
> test/jdk/java/lang/String/concat/HiddenClassUnloading.java line 67:
> 
>> 65:                     new Object[0]
>> 66:             );
>> 67:             MethodHandle mh = callSite.dynamicInvoker();
> 
> Actually invoking the concats seem unnecessary for this test; even with the rest of this method removed many thousands of classes is unloaded. We also seem to do pretty well with fewer iterations in the outer loop.

Yes, this is not necessary, it is there to check correctness, but it is not what this test is about, so I have removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714924871

From duke at openjdk.org  Tue Aug 13 09:05:09 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 09:05:09 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v52]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <v7TP0xWY0_Is7agyWu5Up339I2upQeRqDn0u4xOY2SY=.c7e3af92-13a6-471e-b657-29e316072ed3@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  Simplify HiddenClassUnloading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/14205596..e4f49c5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=50-51

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

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

From redestad at openjdk.org  Tue Aug 13 09:05:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Aug 2024 09:05:09 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v51]
In-Reply-To: <VCM4Lt8vJrkoOM2DtA-OovgQkywuj08s-iue4GmozLY=.31bcf7bc-fd27-4c30-b307-ba37621d0eee@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <VCM4Lt8vJrkoOM2DtA-OovgQkywuj08s-iue4GmozLY=.31bcf7bc-fd27-4c30-b307-ba37621d0eee@github.com>
Message-ID: <IqIB6cj0qlnO_W4dLwyHGFIg5ouJmAOh1SmXsDAQNYw=.e00f198b-46de-4013-bd5e-32c192c33efd@github.com>

On Tue, 13 Aug 2024 09:00:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

test/jdk/java/lang/String/concat/HiddenClassUnloading.java line 70:

> 68:     }
> 69: 
> 70:     static void assertEquals(String expected, String actual) {

unused

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714934816

From duke at openjdk.org  Tue Aug 13 09:25:20 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 09:25:20 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v53]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <nVWp3berJ8zq7D-xoc8bZTxuX0yCgzjqQSzrMG5Kce0=.f9ba2820-5b40-4d73-a554-ae21dda9b2d8@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

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

  Minor refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/e4f49c5e..62dd2ce7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=51-52

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

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

From redestad at openjdk.org  Tue Aug 13 09:25:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Aug 2024 09:25:21 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v51]
In-Reply-To: <VCM4Lt8vJrkoOM2DtA-OovgQkywuj08s-iue4GmozLY=.31bcf7bc-fd27-4c30-b307-ba37621d0eee@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <VCM4Lt8vJrkoOM2DtA-OovgQkywuj08s-iue4GmozLY=.31bcf7bc-fd27-4c30-b307-ba37621d0eee@github.com>
Message-ID: <VlLvucfdj014BBMBDc4mMmCaJuxAuZNUmNCMn3k-FW0=.5010ac0a-f588-4c94-9d16-e97ffc3c3a85@github.com>

On Tue, 13 Aug 2024 09:00:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>   
>   Co-authored-by: Claes Redestad <claes.redestad at oracle.com>

src/java.base/share/classes/java/lang/StringConcatHelper.java line 121:

> 119:         @ForceInline
> 120:         String concat(Object value) {
> 121:             String str = stringOf(value);

Redundant (remove, or replace `stringOf(value)` on next line with `str`)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714962672

From duke at openjdk.org  Tue Aug 13 09:38:31 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 09:38:31 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v54]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <QJeiJ_xRdBjR4RYkUhkFS9yhlT7drMaWbY9UMa2kU0k=.da6c70e6-9951-44ab-b15b-f2b9cbf838ce@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - remove unused
 - Minor refactoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/62dd2ce7..094b2e54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=52-53

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

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

From vklang at openjdk.org  Tue Aug 13 09:53:53 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 Aug 2024 09:53:53 GMT
Subject: Integrated: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors
In-Reply-To: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
Message-ID: <gqsbQrXPy7h9Ugya1mDU8EXZV03N-b5J2mLx9ridcYc=.67d00bb9-95b1-4aed-9283-e4948bebfd17@github.com>

On Mon, 12 Aug 2024 13:41:24 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

This pull request has now been integrated.

Changeset: fbe4cc96
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4
Stats:     26 lines in 2 files changed: 12 ins; 2 del; 12 mod

8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors

Reviewed-by: alanb

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

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

From vklang at openjdk.org  Tue Aug 13 11:54:50 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 13 Aug 2024 11:54:50 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
Message-ID: <6Kl2RpeG4-aM0z2o1RzBiKt-QBD-GLoHssiwjTdQCew=.ce417c1d-2205-4074-852b-40c5df5e1862@github.com>

On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea <dl at openjdk.org> wrote:

> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

src/java.base/share/classes/java/util/concurrent/Exchanger.java line 379:

> 377:                             if ((v = p.match) != null) {
> 378:                                 MATCH.set(p, null);
> 379:                                 break outer;     // spin wait

Is this comment accurate?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20554#discussion_r1715164058

From aboldtch at openjdk.org  Tue Aug 13 12:59:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 12:59:55 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com>
Message-ID: <BoS1Ow_5xJIp1UzI1rnG9JANY-ynS6QolrkpBv_ZAwE=.e9a5c979-fc54-43c5-b33b-66410067c41f@github.com>

On Tue, 16 Jul 2024 12:36:08 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Remove try_read
>>  - Add explicit to single parameter constructors
>>  - Remove superfluous access specifier
>>  - Remove unused include
>>  - Update assert message OMCache::set_monitor
>>  - Fix indentation
>>  - Remove outdated comment LightweightSynchronizer::exit
>>  - Remove logStream include
>>  - Remove strange comment
>>  - Fix javaThread include
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674:
> 
>> 672: 
>> 673:       // Search for obj in cache.
>> 674:       bind(loop);
> 
> Same loop transformation would be possible here.

I tried the following (see diff below) and it shows about a 5-10% regression in most the `LockUnlock.testInflated*` micros. Also tried with just `num_unrolled = 1` saw the same regression.  Maybe there was some other pattern you were thinking of. There are probably architecture and platform differences. This can and should probably be explored in a followup PR.



diff --git a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
index 5dbfdbc225d..4e6621cfece 100644
--- a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
+++ b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
@@ -663,25 +663,28 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
 
       const int num_unrolled = 2;
       for (int i = 0; i < num_unrolled; i++) {
-        cmpptr(obj, Address(t));
-        jccb(Assembler::equal, monitor_found);
-        increment(t, in_bytes(OMCache::oop_to_oop_difference()));
+        Label next;
+        cmpptr(obj, Address(t, OMCache::oop_to_oop_difference() * i));
+        jccb(Assembler::notEqual, next);
+        increment(t, in_bytes(OMCache::oop_to_oop_difference() * i));
+        jmpb(monitor_found);
+        bind(next);
       }
+      increment(t, in_bytes(OMCache::oop_to_oop_difference() * (num_unrolled - 1)));
 
       Label loop;
 
       // Search for obj in cache.
       bind(loop);
-
-      // Check for match.
-      cmpptr(obj, Address(t));
-      jccb(Assembler::equal, monitor_found);
-
+      // Advance.
+      increment(t, in_bytes(OMCache::oop_to_oop_difference()));
       // Search until null encountered, guaranteed _null_sentinel at end.
       cmpptr(Address(t), 1);
       jcc(Assembler::below, slow_path); // 0 check, but with ZF=0 when *t == 0
-      increment(t, in_bytes(OMCache::oop_to_oop_difference()));
-      jmpb(loop);
+
+      // Check for match.
+      cmpptr(obj, Address(t));
+      jccb(Assembler::notEqual, loop);
 
       // Cache hit.
       bind(monitor_found);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715249312

From aboldtch at openjdk.org  Tue Aug 13 13:29:23 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 13:29:23 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v12]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <HnUTRbKN3HCFRyXlGtEoSWZ8vYJhq32uaj1viD05JUo=.c0b61fec-b77e-4f2b-8fc1-aac35789b430@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8315884
 - Remove top comment
 - Missing DEBUG_ONLY
 - Remove extra whitespace in UseObjectMonitorTableTest.java
 - Inline _table
 - Rename ObjectMonitorWorld to ObjectMonitorTable
 - Update comment basicLock.hpp
 - Remove const for InflateCause parameters in lightweightSynchronizer
 - Use [inc/dec]_no_safepoint_count directly instead of a conditionally created NoSafepointVerifier
 - Remove unnecessary assert
 - ... and 29 more: https://git.openjdk.org/jdk/compare/76e33b6c...b96b916a

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

Changes: https://git.openjdk.org/jdk/pull/20067/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=11
  Stats: 3612 lines in 69 files changed: 2699 ins; 314 del; 599 mod
  Patch: https://git.openjdk.org/jdk/pull/20067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067

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

From aboldtch at openjdk.org  Tue Aug 13 13:29:24 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 13:29:24 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6]
In-Reply-To: <H1xx5Q5Wsuz3cl0FP1fwX4kL-jYdqbQ3skKwYcd54vo=.bd7abee8-0300-4253-a8b4-428ae8da1a0e@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <wRW8TABXS8LovbQ9qF8fosFD7FxYzpJdrG2LOvR6xDk=.19d62ec7-b2e4-41a1-8443-0480761288bf@github.com>
 <H1xx5Q5Wsuz3cl0FP1fwX4kL-jYdqbQ3skKwYcd54vo=.bd7abee8-0300-4253-a8b4-428ae8da1a0e@github.com>
Message-ID: <gxZcx6iBfrV4b6Fe1X6aRJGBXiYcblmlT1-QGjyXIoQ=.69a75453-2706-44dd-b7e6-89f8020578d7@github.com>

On Fri, 12 Jul 2024 15:32:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update arguments.cpp
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 58:
> 
>> 56: 
>> 57: //
>> 58: // Lightweight synchronization.
> 
> This comment doesn't really say anything. Either remove it, or add a nice summary of how LW locking and OM table stuff works.

Removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715291832

From aboldtch at openjdk.org  Tue Aug 13 13:33:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 13:33:55 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <zYO70HQfI8-f1CcQ_N7H0FtHecJdJ26uGt3DBJeMaYg=.9477511e-59c1-4eb4-9d7f-40c5e0b7555c@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <Wj5uaRxDmVYqDnt2V1PgErk7dI10LCro6WSfAm4Q6BU=.6fd91b51-ec40-438f-95a4-d2fbf593a288@github.com>
 <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
 <zYO70HQfI8-f1CcQ_N7H0FtHecJdJ26uGt3DBJeMaYg=.9477511e-59c1-4eb4-9d7f-40c5e0b7555c@github.com>
Message-ID: <wSqRZb3Uy2WSTW7NFg7VC4-5pqryvPkz7RrluM43qVY=.e21ecefc-4982-4f2d-b8a9-3e51a7fb320f@github.com>

On Tue, 23 Jul 2024 20:21:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Only legacy locking uses the displaced header, I believe, which isn't clear in this code at all.  This seems like a fix.  We should probably assert that only legacy locking uses this field as a displaced header.
>
> Update: yes, this code change does assert if you use BasicLock's displaced header for locking modes other than LM_LEGACY.

This is correct. The `displaced_header` in the BasicLock is only used by Legacy. Which is more strongly asserted now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715299608

From aboldtch at openjdk.org  Tue Aug 13 13:37:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 13:37:03 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <Wj5uaRxDmVYqDnt2V1PgErk7dI10LCro6WSfAm4Q6BU=.6fd91b51-ec40-438f-95a4-d2fbf593a288@github.com>
 <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
Message-ID: <boxzHVCBxDwVCoMmC2fRE38cOT2sCxUP6cQHU1eXIAI=.1b2e6509-e3c2-41a4-9740-db6e5326c990@github.com>

On Tue, 23 Jul 2024 13:19:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62:
>> 
>>> 60: class ObjectMonitorWorld : public CHeapObj<MEMFLAGS::mtObjectMonitor> {
>>> 61:   struct Config {
>>> 62:     using Value = ObjectMonitor*;
>> 
>> Does this alias really help? We don't state the type that many times and it looks odd to end up with a mix of `Value` and `ObjectMonitor*` in the same code.
>
> This alias is present in the other CHT implementations, alas as a typedef in StringTable and SymbolTable so this follows the pattern and allows cut/paste of the allocate_node, get_hash, and other functions.

It is required by the `ConcurrentHashTable` implementation.
https://github.com/openjdk/jdk/blob/ebf1154292aa5e78c9eb9ddb26a1a3f9885c2ef8/src/hotspot/share/utilities/concurrentHashTable.hpp#L43-L45

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715304376

From aboldtch at openjdk.org  Tue Aug 13 14:01:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 14:01:56 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <Wj5uaRxDmVYqDnt2V1PgErk7dI10LCro6WSfAm4Q6BU=.6fd91b51-ec40-438f-95a4-d2fbf593a288@github.com>
 <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
Message-ID: <xbMB5TpY37fxDKlN3-QqO1HGpYvw4RtOAhmHJGoPKJI=.0c7ec8d5-6ab1-44ac-a805-aa8ab4039a7d@github.com>

On Tue, 23 Jul 2024 16:36:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102:
>> 
>>> 100:       assert(*value != nullptr, "must be");
>>> 101:       return (*value)->object_is_cleared();
>>> 102:     }
>> 
>> The `is_dead` functions seem oddly placed given they do not relate to the object stored in the wrapper. Why are they here? And what is the difference between `object_is_cleared` and `object_is_dead` (as used by `LookupMonitor`) ?
>
> This is a good question.  When we look up the Monitor, we don't want to find any that the GC has marked dead, so that's why we call object_is_dead.   When we look up with the object to find the Monitor, the object won't be dead (since we're using it to look up).  But we don't want to find one that we've cleared because the Monitor was  deflated?  I don't see where we would clear it though.  We clear the WeakHandle in the destructor after the Monitor has been removed from the table.

What @coleenp  said is correct. One is just a null check, the other interacts with the GC and the objects lifecycle. 

But as also mentioned we do not ever clear these any WeakHandle, so this is currently always returning false. (At least from what I can see). This load should be cached or in a register because it always load this to check if it is the value when doing a lookup. So there should be no performance cost here, but it is unnecessary. I'll remove this.

The `object_is_dead` is only used when removing, where we can take the extra cost.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715347334

From aboldtch at openjdk.org  Tue Aug 13 14:06:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 14:06:55 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <Wj5uaRxDmVYqDnt2V1PgErk7dI10LCro6WSfAm4Q6BU=.6fd91b51-ec40-438f-95a4-d2fbf593a288@github.com>
 <RmSdsqxnTjwB53zn49RvKRIRkIuz_jiRjOCwwLhEm-g=.6e9238c5-bbbb-4666-82b0-fef3235a12b6@github.com>
Message-ID: <KJP-3SzwijAgTq7jFyTzsbN09YCAYt35tgRMf1d4NG4=.3d14e83d-0186-4e37-9b57-36be4f3d4530@github.com>

On Tue, 23 Jul 2024 14:27:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105:
>> 
>>> 103:   };
>>> 104: 
>>> 105:   class LookupMonitor : public StackObj {
>> 
>> I'm not understanding why we need this little wrapper class.
>
> It's a two way lookup.  The plain Lookup class is used to lookup the Monitor given the object.  This LookupMonitor class is used to lookup the object given the Monitor.  The CHT takes these wrapper classes.  Maybe we should rename LookupObject to be more clear?

As @coleenp said there are two lookups. One when you have the object and want to get or insert a new ObjectMonitor. Or the second when the deflator has an ObjectMonitor and wants to deflate and remove that object - ObjectMonitor association.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715356203

From aboldtch at openjdk.org  Tue Aug 13 14:15:18 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 14:15:18 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v13]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <Z4q88IUCsBrrMk7A2sANspUl7wDcOOtZeCFzJDAb_yw=.2ee7dfa4-5ff4-434b-89df-2a8ae01da44a@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Remove object_is_cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/b96b916a..53f833bc

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

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

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

From dl at openjdk.org  Tue Aug 13 14:16:50 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 13 Aug 2024 14:16:50 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <6Kl2RpeG4-aM0z2o1RzBiKt-QBD-GLoHssiwjTdQCew=.ce417c1d-2205-4074-852b-40c5df5e1862@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
 <6Kl2RpeG4-aM0z2o1RzBiKt-QBD-GLoHssiwjTdQCew=.ce417c1d-2205-4074-852b-40c5df5e1862@github.com>
Message-ID: <dasO4IkMm293nMt-foZd2b6IWJsIMJzC2qrBaTCaixM=.d4fce695-fa94-4a2d-b6be-1dc500ab2e92@github.com>

On Tue, 13 Aug 2024 11:52:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation
>
> src/java.base/share/classes/java/util/concurrent/Exchanger.java line 379:
> 
>> 377:                             if ((v = p.match) != null) {
>> 378:                                 MATCH.set(p, null);
>> 379:                                 break outer;     // spin wait
> 
> Is this comment accurate?

No. Carried over by mistake in a paste. Thanks. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20554#discussion_r1715375622

From szaldana at openjdk.org  Tue Aug 13 14:37:32 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 13 Aug 2024 14:37:32 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API [v2]
In-Reply-To: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
Message-ID: <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>

> Hi all, 
> 
> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
> 
> Thanks, 
> Sonia

Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8338014' of github.com:SoniaZaldana/jdk into JDK-8338014
 - Adding parentheses to references which are not part of sentences and removing redundant additions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20513/files
  - new: https://git.openjdk.org/jdk/pull/20513/files/099f2b81..4a709416

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

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

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

From aboldtch at openjdk.org  Tue Aug 13 14:50:06 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 14:50:06 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v14]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <Jyc9C5vqLA5OZKn23WGia4BCQCztR9Jo_s1jUb82l3g=.c4fcbaed-83bd-4c20-970a-820dfc9c34a9@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision:

 - Remove _omworld
 - Make ObjectMonitorTable AllStatic
 - Revert "Inline _table"
   
   This reverts commit 937f531364bb7025998d3a80f9ea93cbc8c9650f.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/53f833bc..123a2683

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

  Stats: 64 lines in 3 files changed: 4 ins; 5 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/20067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067

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

From aboldtch at openjdk.org  Tue Aug 13 14:52:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 14:52:03 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:

 - Remove the last OMWorld references
 - Rename omworldtable_work to object_monitor_table_work

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/123a2683..7946d148

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

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

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

From aboldtch at openjdk.org  Tue Aug 13 14:52:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 14:52:04 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v11]
In-Reply-To: <5r33aU_dXazxa8Lahw6JCsbt5aLwcjCp1N6vkcTm_yI=.f47905ec-aa19-447f-ba28-658c6c94003a@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>
 <5r33aU_dXazxa8Lahw6JCsbt5aLwcjCp1N6vkcTm_yI=.f47905ec-aa19-447f-ba28-658c6c94003a@github.com>
Message-ID: <4P75lMkZcWHH-gmLGywQxkgTIyAVhnURw7pLX1_5_Tk=.462bc748-1875-4e42-9a27-04ac2968c124@github.com>

On Mon, 12 Aug 2024 18:55:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing DEBUG_ONLY
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
> 
>> 339: };
>> 340: 
>> 341: ObjectMonitorTable* LightweightSynchronizer::_omworld = nullptr;
> 
> I preferred my version where ObjectMonitorTable was AllStatic which gets rid of _omworld-> everwhere, but the internal table is the pointer.  You can remove more omworld names also.

I implemented the AllStatic table, and remove all mentions of OMWorld.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715432994

From coleenp at openjdk.org  Tue Aug 13 14:56:56 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Aug 2024 14:56:56 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <RWR_R_rpAnhgo99Em5LpeLfzzxSYaS-1GUzX0sZFtOI=.1c3cdb68-e65d-4b7c-a3c0-77003689c279@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <OCv6QKq_A8dUaKUbnzSdEnlEqrMIcb6pUyLfObBFq-o=.1d78e62f-151c-403d-a291-fbab38c5f4d6@github.com>
 <3m5N_Fh65MVy7vRvO0wq3qFlzxjbCLHhbTBJe8OJorw=.eb61b3bd-5aca-45cd-8e88-389ae86a599b@github.com>
 <RWR_R_rpAnhgo99Em5LpeLfzzxSYaS-1GUzX0sZFtOI=.1c3cdb68-e65d-4b7c-a3c0-77003689c279@github.com>
Message-ID: <Ttc1Z990yUInWAdacXvBSnQorhuEuqrUxoc59VDhMos=.f69c5fb2-743c-4c5a-b5d4-47dfa804edc9@github.com>

On Mon, 12 Aug 2024 14:37:50 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is a really good suggestion and might help a lot with the performance problems that we see with the table with heavily contended locking.  I think we should change this in a follow-on patch (which I'll work on).
>
> I inlined the table in the surrounding object as it is a trivial change. 
> 
> Removing both indirections and creating static storage I would require more work (some conditional deferred creation, similar to an optional).

Sadly doesn't help with performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715443138

From coleenp at openjdk.org  Tue Aug 13 15:04:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 13 Aug 2024 15:04:54 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
Message-ID: <YnA1HSotBCHaZ7ung5A40cJKNvmxioHh6ps-xJ-R0rM=.46e950e3-c916-4923-84d7-f6d881bcf876@github.com>

On Tue, 13 Aug 2024 14:52:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the last OMWorld references
>  - Rename omworldtable_work to object_monitor_table_work

Two tiny nits.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 172:

> 170:   static void create() {
> 171:     _table = new ConcurrentTable(initial_log_size(),
> 172:                                 max_log_size(),

nit, can you line up these parameters?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 579:

> 577: }
> 578: 
> 579: 

Extra blank line.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2235807775
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715446552
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715449461

From redestad at openjdk.org  Tue Aug 13 15:14:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Aug 2024 15:14:02 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v54]
In-Reply-To: <QJeiJ_xRdBjR4RYkUhkFS9yhlT7drMaWbY9UMa2kU0k=.da6c70e6-9951-44ab-b15b-f2b9cbf838ce@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <QJeiJ_xRdBjR4RYkUhkFS9yhlT7drMaWbY9UMa2kU0k=.da6c70e6-9951-44ab-b15b-f2b9cbf838ce@github.com>
Message-ID: <0oVPgT_0jKp-wDfxUuIiqwFf0Soa7y9p59OPxcyKVFw=.91477283-95a2-4c87-9c66-4733a7ad50c2@github.com>

On Tue, 13 Aug 2024 09:38:31 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused
>  - Minor refactoring

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1232:

> 1230:             // 1 argment use built-in method
> 1231:             int paramCount  = args.parameterCount();
> 1232:             var concatClass = ConstantUtils.binaryNameToDesc(className);

`String className` and `ClassDesc concatClass` are effectively constant. Refactor to `static final` to save a few instructions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1715473623

From liach at openjdk.org  Tue Aug 13 15:17:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 15:17:04 GMT
Subject: RFR: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant [v5]
In-Reply-To: <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
 <Z-bfsQ2IgoN760NAVY8nKVHvKyvivAd9J0Q1NUrkS2I=.17b288d9-53ef-4a42-8e3d-63e1ad8eda9c@github.com>
Message-ID: <OuI3zRiE6u0l-c5Ygb3CeVZOngX48frX7QfCl0JucFY=.e0212eab-02c8-41b4-94f2-32f777453cb8@github.com>

On Fri, 2 Aug 2024 16:31:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
>> 2. Improved value specification to specify their tags.
>> 3. Improved value factories to return their specific types instead of `OfConstant`
>> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
>> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another failing test

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/20436#issuecomment-2286501451

From liach at openjdk.org  Tue Aug 13 15:17:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 15:17:04 GMT
Subject: Integrated: 8335927: Revisit AnnotationConstantValueEntry and
 AnnotationValue.OfConstant
In-Reply-To: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
References: <5k3hUQbfvCpwyfxZrORXzdRz9F4um9inoNsc1r4kahU=.2783e58b-6d60-4a8f-9d36-c56c570f25e0@github.com>
Message-ID: <2nhkV2zBPm6lyeRuDboFGmIh9tNVACktx5RPSB1p9Yc=.f6a1790b-9856-4048-b8ac-80ed25526f7b@github.com>

On Fri, 2 Aug 2024 00:39:12 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. Add notes and docs about the difference between resolved constants and constant pool descriptors for annotation constants (e.g. `char` vs `IntegerEntry`)
> 2. Improved value specification to specify their tags.
> 3. Improved value factories to return their specific types instead of `OfConstant`
> 4. Improved value classes to return specific `PoolEntry` subtypes and specific live constant subtypes
> 5. Removed confusing and meaningless `ConstantPoolBuilder.annotationConstantValueEntry`

This pull request has now been integrated.

Changeset: 6af1d6ff
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6af1d6ff210b3ddbc7d1585428b49631248a500b
Stats:     397 lines in 12 files changed: 216 ins; 39 del; 142 mod

8335927: Revisit AnnotationConstantValueEntry and AnnotationValue.OfConstant

Reviewed-by: asotona

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

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

From liach at openjdk.org  Tue Aug 13 15:28:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 15:28:49 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API [v2]
In-Reply-To: <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
Message-ID: <gmnk1JOh7XXmUa9AZGPntpO-RjfKTMV9FMTHalIPark=.fbd44540-8524-4a2c-b467-9723ceb357b4@github.com>

On Tue, 13 Aug 2024 14:37:32 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8338014' of github.com:SoniaZaldana/jdk into JDK-8338014
>  - Adding parentheses to references which are not part of sentences and removing redundant additions

Thanks for the cleanup.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20513#pullrequestreview-2235893657

From rkennke at openjdk.org  Tue Aug 13 16:05:57 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 13 Aug 2024 16:05:57 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <BoS1Ow_5xJIp1UzI1rnG9JANY-ynS6QolrkpBv_ZAwE=.e9a5c979-fc54-43c5-b33b-66410067c41f@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com>
 <BoS1Ow_5xJIp1UzI1rnG9JANY-ynS6QolrkpBv_ZAwE=.e9a5c979-fc54-43c5-b33b-66410067c41f@github.com>
Message-ID: <MmdZ3yn3V--_kRBE7YhEBoQF6o0qp-zebFKI0IvGpq8=.2c700fa7-d4b8-4718-930b-30590d508a3b@github.com>

On Tue, 13 Aug 2024 12:57:23 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674:
>> 
>>> 672: 
>>> 673:       // Search for obj in cache.
>>> 674:       bind(loop);
>> 
>> Same loop transformation would be possible here.
>
> I tried the following (see diff below) and it shows about a 5-10% regression in most the `LockUnlock.testInflated*` micros. Also tried with just `num_unrolled = 1` saw the same regression.  Maybe there was some other pattern you were thinking of. There are probably architecture and platform differences. This can and should probably be explored in a followup PR.
> 
> 
> 
> diff --git a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
> index 5dbfdbc225d..4e6621cfece 100644
> --- a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
> +++ b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
> @@ -663,25 +663,28 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
>  
>        const int num_unrolled = 2;
>        for (int i = 0; i < num_unrolled; i++) {
> -        cmpptr(obj, Address(t));
> -        jccb(Assembler::equal, monitor_found);
> -        increment(t, in_bytes(OMCache::oop_to_oop_difference()));
> +        Label next;
> +        cmpptr(obj, Address(t, OMCache::oop_to_oop_difference() * i));
> +        jccb(Assembler::notEqual, next);
> +        increment(t, in_bytes(OMCache::oop_to_oop_difference() * i));
> +        jmpb(monitor_found);
> +        bind(next);
>        }
> +      increment(t, in_bytes(OMCache::oop_to_oop_difference() * (num_unrolled - 1)));
>  
>        Label loop;
>  
>        // Search for obj in cache.
>        bind(loop);
> -
> -      // Check for match.
> -      cmpptr(obj, Address(t));
> -      jccb(Assembler::equal, monitor_found);
> -
> +      // Advance.
> +      increment(t, in_bytes(OMCache::oop_to_oop_difference()));
>        // Search until null encountered, guaranteed _null_sentinel at end.
>        cmpptr(Address(t), 1);
>        jcc(Assembler::below, slow_path); // 0 check, but with ZF=0 when *t == 0
> -      increment(t, in_bytes(OMCache::oop_to_oop_difference()));
> -      jmpb(loop);
> +
> +      // Check for match.
> +      cmpptr(obj, Address(t));
> +      jccb(Assembler::notEqual, loop);
>  
>        // Cache hit.
>        bind(monitor_found);

Yeah it's probably not very important. But it's not quite what I had in mind, I was thinking more something like (aarch64 version, untested, may be wrong):


diff --git a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
index 19af03d3488..05bbb5760b8 100644
--- a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
+++ b/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
@@ -302,14 +302,14 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
       Label monitor_found;

       // Load cache address
-      lea(t3_t, Address(rthread, JavaThread::om_cache_oops_offset()));
+      lea(t3_t, Address(rthread, JavaThread::om_cache_oops_offset() - OMCache::oop_to_oop_difference()));

       const int num_unrolled = 2;
       for (int i = 0; i < num_unrolled; i++) {
+        increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
         ldr(t1, Address(t3_t));
         cmp(obj, t1);
         br(Assembler::EQ, monitor_found);
-        increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
       }

       Label loop;
@@ -317,16 +317,14 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
       // Search for obj in cache.
       bind(loop);

-      // Check for match.
-      ldr(t1, Address(t3_t));
-      cmp(obj, t1);
-      br(Assembler::EQ, monitor_found);
+      increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));

+      ldr(t1, Address(t3_t));
       // Search until null encountered, guaranteed _null_sentinel at end.
-      increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
-      cbnz(t1, loop);
-      // Cache Miss, NE set from cmp above, cbnz does not set flags
-      b(slow_path);
+      cbz(t1, slow_path);
+      // Check for match.
+      cmp(obj, t1);
+      br(Assembler::NE, loop);

       bind(monitor_found);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715557161

From aboldtch at openjdk.org  Tue Aug 13 16:30:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 13 Aug 2024 16:30:12 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace and nits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/7946d148..68681c84

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

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

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

From dev at anthonyv.be  Tue Aug 13 16:32:16 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Tue, 13 Aug 2024 16:32:16 +0000
Subject: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>

Hi Viktor

Your previous response inspired me to experiment some more with Gatherers
As a result I'd like to make a couple propositions:

* add an additional type parameter.
  After doing so, type inference no longer needs any assistance:
  `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
* add an identity Gatherer with an optimized `andThen` implementation
  as well as an optimization in the default implementation of `Gatherer::andThen`
* eliminate the use of raw types in `Gatherers.Value`

Code that implements these propositions is in this gist: https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c

Kind regards,
Anthony

July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> Hi Anthony,
> 
> >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
> 
> >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
> 
> >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java
> 
> Cheers,
> 
> ?
> 
> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle
> 
> ????????????????????????????????????????????????????????????????
> 
> **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:**?Tuesday, 30 July 2024 17:20
> **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> ?
> 
> July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> >
> 
> > Hi Anthony,
> 
> Hi Viktor
> 
> > Thank you for your patience, and for providing feedback, it is always much appreciated.
> 
> >
> 
> > >When writing factory methods for Gatherers, there's sometimes a
> 
> > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> > to recognize and eliminate it from the pipeline. One idea is to add
> 
> > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> >
> 
> > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
> 
> > but rather adding it in case it was deemed necessary.
> 
> >
> 
> > Do you have a concrete use-case (code) that you could share?
> 
> The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> > >Sometimes a factory method returns a Gatherer that only works correctly
> 
> > if the upstream has certain characteristics, for example
> 
> > Spliterator.SORTED or Spliterator.DISTINCT.
> 
> >
> 
> > Do you have a concrete use-case (code) that you could share?
> 
> All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
> 
> > >One idea is to add methods
> 
> > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> > implementation would be able to recognize and eliminate these from the
> 
> > pipeline if the upstream already has these characteristics. That way
> 
> > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> > idea is to provide a Gatherer with a way to inspect the upstream
> 
> > characteristics. If the upstream is missing the required
> 
> > characteristic(s), it could then throw an IllegalStateException.
> 
> I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
> 
> > For a rather long time Gatherer had characteristics, however,
> 
> > what I noticed is that given composition of Gatherers what ended up happening
> 
> > almost always was that the combination of characteristics added overhead and devolved into the empty set
> 
> > real fast.
> 
> >
> 
> > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
> 
> > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
> 
> In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
> 
> That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> > >The returns clause of Gatherer.Integrator::integrate just states "true
> 
> > if subsequent integration is desired, false if not". In particular, it
> 
> > doesn't document the behavior I'm observing, that returning false also
> 
> > causes downstream to reject any further output elements.
> 
> >
> 
> > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
> 
> I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$? ), but this is indeed already fixed in JDK 23-ea.
> 
> This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> > Cheers,
> 
> >
> 
> > ?
> 
> >
> 
> > **Viktor Klang**
> 
> > Software Architect, Java Platform Group
> 
> >
> 
> > Oracle
> 
> Kind regards,
> 
> Anthony
> 
> > ????????????????????????????????????????????????????????????????
> 
> >
> 
> > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > **Sent:** Saturday, 27 July 2024 08:57
> 
> > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > **Subject:** Stream Gatherers (JEP 473) feedback
> 
> > ?
> 
> >
> 
> > When writing factory methods for Gatherers, there's sometimes a
> 
> >
> 
> > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> >
> 
> > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> >
> 
> > to recognize and eliminate it from the pipeline. One idea is to add
> 
> >
> 
> > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> >
> 
> > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> >
> 
> > Sometimes a factory method returns a Gatherer that only works correctly
> 
> >
> 
> > if the upstream has certain characteristics, for example
> 
> >
> 
> > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
> 
> >
> 
> > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> >
> 
> > implementation would be able to recognize and eliminate these from the
> 
> >
> 
> > pipeline if the upstream already has these characteristics. That way
> 
> >
> 
> > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> >
> 
> > idea is to provide a Gatherer with a way to inspect the upstream
> 
> >
> 
> > characteristics. If the upstream is missing the required
> 
> >
> 
> > characteristic(s), it could then throw an IllegalStateException.
> 
> >
> 
> > The returns clause of Gatherer.Integrator::integrate just states "true
> 
> >
> 
> > if subsequent integration is desired, false if not". In particular, it
> 
> >
> 
> > doesn't document the behavior I'm observing, that returning false also
> 
> >
> 
> > causes downstream to reject any further output elements.
> 
> >
> 
> > In the Implementation Requirements section of Gatherer, rephrasing
> 
> >
> 
> > "Outputs and state later in the input sequence will be discarded if
> 
> >
> 
> > processing an earlier partition short-circuits." to something like the
> 
> >
> 
> > following would be clearer to me: "As soon as any partition
> 
> >
> 
> > short-circuits, the whole Gatherer short-circuits. The state of other
> 
> >
> 
> > partitions is discarded, i.e. there are no further invocations of the
> 
> >
> 
> > combiner. The finisher is invoked with the short-circuiting partition's
> 
> >
> 
> > state." I wouldn't mention discarding of outputs, since that's implied
> 
> >
> 
> > by the act of short-circuiting.
> 
> >
> 
> > Anthony
> 
> >
>

From duke at openjdk.org  Tue Aug 13 16:34:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 13 Aug 2024 16:34:18 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>

> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - static final
 - code style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20273/files
  - new: https://git.openjdk.org/jdk/pull/20273/files/094b2e54..7d481ece

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=53-54

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

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

From cushon at google.com  Tue Aug 13 16:48:50 2024
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 13 Aug 2024 09:48:50 -0700
Subject: compatibility impact of JDK-8325621 (Improve jspawnhelper version
 checks)
Message-ID: <CAL4QsgvmX7UDTTB79eds+JM3Lmj3_BrSJ820jc1LT_bEKse7ug@mail.gmail.com>

Hi,

I have a data point to share on the compatibility impact of
JDK-8325621 (Improve jspawnhelper version checks), which was
backported to earlier release trains.

As a result of that change, doing an in-place upgrade from 22.0.1 to
22.0.2 breaks long-running Java applications that create subprocesses.
This is an expected consequence of the change, which adds version
checks to jspawnhelper to detect if a JVM is updated in-place to a
version with an incompatible jspawnhelper.

I'm curious if the list has suggestions on the best way to mitigate
the compatibility impact. One possibility is that replacing a JVM
in-place for a running process should never happen, and installers
should use new directories, or ensure any long-running Java processes
are shut down during the upgrade. Is that considered a best practice?

Here's a demo of the issue I saw:

$ cat T.java
public class T {
  public static void main(String[] args) throws Exception {
    while (true) {
      Thread.sleep(1000);
      System.err.println(Runtime.version());
      ProcessBuilder pb = new ProcessBuilder("/usr/bin/date");
      pb.redirectError(ProcessBuilder.Redirect.INHERIT);
      pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
      pb.start();
    }
  }
}

$ ./jdk-22.0.1/bin/java -fullversion
openjdk full version "22.0.1+8-16"
$ ./jdk-22.0.2/bin/java -fullversion
openjdk full version "22.0.2+9-70"

$ javac T.java
$ rsync -a jdk-22.0.1/ jdk/
$ ./jdk/bin/java T &
$ rsync -a jdk-22.0.2/ jdk/
...
jspawnhelper version 22.0.2+9-70
This command is not for general use and should only be run as the
result of a call to
ProcessBuilder.start() or Runtime.exec() in a java application
Exception in thread "main" java.io.IOException: Cannot run program
"/usr/bin/date": error=0, Failed to exec spawn helper: pid: 3740946,
exit value: 1
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1170)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1089)
        at T.main(T.java:12)
Caused by: java.io.IOException: error=0, Failed to exec spawn helper:
pid: 3740946, exit value: 1
        at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
        at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:295)
        at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:225)
        at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1126)
        ... 2 more

From duke at openjdk.org  Tue Aug 13 18:15:50 2024
From: duke at openjdk.org (jengebr)
Date: Tue, 13 Aug 2024 18:15:50 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <PaAlrwQm_PJNGZOt_3DPmVUOiil94nfHw8KZ0r80-a4=.bb6780d6-0e6a-4feb-aaf1-e24bb575a1fc@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>
 <PaAlrwQm_PJNGZOt_3DPmVUOiil94nfHw8KZ0r80-a4=.bb6780d6-0e6a-4feb-aaf1-e24bb575a1fc@github.com>
Message-ID: <gDlGfmrjIIVVr0e6nb7ca8oCfG2OOyz4oW_INeOu2Ks=.08e77438-cd17-432d-abb5-9ce9615b3eca@github.com>

On Wed, 19 Jun 2024 12:52:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman -- could you please take a look? Thanks.
>
>> @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 change? Part of me wonders if remove(int) needs to do the same as someone will show up sometime to ask.

@AlanBateman review please.

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

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

From redestad at openjdk.org  Tue Aug 13 18:44:55 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 13 Aug 2024 18:44:55 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <UhtzsR3aRks1oOdDi5EPKSTEMhv47Tm3G6AkroxCTG8=.7974b8de-81a5-4952-a888-a8d495d709cc@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

Marked as reviewed by redestad (Reviewer).

Thanks for your patience and hard work on this! I think this is ready to go, assuming tests and performance looks fine. I'll start some larger tests in our test system.

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

PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2236302953
PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2286890456

From liach at openjdk.org  Tue Aug 13 19:46:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 19:46:56 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v3]
In-Reply-To: <lo5w2ZQeB_AySGepo24kLO5P4tkKPP_l3KpVZQX02v4=.d15d60f5-17a4-4ed4-bedf-6b1dc0767b6d@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <lo5w2ZQeB_AySGepo24kLO5P4tkKPP_l3KpVZQX02v4=.d15d60f5-17a4-4ed4-bedf-6b1dc0767b6d@github.com>
Message-ID: <lUiJRy2Updbc4ni6XZMRRVFbjWTWrFuqCpgpHE_nleI=.613d96f0-4186-484c-b5aa-466570aee351@github.com>

On Mon, 12 Aug 2024 23:08:07 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Add missing visibility modifiers.

src/java.base/share/classes/java/lang/TypeNotPresentException.java line 1:

> 1: /*

Can you update the copyright header to this?

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

So 2024 instead of 2020. Same for `CoreReflectionFactory`.

test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 2:

> 1: /*
> 2:  * Copyright (c) 2004, 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/20535#discussion_r1715835788
PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1715835042

From liach at openjdk.org  Tue Aug 13 19:46:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 19:46:58 GMT
Subject: Withdrawn: 8261400: Reflection member filtering registration might be
 flawed
In-Reply-To: <VvKBpo68AQCTd0Trxi_-95dREOBXQFbsxuiKVudEJy0=.2bc31af7-3971-4d73-9161-4a18adcbe75b@github.com>
References: <VvKBpo68AQCTd0Trxi_-95dREOBXQFbsxuiKVudEJy0=.2bc31af7-3971-4d73-9161-4a18adcbe75b@github.com>
Message-ID: <bdr8E3kU2V3OvMQ-odzSaewvbdbVs5Eox8RGitknSH0=.33c77eb7-b092-44ab-8cf5-ffa2b8720ea6@github.com>

On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch that address the reflection member filtering flaws.
> 
> 1. Remove a pointless bootstrap check to ensure no filter is accidentally bypassed due to class-loading order.
> 2. Clarify the scenarios for filtering, and the correct filter actions for each scenario.
> 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways to steal this instance, bypassing the filtered getter. The `jdk.internal.misc.Unsafe`'s filter was already removed in JDK-8161129, so this filter is meaningless.

This pull request has been closed without being integrated.

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

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

From liach at openjdk.org  Tue Aug 13 19:47:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 19:47:30 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v9]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <nYQhpgoVZ9KHWpCcsce10UwAhRjd0id7hbFRAyC1-sg=.14365076-bb5e-4a91-8f12-e0998da9b828@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

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

 - More bad terms and redundancy
 - Fix terminology
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - remove compile, use element-value, break long sentences
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Improve docs for repeating, default, and value name
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - ... and 8 more: https://git.openjdk.org/jdk/compare/f09e48cb...c66c7d25

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/3a91a3a5..c66c7d25

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

  Stats: 15357 lines in 539 files changed: 6184 ins; 6850 del; 2323 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

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

From liach at openjdk.org  Tue Aug 13 19:56:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 19:56:22 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v10]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

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

  Missed JLS prefix from web review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20247/files
  - new: https://git.openjdk.org/jdk/pull/20247/files/c66c7d25..8af07782

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

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

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

From szaldana at openjdk.org  Tue Aug 13 20:51:50 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 13 Aug 2024 20:51:50 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API [v2]
In-Reply-To: <APZF5bj6Q8rtmnY_QjVb14hmQ7IbrXe_mKf3Mi8IHM8=.51b009b5-ca58-4362-b0a7-52268de17597@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <TBrakFUTbn8N3TWQEG4ArUqQDsFwScbsFslbeBMMtQg=.7b97f376-3883-4195-9688-95eef9785d6f@github.com>
 <APZF5bj6Q8rtmnY_QjVb14hmQ7IbrXe_mKf3Mi8IHM8=.51b009b5-ca58-4362-b0a7-52268de17597@github.com>
Message-ID: <DuuJF0nDaZBRUWE3G5FIUJYhiBdU9k3Kk7iCkznYo4c=.f4da1cae-750a-48e1-87cf-37842d30435e@github.com>

On Mon, 12 Aug 2024 18:55:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Looks fine; increasing review count to also include someone who more directly maintains this API.
>> 
>> If you haven't done so already, I recommend also doing a quick check for an analagous issue with `@jls` tags in this API.
>
>> @jddarcy Perhaps we should revisit the inline forms of `@jls` and `@jvms` tags to come up with similar and more consistent usage.
> 
> Certainly a variant do generate the most common usage pattern would be helpful -- brainstorming --
> 
> `{@jvms cite 1.2.3}`
> 
> to generate
> 
> (JVMVS 1.2.3)
> 
> where "1.2.3" was the expected link.

Hi @jddarcy, just checking in if the update looks good prior to integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/20513#issuecomment-2287112583

From darcy at openjdk.org  Tue Aug 13 20:57:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Aug 2024 20:57:49 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API [v2]
In-Reply-To: <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
Message-ID: <0ub4x-kVDfkz3aT0GJpo4wORTTdtcn2FS4gHyjvA_bU=.08d85e12-6184-44b0-b2f7-71e118a1e3af@github.com>

On Tue, 13 Aug 2024 14:37:32 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8338014' of github.com:SoniaZaldana/jdk into JDK-8338014
>  - Adding parentheses to references which are not part of sentences and removing redundant additions

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20513#pullrequestreview-2236559081

From liach at openjdk.org  Tue Aug 13 21:04:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Aug 2024 21:04:50 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API [v2]
In-Reply-To: <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
Message-ID: <C7U9hLsfi64kMRtnll9xRS5Tl_tl9MRGtOrcP3FEcvU=.ec5917df-5f62-45e7-94ff-5a3307a97c8c@github.com>

On Tue, 13 Aug 2024 14:37:32 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8338014' of github.com:SoniaZaldana/jdk into JDK-8338014
>  - Adding parentheses to references which are not part of sentences and removing redundant additions

Please allow for about 24 hours after the last push so that everyone interested may review, such as @asotona.

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

PR Comment: https://git.openjdk.org/jdk/pull/20513#issuecomment-2287132524

From dholmes at openjdk.org  Tue Aug 13 22:06:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Aug 2024 22:06:53 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <6qzN-mKRQgx5jV0o-BJgZhPXDRWBqKokbvjTrS3QC3c=.a5eea21a-dbf3-4602-8919-c91f220503b8@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <H7J2sp-60mfI1HeTiBu7DYzAZPFk7j-WwrzGleexNa0=.b9927d35-3c74-4dcd-873e-6e023142578b@github.com>
 <6qzN-mKRQgx5jV0o-BJgZhPXDRWBqKokbvjTrS3QC3c=.a5eea21a-dbf3-4602-8919-c91f220503b8@github.com>
Message-ID: <pqQvqCXUcUfODXgyYFPyqSaLYArGtd82gA8X1LqOwxw=.cf6d32e5-5c76-4d2c-8d12-6f18d5956f0a@github.com>

On Tue, 13 Aug 2024 08:02:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > It has been a while since I knew this code reasonably well so perhaps I have just forgotten this difference between AQS and built-in monitors, but it seems that a Condition.await can return by throwing an exception without re-acquiring the associated synchronizer. Or is that handled at a higher-level?
> 
> The semantics are the same as monitor wait/notify so Condition.await must guarantee to hold the lock when it returns. If ConditionNode.block were to throw something like StackOverflowError then there would be an issue (it's a different park to the one changed in this PR but I think you do have a good point).

AFAICS `await` would call the acquire method that was changed here. I know we have issues with OOME and SOE, but these changes admit more general exception possibilities that would seem to undermine the required guarantee. But perhaps a different `acquire` is involved in the `await` case?

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

PR Comment: https://git.openjdk.org/jdk/pull/20548#issuecomment-2287218877

From dcubed at openjdk.org  Tue Aug 13 22:16:01 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:16:01 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v11]
In-Reply-To: <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>
Message-ID: <jffFQcHwpwcqMpEwhBuv0_oqCcuZoaHARxrc1Pseehc=.0edf997e-5bc6-4fd8-9e2b-a64afdc3fe99@github.com>

On Mon, 12 Aug 2024 15:58:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing DEBUG_ONLY

src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 632:

> 630:         bool success = false;
> 631:         if (LockingMode == LM_LEGACY) {
> 632:            // Traditional lightweight locking.

The if-statement is for legacy locking so the comment about lightweight
locking seems wrong.

src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 736:

> 734:       bool success = false;
> 735:       if (LockingMode == LM_LEGACY) {
> 736:         // traditional lightweight locking

The if-statement is for legacy locking so the comment about lightweight
locking seems wrong.

src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1671:

> 1669:           bool success = false;
> 1670:           if (LockingMode == LM_LEGACY) {
> 1671:             // traditional lightweight locking

The if-statement is for legacy locking so the comment about lightweight
locking seems wrong.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1503:

> 1501: 
> 1502:   if (mon != nullptr) {
> 1503:     assert(mon != nullptr, "must have monitor");

With the new if-statement on L1502, the assert is not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714439929
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714440641
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714441506
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1714448544

From dcubed at openjdk.org  Tue Aug 13 22:16:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:16:10 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
Message-ID: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>

On Tue, 13 Aug 2024 14:52:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the last OMWorld references
>  - Rename omworldtable_work to object_monitor_table_work

src/hotspot/share/runtime/basicLock.inline.hpp line 45:

> 43:   return reinterpret_cast<ObjectMonitor*>(get_metadata());
> 44: #else
> 45:   // Other platforms does not make use of the cache yet,

nit typo: s/does not/do not/

src/hotspot/share/runtime/basicLock.inline.hpp line 54:

> 52: inline void BasicLock::clear_object_monitor_cache() {
> 53:   assert(UseObjectMonitorTable, "must be");
> 54:   set_metadata(0);

Should this be a literal `0` or should it be `nullptr`?
Update: The metadata field is of type `unintptr_t`. Got it.

src/hotspot/share/runtime/deoptimization.cpp line 1650:

> 1648:                 mon_info->lock()->set_bad_metadata_deopt();
> 1649:               }
> 1650: #endif

I like this!

src/hotspot/share/runtime/globals.hpp line 1964:

> 1962:                                                                             \
> 1963:   product(int, LightweightFastLockingSpins, 13, DIAGNOSTIC,                 \
> 1964:           "Specifies the number of time lightweight fast locking will "     \

nit typo: s/number of time/number of times/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 34:

> 32: #include "oops/oop.inline.hpp"
> 33: #include "runtime/atomic.hpp"
> 34: #include "memory/allStatic.hpp"

nit: this include is out of order.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 43:

> 41: #include "runtime/mutexLocker.hpp"
> 42: #include "runtime/objectMonitor.hpp"
> 43: #include "runtime/objectMonitor.inline.hpp"

Shouldn't have both includes here.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 81:

> 79:     oop _obj;
> 80: 
> 81:   public:

nit - please indent by one more space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 86:

> 84:     uintx get_hash() const {
> 85:       uintx hash = _obj->mark().hash();
> 86:       assert(hash != 0, "should have a hash");

Hmmm... I can remember seeing hash values of zero in some
of my older legacy inflation stress runs. Is a hash value of zero
not a thing with lightweight locking?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 104:

> 102:     ObjectMonitor* _monitor;
> 103: 
> 104:   public:

nit - please indent by one more space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 126:

> 124: 
> 125:   static void dec_items_count() {
> 126:     Atomic::inc(&_items_count);

Shouldn't this be `Atomic::dec`?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 130:

> 128: 
> 129:   static double get_load_factor() {
> 130:     return (double)_items_count/(double)_table_size;

nit - please add spaces around `/` operator.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 169:

> 167:   }
> 168: 
> 169: public:

nit - please indent by one space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 184:

> 182:       bool has_monitor = obj->mark().has_monitor();
> 183:       assert(has_monitor == (monitor != nullptr),
> 184:           "Inconsistency between markWord and OMW table has_monitor: %s monitor: " PTR_FORMAT,

Do you still want to use the name "OMW table"?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 213:

> 211: 
> 212:   static bool should_shrink() {
> 213:     // No implemented;

nit typo: s/No/Not/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 322:

> 320:        oop obj = om->object_peek();
> 321:        st->print("monitor " PTR_FORMAT " ", p2i(om));
> 322:        st->print("object " PTR_FORMAT, p2i(obj));

The monitor output style is to use `=` and commas, e.g.
`monitor=<value>, object=<value>`

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:

> 339: 
> 340: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor_from_table(oop object, JavaThread* current, bool* inserted) {
> 341:   assert(LockingMode == LM_LIGHTWEIGHT, "must be");

Do you want to assert: `inserted != nullptr`?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 367:

> 365:     ResourceMark rm(current);
> 366:     log_trace(monitorinflation)("inflate: object=" INTPTR_FORMAT ", mark="
> 367:                                 INTPTR_FORMAT ", type='%s' cause %s", p2i(object),

nit typo: s/cause %s/cause=%s/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 414:

> 412: 
> 413:   intptr_t hash = obj->mark().hash();
> 414:   assert(hash != 0, "must be set when claiming the object monitor");

Hmmm... I can remember seeing hash values of zero in some
of my older legacy inflation stress runs. Is a hash value of zero
not a thing with lightweight locking?

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 468:

> 466:     oop obj = *o;
> 467:     if (obj->mark_acquire().has_monitor()) {
> 468:       if (_length > 0 && _contended_oops[_length-1] == obj) {

nit - please add space around `-` operator.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 501:

> 499:   // Make room on lock_stack
> 500:   if (lock_stack.is_full()) {
> 501:     // Inflate contented objects

nit typo: s/contented/contended/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 545:

> 543:   bool _no_safepoint;
> 544: 
> 545: public:

nit - please indent by one space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 664:

> 662: 
> 663:   // Used when deflation is observed. Progress here requires progress
> 664:   // from the deflator. After observing the that the deflator is not

nit typo: s/observing the that the deflator/observing that the deflator/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 760:

> 758: 
> 759: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated
> 760: // ObjectMonitor* with LM_LIGHTWEIGHT. It is used from contexts which requires

nit typo: s/used from contexts which requires/used from contexts which require/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 773:

> 771:   JavaThread* current = THREAD;
> 772: 
> 773:   for(;;) {

nit: please add space before `(`.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 778:

> 776:       // No lock, IMSE.
> 777:       THROW_MSG_(vmSymbols::java_lang_IllegalMonitorStateException(),
> 778:                 "current thread is not owner", nullptr);

nit - please indent by one more space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 785:

> 783:         // Fast locked by other thread, IMSE.
> 784:         THROW_MSG_(vmSymbols::java_lang_IllegalMonitorStateException(),
> 785:                   "current thread is not owner", nullptr);

nit - please indent by one more space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 799:

> 797:         if (lock_stack.contains(obj)) {
> 798:           // Current thread owns the lock but someone else inflated
> 799:           // fix owner and pop lock stack

Please consider:

          // Current thread owns the lock but someone else inflated it.
          // Fix owner and pop lock stack.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 805:

> 803:           // Fast locked (and inflated) by other thread, or deflation in progress, IMSE.
> 804:           THROW_MSG_(vmSymbols::java_lang_IllegalMonitorStateException(),
> 805:                     "current thread is not owner", nullptr);

nit - please indent by one more space.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1045:

> 1043:   if (monitor->is_being_async_deflated()) {
> 1044:     // The MonitorDeflation thread is deflating the monitor. The locking thread
> 1045:     // must spin until further progress have been made.

nit typo: s/progress have been made./progress has been made./

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1075:

> 1073:     //                   lock, then we make the locking_thread thread
> 1074:     //                   the ObjectMonitor owner and remove the
> 1075:     //                   lock from the locking_thread thread's lock stack.

nit typos: s/locking_thread thread/locking_thread/
in three places.

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1190:

> 1188: 
> 1189: #ifndef _LP64
> 1190:   // Only for 32bit which have limited support for fast locking outside the runtime.

nit typo: s/which have limited support/which has limited support/

src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1194:

> 1192:     // Recursive lock successful.
> 1193:     current->inc_held_monitor_count();
> 1194:     // Clears object monitor cache, because ?

What does this comment mean?

src/hotspot/share/runtime/lightweightSynchronizer.hpp line 36:

> 34: 
> 35: class LightweightSynchronizer : AllStatic {
> 36: private:

nit: please indent by 1 space.

src/hotspot/share/runtime/lightweightSynchronizer.hpp line 41:

> 39: 
> 40:   static ObjectMonitor* add_monitor(JavaThread* current, ObjectMonitor* monitor, oop obj);
> 41:   static bool remove_monitor(Thread* current, oop obj, ObjectMonitor* monitor);

Hmmm... `add_monitor` has `monitor` and then `obj` params.
`remove_monitor` has `obj` and then `monitor` params. Why
not use the same order?

src/hotspot/share/runtime/lightweightSynchronizer.hpp line 57:

> 55:   static bool resize_table(JavaThread* current);
> 56: 
> 57: private:

nit: please indent by 1 space.

src/hotspot/share/runtime/lightweightSynchronizer.hpp line 61:

> 59:   static bool fast_lock_spin_enter(oop obj, LockStack& lock_stack, JavaThread* current, bool observed_deflation);
> 60: 
> 61: public:

nit: please indent by 1 space.

src/hotspot/share/runtime/lightweightSynchronizer.hpp line 69:

> 67:   static ObjectMonitor* inflate_locked_or_imse(oop object, ObjectSynchronizer::InflateCause cause, TRAPS);
> 68:   static ObjectMonitor* inflate_fast_locked_object(oop object, JavaThread* locking_thread, JavaThread* current, ObjectSynchronizer::InflateCause cause);
> 69:   static ObjectMonitor* inflate_and_enter(oop object, JavaThread* locking_thread, JavaThread* current, ObjectSynchronizer::InflateCause cause);

All of these are "inflate" functions, but:
- two of them have `object` parameter next to the `cause` parameter
-  two of them have `object` parameter first
- one of them has `current` parameter before the other thread parameter (`inflating_thread`)
- two of them have the `current` parameter after the other thread parameter (`locking_thread`)

Please consider making the parameter order consistent.

src/hotspot/share/runtime/lockStack.hpp line 130:

> 128: class OMCache {
> 129:   friend class VMStructs;
> 130: public:

Please indent by one space.

src/hotspot/share/runtime/lockStack.hpp line 133:

> 131:   static constexpr int CAPACITY = 8;
> 132: 
> 133: private:

Please indent by one space.

src/hotspot/share/runtime/lockStack.hpp line 140:

> 138:   const oop _null_sentinel = nullptr;
> 139: 
> 140: public:

Please indent by one space.

src/hotspot/share/runtime/objectMonitor.cpp line 669:

> 667:       install_displaced_markword_in_object(obj);
> 668:     }
> 669:   }

This can be cleaned up by putting L664 and L665 on the same line,
fixing the indents on L666-7 and deleting L668.

src/hotspot/share/runtime/objectMonitor.cpp line 682:

> 680: // deflation process.
> 681: void ObjectMonitor::install_displaced_markword_in_object(const oop obj) {
> 682:   assert(!UseObjectMonitorTable, "Lightweight has no dmw");

Perhaps:
`assert(!UseObjectMonitorTable, "ObjectMonitorTable has no dmw");`

src/hotspot/share/runtime/objectMonitor.hpp line 388:

> 386:   // Deflation support
> 387:   bool      deflate_monitor(Thread* current);
> 388: private:

nit - please indent by one space

src/hotspot/share/runtime/serviceThread.cpp line 44:

> 42: #include "runtime/jniHandles.hpp"
> 43: #include "runtime/serviceThread.hpp"
> 44: #include "runtime/lightweightSynchronizer.hpp"

Include is in the wrong place.

src/hotspot/share/runtime/synchronizer.cpp line 404:

> 402: 
> 403: bool ObjectSynchronizer::quick_enter_legacy(oop obj, JavaThread* current,
> 404:                                      BasicLock * lock) {

nit - please fix this indent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715569720
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715571831
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715582675
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715589490
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715617774
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715618379
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715621030
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715623399
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715640861
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715642307
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715643617
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715647133
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715649276
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715651080
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715661781
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715663965
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715662800
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715675411
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715678877
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715680995
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715682621
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715690997
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715696004
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715697549
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715698164
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715698568
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715700114
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715700801
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715716901
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715720857
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715724929
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715726115
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715603974
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715601643
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715604333
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715604553
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715614530
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715880925
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715881116
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715881379
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715922871
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715924876
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715900092
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715926418
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715940064

From dcubed at openjdk.org  Tue Aug 13 22:16:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:16:10 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6]
In-Reply-To: <u2VLk8hKBH5V6331fMIPCwusNARMd_v-q_wL_7r0AOA=.99b9b9f1-ac37-4cb6-9ad0-4e019fe3c1fe@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <wRW8TABXS8LovbQ9qF8fosFD7FxYzpJdrG2LOvR6xDk=.19d62ec7-b2e4-41a1-8443-0480761288bf@github.com>
 <H1xx5Q5Wsuz3cl0FP1fwX4kL-jYdqbQ3skKwYcd54vo=.bd7abee8-0300-4253-a8b4-428ae8da1a0e@github.com>
 <u2VLk8hKBH5V6331fMIPCwusNARMd_v-q_wL_7r0AOA=.99b9b9f1-ac37-4cb6-9ad0-4e019fe3c1fe@github.com>
Message-ID: <WvD7yT9MmMJC9uxfazdvMI-d71GthG-1iTHhVQoGnB0=.1239fd4a-a004-4840-aa3f-3241e2ee1235@github.com>

On Mon, 15 Jul 2024 00:45:10 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 401:
>> 
>>> 399: 
>>> 400:   if (inserted) {
>>> 401:     // Hopefully the performance counters are allocated on distinct
>> 
>> It doesn't look like the counters are on distinct cache lines (see objectMonitor.hpp, lines 212ff). If this is a concern, file a bug to investigate it later? The comment here is a bit misplaced, IMO.
>
> It originates from https://github.com/openjdk/jdk/blob/15997bc3dfe9dddf21f20fa189f97291824892de/src/hotspot/share/runtime/synchronizer.cpp#L1543 
> 
> I think we just kept it and did not think more about it.
> 
> Not sure what it is referring to. Maybe @dcubed-ojdk knows more, they originated from him (9 years old comment).

I don't think we ever got around to experimenting with putting the perf counters
on distinct cache lines. We've always had bigger fish to fry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715669185

From dcubed at openjdk.org  Tue Aug 13 22:15:59 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:15:59 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
Message-ID: <Nt7rViCh3ufr94M4mx4U0sSwjkmLfhEyoeqdfWMgqK0=.9101c1d4-fb06-4747-bc57-771e05849657@github.com>

On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace and nits

I finished my first pass crawl thru on these changes. I need to mull
on these changes a bit before I make another pass. I think there's
only one real bug buried in all of my comments.

src/hotspot/share/runtime/objectMonitor.cpp line 377:

> 375: 
> 376:   if (cur == current) {
> 377:     // TODO-FIXME: check for integer overflow!  BUGID 6557169.

Thanks for removing this comment. JDK-6557169 was closed as
"Will Not FIx" in 2017.

src/hotspot/share/runtime/synchronizer.cpp line 970:

> 968:   if (value == 0) value = 0xBAD;
> 969:   assert(value != markWord::no_hash, "invariant");
> 970:   return value;

In the elided part above this line, we have:

  if (value == 0) value = 0xBAD;
  assert(value != markWord::no_hash, "invariant");

so my memory about zero being returnable as a hash value is wrong.

src/hotspot/share/runtime/synchronizer.cpp line 977:

> 975: 
> 976:   markWord mark = obj->mark_acquire();
> 977:   for(;;) {

nit - please insert space before `(`

src/hotspot/share/runtime/synchronizer.cpp line 997:

> 995:   // Since the monitor isn't in the object header, it can simply be installed.
> 996:   if (UseObjectMonitorTable) {
> 997:     return install_hash_code(current, obj);

Perhaps:

  if (UseObjectMonitorTable) {
    // Since the monitor isn't in the object header, the hash can simply be
    // installed in the object header.
    return install_hash_code(current, obj);

src/hotspot/share/runtime/synchronizer.cpp line 1271:

> 1269:       _no_progress_cnt >= NoAsyncDeflationProgressMax) {
> 1270:     double remainder = (100.0 - MonitorUsedDeflationThreshold) / 100.0;
> 1271:     size_t new_ceiling = ceiling / remainder + 1;

Why was the `new_ceiling` calculation changed?
I think the `new_ceiling` value is going to lower than the old ceiling value.

src/hotspot/share/runtime/synchronizer.inline.hpp line 83:

> 81: 
> 82: 
> 83: #endif // SHARE_RUNTIME_SYNCHRONIZER_INLINE_HPP

nit - please delete one of the blank lines.

src/hotspot/share/runtime/vframe.cpp line 252:

> 250:           if (mark.has_monitor()) {
> 251:             ObjectMonitor* mon = ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
> 252:             if (// if the monitor is null we must be in the process of locking

nit - please add a space after `(`

test/hotspot/gtest/runtime/test_objectMonitor.cpp line 36:

> 34:     EXPECT_EQ(in_bytes(ObjectMonitor::metadata_offset()), 0)
> 35:          << "_metadata at a non 0 offset. metadata_offset = "
> 36:          << in_bytes(ObjectMonitor::metadata_offset());

nit - the indent should be four spaces instead of five spaces.

test/hotspot/gtest/runtime/test_objectMonitor.cpp line 40:

> 38:     EXPECT_GE((size_t) in_bytes(ObjectMonitor::owner_offset()), cache_line_size)
> 39:          << "the _metadata and _owner fields are closer "
> 40:          << "than a cache line which permits false sharing.";

nit - the indent should be four spaces instead of five spaces.

test/hotspot/gtest/runtime/test_objectMonitor.cpp line 44:

> 42:     EXPECT_GE((size_t) in_bytes(ObjectMonitor::recursions_offset() - ObjectMonitor::owner_offset()), cache_line_size)
> 43:          << "the _owner and _recursions fields are closer "
> 44:          << "than a cache line which permits false sharing.";

nit - the indent should be four spaces instead of five spaces.

test/hotspot/jtreg/runtime/Monitor/UseObjectMonitorTableTest.java line 148:

> 146:         static final int MAX_RECURSION_COUNT = 10;
> 147:         static final double RECURSION_CHANCE = .25;
> 148:         final Random random = new Random();

The test should output a seed value so that the user knows what
random seed value was in use if/when the test fails. Also add a way
to specify the seed value from the command line for reproducibility.

test/micro/org/openjdk/bench/vm/lang/LockUnlock.java line 201:

> 199: 
> 200:   /** Perform two synchronized after each other on the same object. */
> 201:     @Benchmark

Please align L200 with L201.

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

Changes requested by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2234133776
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715917040
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715955877
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715957258
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715958513
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715965577
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715976433
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715978312
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715981270
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715981568
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715981881
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715986844
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715990141

From dcubed at openjdk.org  Tue Aug 13 22:16:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:16:10 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <YnA1HSotBCHaZ7ung5A40cJKNvmxioHh6ps-xJ-R0rM=.46e950e3-c916-4923-84d7-f6d881bcf876@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <YnA1HSotBCHaZ7ung5A40cJKNvmxioHh6ps-xJ-R0rM=.46e950e3-c916-4923-84d7-f6d881bcf876@github.com>
Message-ID: <Hc9IIU_kaHqDAOMzkk8bTxCmJ7h9b0sE5dWV4K7X9gc=.3d962750-6240-4ea0-8a39-d218e1e9c595@github.com>

On Tue, 13 Aug 2024 14:56:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 172:
> 
>> 170:   static void create() {
>> 171:     _table = new ConcurrentTable(initial_log_size(),
>> 172:                                 max_log_size(),
> 
> nit, can you line up these parameters?

Or put them all on L171 if that doesn't make it too long...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715648059

From dcubed at openjdk.org  Tue Aug 13 22:16:10 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:16:10 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
Message-ID: <rub0-tfAHaBnwAxBTZfaTXtgYgvpcX_5f3T6vBWL81o=.fa5271c3-614b-49db-9de5-cdf01baf33ea@github.com>

On Tue, 13 Aug 2024 16:49:42 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 86:
> 
>> 84:     uintx get_hash() const {
>> 85:       uintx hash = _obj->mark().hash();
>> 86:       assert(hash != 0, "should have a hash");
> 
> Hmmm... I can remember seeing hash values of zero in some
> of my older legacy inflation stress runs. Is a hash value of zero
> not a thing with lightweight locking?

Update: My memory was wrong. When zero is encountered as a
hash value, it is replaced with `0xBAD`.

> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 414:
> 
>> 412: 
>> 413:   intptr_t hash = obj->mark().hash();
>> 414:   assert(hash != 0, "must be set when claiming the object monitor");
> 
> Hmmm... I can remember seeing hash values of zero in some
> of my older legacy inflation stress runs. Is a hash value of zero
> not a thing with lightweight locking?

Update: My memory was wrong. When zero is encountered as a
hash value, it is replaced with `0xBAD`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715952007
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1715952460

From dcubed at openjdk.org  Tue Aug 13 22:21:55 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 13 Aug 2024 22:21:55 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
Message-ID: <DwcyZD732AZ1FIoaIdi_EQaieUWBeib5QwTno69ghTs=.9af8d7f5-aae2-4b13-943e-29c8caf97387@github.com>

On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace and nits

Just for clarity, I think this is the one real bug that I found:
src/hotspot/share/runtime/lightweightSynchronizer.cpp line 126:

> 124: 
> 125:   static void dec_items_count() {
> 126:     Atomic::inc(&_items_count);

Shouldn't this be `Atomic::dec`?

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

PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2287237680

From winterhalter at openjdk.org  Tue Aug 13 23:41:06 2024
From: winterhalter at openjdk.org (Rafael Winterhalter)
Date: Tue, 13 Aug 2024 23:41:06 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
Message-ID: <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>

> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.

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

  8337302: Fix copyright years.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20535/files
  - new: https://git.openjdk.org/jdk/pull/20535/files/2dbb17c6..10d73b6c

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

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

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

From liach at openjdk.org  Wed Aug 14 00:30:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Aug 2024 00:30:50 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
Message-ID: <Xwxh8KGcigX-nYp_OgkmhGeFF6zbnRh6PnIjf12gSN0=.fc2e76b9-aa4c-4cda-88fc-eb352090dccf@github.com>

On Tue, 13 Aug 2024 23:41:06 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Fix copyright years.

Thanks for this patch!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20535#pullrequestreview-2236902946

From manc at google.com  Wed Aug 14 02:24:24 2024
From: manc at google.com (Man Cao)
Date: Tue, 13 Aug 2024 19:24:24 -0700
Subject: compatibility impact of JDK-8325621 (Improve jspawnhelper version
 checks)
Message-ID: <CA+w6HxYAg_N3eMHqTknkU3EjfKTEjt+1gt1xAH73mv2QXeS3cQ@mail.gmail.com>

HI,

In addition to Liam's point, I'd like to point out:

1. The version check in jspawnhelper is for the full JDK version. This
means any future in-place JDK update could trigger this problem for
long-running applications.
2. Typical Linux package managers (e.g. apt, yum) seem to update the JDK
package in place by default. We run into this problem with updates from
"apt install" internally.  Admittedly, I have not tested if updating
Debian's openjdk-21-jre-headless from 17.0.12 to 17.0.13, or from 21.0.3 to
21.0.4 would trigger the same issue, but it likely will.

This could be a widespread problem for future JDK updates on Linux distros.
Perhaps we should also raise this concern to jdk-updates-dev at openjdk.org?

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

From jkratochvil at openjdk.org  Wed Aug 14 02:59:33 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 14 Aug 2024 02:59:33 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v20]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <armE1TJT6euiIdqBUr7syBd5IAuArt4sTywLVp0CSgU=.4d85d1c0-d07a-4d3f-b2ed-6d871d1ec731@github.com>

> The testcase requires root permissions.
> 
> Fix by  Severin Gehwolf.
> Testcase by Jan Kratochvil.

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

  Testcase update upon review by Severin Gehwolf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17198/files
  - new: https://git.openjdk.org/jdk/pull/17198/files/4aec7a6e..b790b181

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=18-19

  Stats: 131 lines in 3 files changed: 21 ins; 67 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

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

From jkratochvil at openjdk.org  Wed Aug 14 03:28:55 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 14 Aug 2024 03:28:55 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v19]
In-Reply-To: <al8-84qIReC0un3wrpfUBFS8d2Xbfzxc4yqCVaWkzlY=.958d09a8-afc1-41fb-8dce-e6adb9823dee@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <UJEH6O85W5S7EPcsD74dXIcXqmYamjdsDuKeSb0ID-Y=.492ccb0e-85eb-41d4-a9ad-3f4fc47a1bb4@github.com>
 <al8-84qIReC0un3wrpfUBFS8d2Xbfzxc4yqCVaWkzlY=.958d09a8-afc1-41fb-8dce-e6adb9823dee@github.com>
Message-ID: <kc3sPHmAj7e37Z6QNA9BoA9PkG0wXfO_NlSC-7sDoRY=.722cf7e7-6c20-4da6-a89b-89d87d1763d2@github.com>

On Mon, 12 Aug 2024 18:39:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Inline adjust_controller() twice
>>  - Revert "Unify 4 copies of adjust_controller()"
>>    
>>    This reverts commit 77a81d07d74c8ae9bf34bfd8df9bcaca451ede9a.
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 217:
> 
>> 215: 
>> 216:             // KFAIL - verify the CgroupSubsystem::initialize_hierarchy() and jdk.internal.platform.CgroupSubsystem.initializeHierarchy() bug
>> 217:             // TestTwoLimits does not see the lower MEMORY_MAX_OUTER limit.
> 
> Remove this obsolete(?) comment.

This comment is documenting what the `TestTwoLimits` testcase does. Which I find useful.
It is KFAIL - Known Failure - the current OpenJDK code does not properly simulate what Linux kernel does. If you do:

cgset -r memory.max=$[1024*1024*1024] a/b
cgset -r memory.max=$[512*1024] a
cgexec -g memory:a/b java...

Then OpenJDK thinks it is `1024*1024*1024 KB` but Linux kernel will limit OpenJDK to `512*1024 KB`. So this problem is documented and tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1716261053

From jbhateja at openjdk.org  Wed Aug 14 04:59:23 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 14 Aug 2024 04:59:23 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v3]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <JwEdPnjUezCjbmtad2sFbDMibfS5OrFBaBxQDHzkB3Y=.a73ade46-34b8-4ca0-87c2-03f8bc14fdde@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SATURATING_UADD   : Saturating unsigned addition.
>      . SATURATING_ADD    :  Saturating signed addition. 
>      . SATURATING_USUB   : Saturating unsigned subtraction.
>      . SATURATING_SUB    : Saturating signed subtraction.
>      . UMAX              : Unsigned max
>      . UMIN              : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

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

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/5468e72b..8c9bfeca

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

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

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

From dholmes at openjdk.org  Wed Aug 14 05:47:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Aug 2024 05:47:55 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
Message-ID: <9PPJKBEF_-5HvSd4fnN6Maat1JVsHmxZy-dR7EqDCPw=.4e5d28fb-7dba-43b4-9452-3d9847ed7fa7@github.com>

On Tue, 13 Aug 2024 16:30:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace and nits

src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 84:

> 82: 
> 83:   if (LockingMode == LM_LIGHTWEIGHT) {
> 84:     lightweight_lock(disp_hdr, obj, hdr, temp, rscratch2, slow_case);

Given the declaration:

void MacroAssembler::lightweight_lock(Register basic_lock, Register obj, Register t1, Register t2, Register t3, Label& slow) 

it looks odd to pass `disp_hdr` here - is that variable just mis-named?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716339494

From aboldtch at openjdk.org  Wed Aug 14 05:54:12 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 05:54:12 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v17]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <8201AEgxCNq6r17tpMSHJ_oZZKSfCRNLKb0GgQEs1RQ=.953ac465-04e3-47ba-aace-92c1a5ef85e7@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix items count

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/68681c84..41ac7d37

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

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

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

From aboldtch at openjdk.org  Wed Aug 14 06:00:58 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 06:00:58 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v11]
In-Reply-To: <jffFQcHwpwcqMpEwhBuv0_oqCcuZoaHARxrc1Pseehc=.0edf997e-5bc6-4fd8-9e2b-a64afdc3fe99@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <SZklJM9NiqsqXZw8Is5RQpN0k3laPJf0cQviuCrOvlQ=.180a6fd8-4347-4628-8bc3-70ff25279aee@github.com>
 <jffFQcHwpwcqMpEwhBuv0_oqCcuZoaHARxrc1Pseehc=.0edf997e-5bc6-4fd8-9e2b-a64afdc3fe99@github.com>
Message-ID: <RtqtM7h2Y43ixzDZMTP7f4UW9ZbGCqgEm_Q8Denmx-8=.69afe878-d417-46fb-bc28-eb2671692ca7@github.com>

On Mon, 12 Aug 2024 22:40:06 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing DEBUG_ONLY
>
> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 632:
> 
>> 630:         bool success = false;
>> 631:         if (LockingMode == LM_LEGACY) {
>> 632:            // Traditional lightweight locking.
> 
> The if-statement is for legacy locking so the comment about lightweight
> locking seems wrong.

Yeah. It is an old comment from before LM_LIGHTWEIGHT existed. Will change to call it fast locking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716348558

From aboldtch at openjdk.org  Wed Aug 14 06:06:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 06:06:57 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
Message-ID: <sbdz0xmH_eok4nmEDukzIDEwFsagqmxlAA9SXSjCNi0=.7468cde9-9f56-4a1c-8417-bf3312ca69f4@github.com>

On Tue, 13 Aug 2024 16:34:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.hpp line 41:
> 
>> 39: 
>> 40:   static ObjectMonitor* add_monitor(JavaThread* current, ObjectMonitor* monitor, oop obj);
>> 41:   static bool remove_monitor(Thread* current, oop obj, ObjectMonitor* monitor);
> 
> Hmmm... `add_monitor` has `monitor` and then `obj` params.
> `remove_monitor` has `obj` and then `monitor` params. Why
> not use the same order?

Yeah, why not? :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716353596

From aboldtch at openjdk.org  Wed Aug 14 06:35:01 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 06:35:01 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
Message-ID: <2IX51ehxuHCfMr4W5i1RtKnBCqv-zU_8K3sLCYwgkoY=.3ad558a2-abce-4a6a-b53c-2750d7349925@github.com>

On Tue, 13 Aug 2024 17:05:38 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 126:
> 
>> 124: 
>> 125:   static void dec_items_count() {
>> 126:     Atomic::inc(&_items_count);
> 
> Shouldn't this be `Atomic::dec`?

Yes it should be. Surprised I never saw this. (Even though that using the service thread to grow was the very last thing changed before the PR, the resizing was handled differently before, by the deflator thread.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716377509

From aboldtch at openjdk.org  Wed Aug 14 07:11:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 07:11:57 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
Message-ID: <RiY0FTRy7gxoQlPFcizyIFbf82xLpVw1HzSQT3D_wOU=.df98a147-cea7-40c1-9eb8-d4e1466baf37@github.com>

On Tue, 13 Aug 2024 18:13:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 1194:
> 
>> 1192:     // Recursive lock successful.
>> 1193:     current->inc_held_monitor_count();
>> 1194:     // Clears object monitor cache, because ?
> 
> What does this comment mean?

I probably meant to write something about how x86_32 still uses the cache, so it is important that the CacheSetter clears it here. I'll remove the comment and add one on the CacheSetter explaining why it is necessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716414912

From alanb at openjdk.org  Wed Aug 14 07:24:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Aug 2024 07:24:53 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <pqQvqCXUcUfODXgyYFPyqSaLYArGtd82gA8X1LqOwxw=.cf6d32e5-5c76-4d2c-8d12-6f18d5956f0a@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <H7J2sp-60mfI1HeTiBu7DYzAZPFk7j-WwrzGleexNa0=.b9927d35-3c74-4dcd-873e-6e023142578b@github.com>
 <6qzN-mKRQgx5jV0o-BJgZhPXDRWBqKokbvjTrS3QC3c=.a5eea21a-dbf3-4602-8919-c91f220503b8@github.com>
 <pqQvqCXUcUfODXgyYFPyqSaLYArGtd82gA8X1LqOwxw=.cf6d32e5-5c76-4d2c-8d12-6f18d5956f0a@github.com>
Message-ID: <sskz5V60XqR2uU_6WpuzO-xT5lCZ3oVSSEe09N-Vuj0=.fb1714d6-50a1-4a34-865a-309bc8613b41@github.com>

On Tue, 13 Aug 2024 22:03:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> AFAICS `await` would call the acquire method that was changed here. I know we have issues with OOME and SOE, but these changes admit more general exception possibilities that would seem to undermine the required guarantee. But perhaps a different `acquire` is involved in the `await` case?

The changes here just cancel the attempt to acquire before throwing. There is more to Condition.awaitXXX in that they park until they can acquire, then acquire. So SOE or some other resource error would mean awaitXXX throws without holding the lock. We have done some work to on the virtual thread implementation of LockSupport.park/parkNanos/unpark so they never fail with OOME. There is a bit more to come there but otherwise not clear how to deal with other resource errors.

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

PR Comment: https://git.openjdk.org/jdk/pull/20548#issuecomment-2288030212

From aboldtch at openjdk.org  Wed Aug 14 07:25:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 07:25:56 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
Message-ID: <91YBmcYITOdHN6xHTbP-ZVABu4d-FNZYM6W630F9egw=.f75a47f5-bbc4-42d8-ba9b-941bea0ce584@github.com>

On Tue, 13 Aug 2024 21:05:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/serviceThread.cpp line 44:
> 
>> 42: #include "runtime/jniHandles.hpp"
>> 43: #include "runtime/serviceThread.hpp"
>> 44: #include "runtime/lightweightSynchronizer.hpp"
> 
> Include is in the wrong place.

I'll sort the whole list. `#include "runtime/serviceThread.hpp"` was in the wrong place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716430696

From dholmes at openjdk.org  Wed Aug 14 07:35:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Aug 2024 07:35:54 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
Message-ID: <SvEcfXKUVJh0OqXa3Tcg9WAVSw9GF6EedO5mMa8Ve8U=.84a963a0-9735-47b9-9dd9-921044041573@github.com>

On Mon, 12 Aug 2024 16:11:46 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> 8336384: AbstractQueuedSynchronizer.acquire should cancel acquire when failing due to a LinkageError or other errors
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Catching both Error and RuntimeException

When we have `Catch (Error | RuntimeException ex)` exactly what RuntimeExceptions are we trying to account for - because they should not happen and may break the synchronizer if they do.

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

PR Comment: https://git.openjdk.org/jdk/pull/20548#issuecomment-2288049212

From jbhateja at openjdk.org  Wed Aug 14 07:43:52 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 14 Aug 2024 07:43:52 GMT
Subject: RFR: 8338023: Support two vector selectFrom API
In-Reply-To: <z_ZtI1BJ66rCzes21Spb19ZQHYkKwhe45ZpvKV0htD8=.e1d290eb-3560-4283-94e6-3e4b792c099a@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <z_ZtI1BJ66rCzes21Spb19ZQHYkKwhe45ZpvKV0htD8=.e1d290eb-3560-4283-94e6-3e4b792c099a@github.com>
Message-ID: <C34zJEYsU2d4uOH6X3-hwmvkF2gfcfUcUw-vPpE45IU=.6c234fee-a4f9-441c-905e-fea9e82a44fe@github.com>

On Mon, 12 Aug 2024 22:03:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The results look promising. I can provide guidance on the specification e.g., we can specify the behavior in terms of rearrange, with the addition of throwing on out of bounds indexes.
> 
> Regarding the throwing of exceptions, some wider context will help to know where we are heading before we finalize the specification. I believe we are considering changing the default throwing behavior for index out of bounds to wrapping, thereby we can avoid bounds checks. If that is the case we should wait until that is done then update rather than submitting a CSR just yet?
> 
> I see you created a specific intrinsic, which will avoid the cost of shuffle creation. Should we apply the same approach (in a subsequent PR) to the single argument shuffle? Or perhaps if we manage to optimize shuffles and change the default wrapping we don't require a specific intrinsic and can just use defer to rearrange?

Hi @PaulSandoz ,
Thanks for your comments. With this new API we intend to enforce stricter specification w.r.t to index values to emit a lean instruction sequence preventing any cycles spent on massaging inputs to a consumable form, thus preventing redundant wrapping and unwrapping operations.

Existing [two vector rearrange API](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html#rearrange(jdk.incubator.vector.VectorShuffle,jdk.incubator.vector.Vector)) has a flexible specification which allows wrapping out of bounds shuffle indexes into exceptional index with a -ve value.

Even if we optimize existing two vector rearrange implementation we will still need to emit additional instructions to generate an indexes which lie within two vector range [0, 2*VLEN). I see this as a specialized API like vector compress/expand which cater to targets like x86-AVX512+ and aarch64-SVE which offers direct instruction for two vector lookups.

May be the API nomenclature can be refined to better reflect its semantics i.e. from selectFrom to twoVectorLookup ?

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

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2288062038

From redestad at openjdk.org  Wed Aug 14 07:49:54 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Aug 2024 07:49:54 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <9IG7yay_pakXNtvw_c-JsWU6533v5WXHJkBybKf0jng=.925a81e9-1e8a-45f0-b743-a9286a599a35@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

Tier 1-5 testing passed (a few unrelated test failures)

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288073835

From aboldtch at openjdk.org  Wed Aug 14 08:05:00 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 08:05:00 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <Nt7rViCh3ufr94M4mx4U0sSwjkmLfhEyoeqdfWMgqK0=.9101c1d4-fb06-4747-bc57-771e05849657@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
 <Nt7rViCh3ufr94M4mx4U0sSwjkmLfhEyoeqdfWMgqK0=.9101c1d4-fb06-4747-bc57-771e05849657@github.com>
Message-ID: <XQcsh4yVqL3jk3unbuWB9qF1aklTuVt5slTKgtuEDfw=.18e05d40-f233-47b6-90bc-c5fd070326f3@github.com>

On Tue, 13 Aug 2024 21:45:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace and nits
>
> src/hotspot/share/runtime/synchronizer.cpp line 1271:
> 
>> 1269:       _no_progress_cnt >= NoAsyncDeflationProgressMax) {
>> 1270:     double remainder = (100.0 - MonitorUsedDeflationThreshold) / 100.0;
>> 1271:     size_t new_ceiling = ceiling / remainder + 1;
> 
> Why was the `new_ceiling` calculation changed?
> I think the `new_ceiling` value is going to lower than the old ceiling value.

The old calculation made no sense if the goal was to after NoAsyncDeflationProgressMax deflation cycles with not deflation stop trying until we get more monitors. With the current calculation we can keep running these no progress cycles for quite a number of iterations.

The remainder is a value in the range [0,1].  So it will always grow by at least 1. (When remainder == 1: `new_ceiling = ceiling + 1;`)

I do however realise that the new calculation needs to handle remainder == 0.0 (MonitorUsedDeflationThreshold = 100). But the whole NoAsyncDeflationProgressMax makes little sense if MonitorUsedDeflationThreshold is 0, as the value for new ceiling would only stop deflation if it is large enough that the `size_t monitor_usage = (monitors_used * 100LL) / ceiling;` gets truncated to 0. (Less than 1%). 

But this is a leftover from the deflation changes so I will probably just remove this change and create a RFE for reevaluating this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716479164

From alanb at openjdk.org  Wed Aug 14 08:37:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Aug 2024 08:37:00 GMT
Subject: RFR: 8336384: AbstractQueuedSynchronizer.acquire should cancel
 acquire when failing due to a LinkageError or other errors [v2]
In-Reply-To: <SvEcfXKUVJh0OqXa3Tcg9WAVSw9GF6EedO5mMa8Ve8U=.84a963a0-9735-47b9-9dd9-921044041573@github.com>
References: <FiD97YqWzBv8wv4ELPyWP_J2WpOu0_Mk5WfcYYRREuA=.736e05f0-599a-446b-a373-352658960527@github.com>
 <e58RY8snzYgnhLMp8QILon3ZoRgXnmxNok0KL3fBwn8=.5543fe31-f45c-47b9-b972-26492d36a4b1@github.com>
 <SvEcfXKUVJh0OqXa3Tcg9WAVSw9GF6EedO5mMa8Ve8U=.84a963a0-9735-47b9-9dd9-921044041573@github.com>
Message-ID: <dEC-ov_ZPnNq3602e6MuzM2lSFkW9fJlF7yIFH3oVF8=.aa3b74e0-ae0c-4b83-a935-9fa08fcf9a4b@github.com>

On Wed, 14 Aug 2024 07:33:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When we have `Catch (Error | RuntimeException ex)` exactly what RuntimeExceptions are we trying to account for - because they should not happen and may break the synchronizer if they do.

Right now, the catch is just defending against LockSupport.park or parkNanos throwing. A timed-park on a virtual thread requires queueing a timer task and first use can involve class loading, initialisation and running more code that is obvious. We are trying to harden this as much as this as possible to never throw OOME. SOE is a lost cause. REE is possible right now and we have to do more to prevent that. Instrumentation brings a truck load of possible issues as some wild agent could instrument core classes and cause all manner of exceptions and issues. All we are doing here is just cancelling the acquire when throwing. It's just too surprising, and hard to diagnose, to throw and leaving a node queued.

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

PR Comment: https://git.openjdk.org/jdk/pull/20548#issuecomment-2288167767

From aboldtch at openjdk.org  Wed Aug 14 08:39:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 08:39:36 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v18]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <fZ4u4OeFMFEl7UHS5VfL5GxMg4akxEAtj0I0-3crSpA=.2b3199bd-7371-49cd-89a8-d612304e119f@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with 30 additional commits since the last revision:

 - Add and print random seed UseObjectMonitorTableTest.java
 - Align comment LockUnlock.java
 - Fix test_objectMonitor.cpp indent
 - Revert monitors_used_above_threshold changes
 - Fix whitespace synchronizer.{inline.hpp,cpp}
 - Update `ObjectSynchronizer::FastHashCode` comment
 - Fix quick_enter parameter order
 - Fix serviceThread.cpp include order
 - Update `ObjectMonitor::install_displaced_markword_in_object` assert text
 - Fix merge else if scopes ObjectMonitor::deflate_monitor
 - ... and 20 more: https://git.openjdk.org/jdk/compare/41ac7d37...3f29e6d6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/41ac7d37..3f29e6d6

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

  Stats: 119 lines in 18 files changed: 11 ins; 16 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/20067.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20067/head:pull/20067

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

From aboldtch at openjdk.org  Wed Aug 14 08:46:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 08:46:57 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <9PPJKBEF_-5HvSd4fnN6Maat1JVsHmxZy-dR7EqDCPw=.4e5d28fb-7dba-43b4-9452-3d9847ed7fa7@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
 <9PPJKBEF_-5HvSd4fnN6Maat1JVsHmxZy-dR7EqDCPw=.4e5d28fb-7dba-43b4-9452-3d9847ed7fa7@github.com>
Message-ID: <zt7csdyBVg-nLZJAeQ-Y5VaQhnMaa7if46pILf2amIk=.94be5de3-ec71-408d-893d-6e9d3ea67371@github.com>

On Wed, 14 Aug 2024 05:45:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace and nits
>
> src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 84:
> 
>> 82: 
>> 83:   if (LockingMode == LM_LIGHTWEIGHT) {
>> 84:     lightweight_lock(disp_hdr, obj, hdr, temp, rscratch2, slow_case);
> 
> Given the declaration:
> 
> void MacroAssembler::lightweight_lock(Register basic_lock, Register obj, Register t1, Register t2, Register t3, Label& slow) 
> 
> it looks odd to pass `disp_hdr` here - is that variable just mis-named?

Yeah, because the BasicLock and display header / metadata in BasicLock are all on the same address so they have been used interchangeably in c1,c2 and the interpreter. It should probably be fixed. But maybe in a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716539547

From aboldtch at openjdk.org  Wed Aug 14 08:51:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 08:51:56 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v9]
In-Reply-To: <MmdZ3yn3V--_kRBE7YhEBoQF6o0qp-zebFKI0IvGpq8=.2c700fa7-d4b8-4718-930b-30590d508a3b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <zu91N4ZznHQPPm9sqN2BI4wu2_xbh5LPYTGPgSwSfB4=.2e309b58-8feb-4d91-8236-275715854e51@github.com>
 <1fs1zYHKJsoWuEpKNb1ZY_VQ7_i_gQrbmx4d2fJvQo0=.1e3cbf20-dedf-4113-95c2-444869a75d1d@github.com>
 <BoS1Ow_5xJIp1UzI1rnG9JANY-ynS6QolrkpBv_ZAwE=.e9a5c979-fc54-43c5-b33b-66410067c41f@github.com>
 <MmdZ3yn3V--_kRBE7YhEBoQF6o0qp-zebFKI0IvGpq8=.2c700fa7-d4b8-4718-930b-30590d508a3b@github.com>
Message-ID: <KMkup_GDVVmBX1n1Nn1h6slnEShkbEEKxGanfXXOKMQ=.d224978e-d558-4a5f-a50d-4a3aa89f793a@github.com>

On Tue, 13 Aug 2024 16:03:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I tried the following (see diff below) and it shows about a 5-10% regression in most the `LockUnlock.testInflated*` micros. Also tried with just `num_unrolled = 1` saw the same regression.  Maybe there was some other pattern you were thinking of. There are probably architecture and platform differences. This can and should probably be explored in a followup PR.
>> 
>> 
>> 
>> diff --git a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
>> index 5dbfdbc225d..4e6621cfece 100644
>> --- a/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
>> +++ b/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
>> @@ -663,25 +663,28 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
>>  
>>        const int num_unrolled = 2;
>>        for (int i = 0; i < num_unrolled; i++) {
>> -        cmpptr(obj, Address(t));
>> -        jccb(Assembler::equal, monitor_found);
>> -        increment(t, in_bytes(OMCache::oop_to_oop_difference()));
>> +        Label next;
>> +        cmpptr(obj, Address(t, OMCache::oop_to_oop_difference() * i));
>> +        jccb(Assembler::notEqual, next);
>> +        increment(t, in_bytes(OMCache::oop_to_oop_difference() * i));
>> +        jmpb(monitor_found);
>> +        bind(next);
>>        }
>> +      increment(t, in_bytes(OMCache::oop_to_oop_difference() * (num_unrolled - 1)));
>>  
>>        Label loop;
>>  
>>        // Search for obj in cache.
>>        bind(loop);
>> -
>> -      // Check for match.
>> -      cmpptr(obj, Address(t));
>> -      jccb(Assembler::equal, monitor_found);
>> -
>> +      // Advance.
>> +      increment(t, in_bytes(OMCache::oop_to_oop_difference()));
>>        // Search until null encountered, guaranteed _null_sentinel at end.
>>        cmpptr(Address(t), 1);
>>        jcc(Assembler::below, slow_path); // 0 check, but with ZF=0 when *t == 0
>> -      increment(t, in_bytes(OMCache::oop_to_oop_difference()));
>> -      jmpb(loop);
>> +
>> +      // Check for match.
>> +      cmpptr(obj, Address(t));
>> +      jccb(Assembler::notEqual, loop);
>>  
>>        // Cache hit.
>>        bind(monitor_found);
>
> Yeah it's probably not very important. But it's not quite what I had in mind, I was thinking more something like (aarch64 version, untested, may be wrong):
> 
> 
> diff --git a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
> index 19af03d3488..05bbb5760b8 100644
> --- a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
> +++ b/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
> @@ -302,14 +302,14 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
>        Label monitor_found;
> 
>        // Load cache address
> -      lea(t3_t, Address(rthread, JavaThread::om_cache_oops_offset()));
> +      lea(t3_t, Address(rthread, JavaThread::om_cache_oops_offset() - OMCache::oop_to_oop_difference()));
> 
>        const int num_unrolled = 2;
>        for (int i = 0; i < num_unrolled; i++) {
> +        increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
>          ldr(t1, Address(t3_t));
>          cmp(obj, t1);
>          br(Assembler::EQ, monitor_found);
> -        increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
>        }
> 
>        Label loop;
> @@ -317,16 +317,14 @@ void C2_MacroAssembler::fast_lock_lightweight(Register obj, Register box, Regist
>        // Search for obj in cache.
>        bind(loop);
> 
> -      // Check for match.
> -      ldr(t1, Address(t3_t));
> -      cmp(obj, t1);
> -      br(Assembler::EQ, monitor_found);
> +      increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
> 
> +      ldr(t1, Address(t3_t));
>        // Search until null encountered, guaranteed _null_sentinel at end.
> -      increment(t3_t, in_bytes(OMCache::oop_to_oop_difference()));
> -      cbnz(t1, loop);
> -      // Cache Miss, NE set from cmp above, cbnz does not set flags
> -      b(slow_path);
> +      cbz(t1, slow_path);
> +      // Check for match.
> +      cmp(obj, t1);
> +      br(Assembler::NE, loop);
> 
>        bind(monitor_found);

I see just the loop. I read it as the a cachehit should not take conditional branches.  

The `num_unrolled = 1` effectively became what you suggest, and showed similar regressions (but with only one unrolled lookup).  And only tested on one specific machine.

But let us leave it to a follow up RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716546168

From asotona at openjdk.org  Wed Aug 14 09:05:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Aug 2024 09:05:50 GMT
Subject: RFR: 8338014: Improve usage of @jvms tags in class file API [v2]
In-Reply-To: <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
 <WCp43xMSsgdFzhFXUrYuLvVRe3zDtVgFxdFAOxkGaxU=.c23a8fd7-bac4-43e9-be36-0a285825bf09@github.com>
Message-ID: <3h5F2LiPS_yqslX3mp7Hg6vtVPjm7mjXR39v-ae0QMs=.8c7cbb76-ba74-4edc-b51c-b3b9bb836efd@github.com>

On Tue, 13 Aug 2024 14:37:32 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
>> 
>> Thanks, 
>> Sonia
>
> Sonia Zaldana Calles has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8338014' of github.com:SoniaZaldana/jdk into JDK-8338014
>  - Adding parentheses to references which are not part of sentences and removing redundant additions

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20513#pullrequestreview-2237574621

From duke at openjdk.org  Wed Aug 14 09:11:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 14 Aug 2024 09:11:03 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <HTnFZJYDwUcHZV1izmkc1t2WkGId6tbkBwez7qqRhk4=.66eb42a6-416e-4443-8cbc-17c36a855a22@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

I did a series of tests and found that compared with the original MH implementation, the startup performance of the current strategy is significantly improved, and the running performance is neutral.

# 1. Script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline with test
git checkout e733e85eb35b4e67b9209656d287747075f03ece
make test TEST="micro:java.lang.StringConcat"

# current
git checkout 7d481ece8e008c3ae55f29d27d10cb59e86212a1
make test TEST="micro:java.lang.StringConcat"


# 2. Performance numbers
## 2.1 MacBook M1 Pro
[StringFormat.result_mbp_m1.txt](https://github.com/user-attachments/files/16610092/StringFormat.result_mbp_m1.txt)
|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 1005.645 | 1078.414 | -6.75% |
| StringConcat.concat13String | 45.914 | 45.657 | 0.56% |
| StringConcat.concat13StringConst | 72.296 | 65.621 | 10.17% |
| StringConcat.concat23String | 90.946 | 138.887 | -34.52% |
| StringConcat.concat23StringConst | 101.160 | 118.533 | -14.66% |
| StringConcat.concat30Mix | 266.559 | 438.586 | -39.22% |
| StringConcat.concat3String | 12.420 | 15.893 | -21.85% |
| StringConcat.concat4String | 13.885 | 22.751 | -38.97% |
| StringConcat.concat6String | 19.789 | 19.810 | -0.11% |
| StringConcat.concatConst2String | 9.503 | 8.654 | 9.81% |
| StringConcat.concatConst4String | 14.878 | 21.128 | -29.58% |
| StringConcat.concatConst6Object | 51.583 | 53.113 | -2.88% |
| StringConcat.concatConst6String | 19.642 | 19.662 | -0.10% |
| StringConcat.concatConstBool | 3.446 | 3.441 | 0.15% |
| StringConcat.concatConstBoolByte | 6.440 | 6.425 | 0.23% |
| StringConcat.concatConstBoolString | 7.066 | 7.812 | -9.55% |
| StringConcat.concatConstBoolean | 3.984 | 3.957 | 0.68% |
| StringConcat.concatConstBooleanConst | 4.871 | 4.876 | -0.10% |
| StringConcat.concatConstBooleanString | 7.299 | 8.528 | -14.41% |
| StringConcat.concatConstFloat | 56.994 | 53.250 | 7.03% |
| StringConcat.concatConstFloatConst | 55.126 | 54.495 | 1.16% |
| StringConcat.concatConstFloatString | 59.585 | 59.648 | -0.11% |
| StringConcat.concatConstInt | 6.077 | 5.893 | 3.12% |
| StringConcat.concatConstIntConst | 6.840 | 6.606 | 3.54% |
| StringConcat.concatConstIntConstInt | 9.792 | 9.813 | -0.21% |
| StringConcat.concatConstIntString | 14.788 | 11.129 | 32.88% |
| StringConcat.concatConstInteger | 4.025 | 4.002 | 0.57% |
| StringConcat.concatConstIntegerConst | 4.790 | 4.775 | 0.31% |
| StringConcat.concatConstIntegerString | 7.013 | 7.657 | -8.41% |
| StringConcat.concatConstObjectConst | 11.063 | 11.035 | 0.25% |
| StringConcat.concatConstString | 4.983 | 4.969 | 0.28% |
| StringConcat.concatConstStringConst | 8.095 | 6.145 | 31.73% |
| StringConcat.concatConstStringConstInt | 11.894 | 18.877 | -36.99% |
| StringConcat.concatEmptyConstInt | 5.611 | 5.625 | -0.25% |
| StringConcat.concatEmptyConstString | 2.044 | 2.065 | -1.02% |
| StringConcat.concatEmptyLeft | 2.230 | 2.226 | 0.18% |
| StringConcat.concatEmptyRight | 2.370 | 2.369 | 0.04% |
| StringConcat.concatMethodConstString | 5.001 | 4.974 | 0.54% |
| StringConcat.concatMix4String | 80.038 | 146.305 | -45.29% |
| StringConcat.concatStringBoolString | 20.103 | 8.626 | 133.05% |
| StringConcat.concatStringBooleanString | 10.896 | 8.574 | 27.08% |
| StringConcat.concatStringIntString | 18.690 | 11.587 | 61.30% |
| StringConcat.concatStringIntegerString | 9.034 | 8.414 | 7.37% |
| StringConcatStartup.MixedLarge.run | 314.747 | 154.531 | 103.68% |
| StringConcatStartup.MixedSmall.run | 24.384 | 7.222 | 237.64% |
| StringConcatStartup.StringLarge.run | 85.708 | 29.411 | 191.41% |
| StringConcatStartup.StringSingle.constBool | 2.116 | 0.439 | 382.00% |
| StringConcatStartup.StringSingle.constBoolString | 0.263 | 0.654 | -59.79% |
| StringConcatStartup.StringSingle.constBoolean | 0.140 | 0.125 | 12.00% |
| StringConcatStartup.StringSingle.constBooleanString | 3.523 | 0.927 | 280.04% |
| StringConcatStartup.StringSingle.constFloat | 2.625 | 0.568 | 362.15% |
| StringConcatStartup.StringSingle.constFloatString | 4.412 | 1.147 | 284.66% |
| StringConcatStartup.StringSingle.constInt | 2.046 | 0.432 | 373.61% |
| StringConcatStartup.StringSingle.constIntString | 0.154 | 0.096 | 60.42% |
| StringConcatStartup.StringSingle.constInteger | 0.141 | 0.123 | 14.63% |
| StringConcatStartup.StringSingle.constIntegerString | 3.513 | 0.893 | 293.39% |
| StringConcatStartup.StringSingle.constString | 0.142 | 0.122 | 16.39% |
| StringConcatStartup.StringThree.stringIntString | 6.058 | 1.410 | 329.65% |
| StringConcatStartup.StringThree.stringIntegerString | 5.031 | 0.930 | 440.97% |


## 2.2 Aliyun ECS c8a
* Linux AMD CPU (x64)

[StringFormat.result_aliyun_c8a.txt](https://github.com/user-attachments/files/16610085/StringFormat.result_aliyun_c8a.txt)

|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 1163.772 | 1521.357 | -23.50% |
| StringConcat.concat13String | 58.267 | 55.241 | 5.48% |
| StringConcat.concat13StringConst | 89.872 | 80.219 | 12.03% |
| StringConcat.concat23String | 117.712 | 166.671 | -29.37% |
| StringConcat.concat23StringConst | 111.839 | 139.034 | -19.56% |
| StringConcat.concat30Mix | 297.812 | 317.952 | -6.33% |
| StringConcat.concat3String | 12.825 | 12.552 | 2.17% |
| StringConcat.concat4String | 16.092 | 14.993 | 7.33% |
| StringConcat.concat6String | 22.840 | 21.629 | 5.60% |
| StringConcat.concatConst2String | 10.355 | 10.684 | -3.08% |
| StringConcat.concatConst4String | 16.866 | 18.053 | -6.58% |
| StringConcat.concatConst6Object | 49.952 | 50.241 | -0.58% |
| StringConcat.concatConst6String | 23.621 | 24.873 | -5.03% |
| StringConcat.concatConstBool | 3.317 | 3.274 | 1.31% |
| StringConcat.concatConstBoolByte | 6.381 | 5.532 | 15.35% |
| StringConcat.concatConstBoolString | 7.555 | 7.825 | -3.45% |
| StringConcat.concatConstBoolean | 3.573 | 3.578 | -0.14% |
| StringConcat.concatConstBooleanConst | 3.882 | 3.870 | 0.31% |
| StringConcat.concatConstBooleanString | 7.656 | 7.763 | -1.38% |
| StringConcat.concatConstFloat | 41.476 | 39.949 | 3.82% |
| StringConcat.concatConstFloatConst | 42.529 | 40.778 | 4.29% |
| StringConcat.concatConstFloatString | 44.946 | 45.346 | -0.88% |
| StringConcat.concatConstInt | 5.157 | 5.080 | 1.52% |
| StringConcat.concatConstIntConst | 5.695 | 5.723 | -0.49% |
| StringConcat.concatConstIntConstInt | 9.385 | 8.520 | 10.15% |
| StringConcat.concatConstIntString | 9.656 | 9.745 | -0.91% |
| StringConcat.concatConstInteger | 3.431 | 3.425 | 0.18% |
| StringConcat.concatConstIntegerConst | 3.761 | 3.763 | -0.05% |
| StringConcat.concatConstIntegerString | 7.862 | 7.979 | -1.47% |
| StringConcat.concatConstObjectConst | 12.002 | 12.340 | -2.74% |
| StringConcat.concatConstString | 5.556 | 5.514 | 0.76% |
| StringConcat.concatConstStringConst | 8.367 | 7.069 | 18.36% |
| StringConcat.concatConstStringConstInt | 12.663 | 12.489 | 1.39% |
| StringConcat.concatEmptyConstInt | 5.401 | 5.381 | 0.37% |
| StringConcat.concatEmptyConstString | 2.455 | 2.444 | 0.45% |
| StringConcat.concatEmptyLeft | 2.449 | 2.436 | 0.53% |
| StringConcat.concatEmptyRight | 2.591 | 2.573 | 0.70% |
| StringConcat.concatMethodConstString | 5.533 | 5.506 | 0.49% |
| StringConcat.concatMix4String | 82.134 | 84.020 | -2.24% |
| StringConcat.concatStringBoolString | 11.661 | 10.215 | 14.16% |
| StringConcat.concatStringBooleanString | 11.173 | 11.173 | 0.00% |
| StringConcat.concatStringIntString | 14.405 | 13.215 | 9.00% |
| StringConcat.concatStringIntegerString | 10.549 | 10.430 | 1.14% |
| StringConcatStartup.MixedLarge.run | 586.642 | 273.945 | 114.15% |
| StringConcatStartup.MixedSmall.run | 37.213 | 11.103 | 235.16% |
| StringConcatStartup.StringLarge.run | 140.629 | 46.256 | 204.02% |
| StringConcatStartup.StringSingle.constBool | 2.974 | 0.639 | 365.41% |
| StringConcatStartup.StringSingle.constBoolString | 0.356 | 0.928 | -61.64% |
| StringConcatStartup.StringSingle.constBoolean | 0.194 | 0.174 | 11.49% |
| StringConcatStartup.StringSingle.constBooleanString | 5.051 | 1.318 | 283.23% |
| StringConcatStartup.StringSingle.constFloat | 3.716 | 0.844 | 340.28% |
| StringConcatStartup.StringSingle.constFloatString | 6.204 | 1.708 | 263.23% |
| StringConcatStartup.StringSingle.constInt | 2.874 | 0.635 | 352.60% |
| StringConcatStartup.StringSingle.constIntString | 0.219 | 0.133 | 64.66% |
| StringConcatStartup.StringSingle.constInteger | 0.204 | 0.181 | 12.71% |
| StringConcatStartup.StringSingle.constIntegerString | 5.235 | 1.344 | 289.51% |
| StringConcatStartup.StringSingle.constString | 0.191 | 0.175 | 9.14% |
| StringConcatStartup.StringThree.stringIntString | 8.492 | 2.145 | 295.90% |
| StringConcatStartup.StringThree.stringIntegerString | 7.041 | 1.446 | 386.93% |


## 2.3 Aliyun ECS c8i
* Linux Intel CPU (x64)
[StringFormat.result_aliyun_c8i.txt](https://github.com/user-attachments/files/16610087/StringFormat.result_aliyun_c8i.txt)

|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 976.112 | 1362.079 | -28.34% |
| StringConcat.concat13String | 37.720 | 37.310 | 1.10% |
| StringConcat.concat13StringConst | 131.434 | 124.136 | 5.88% |
| StringConcat.concat23String | 133.983 | 106.415 | 25.91% |
| StringConcat.concat23StringConst | 172.257 | 148.726 | 15.82% |
| StringConcat.concat30Mix | 232.886 | 257.292 | -9.49% |
| StringConcat.concat3String | 8.113 | 7.907 | 2.61% |
| StringConcat.concat4String | 9.515 | 8.834 | 7.71% |
| StringConcat.concat6String | 13.369 | 12.307 | 8.63% |
| StringConcat.concatConst2String | 7.850 | 7.603 | 3.25% |
| StringConcat.concatConst4String | 10.727 | 10.240 | 4.76% |
| StringConcat.concatConst6Object | 46.214 | 43.903 | 5.26% |
| StringConcat.concatConst6String | 14.274 | 14.250 | 0.17% |
| StringConcat.concatConstBool | 6.646 | 6.681 | -0.52% |
| StringConcat.concatConstBoolByte | 8.365 | 7.891 | 6.01% |
| StringConcat.concatConstBoolString | 7.846 | 8.699 | -9.81% |
| StringConcat.concatConstBoolean | 7.075 | 6.867 | 3.03% |
| StringConcat.concatConstBooleanConst | 7.775 | 7.743 | 0.41% |
| StringConcat.concatConstBooleanString | 8.597 | 8.334 | 3.16% |
| StringConcat.concatConstFloat | 42.285 | 41.610 | 1.62% |
| StringConcat.concatConstFloatConst | 42.879 | 42.106 | 1.84% |
| StringConcat.concatConstFloatString | 44.812 | 44.550 | 0.59% |
| StringConcat.concatConstInt | 7.472 | 7.445 | 0.36% |
| StringConcat.concatConstIntConst | 7.948 | 8.055 | -1.33% |
| StringConcat.concatConstIntConstInt | 10.593 | 10.235 | 3.50% |
| StringConcat.concatConstIntString | 9.507 | 9.794 | -2.93% |
| StringConcat.concatConstInteger | 5.886 | 5.885 | 0.02% |
| StringConcat.concatConstIntegerConst | 7.203 | 7.182 | 0.29% |
| StringConcat.concatConstIntegerString | 7.729 | 7.634 | 1.24% |
| StringConcat.concatConstObjectConst | 16.048 | 16.491 | -2.69% |
| StringConcat.concatConstString | 6.567 | 6.593 | -0.39% |
| StringConcat.concatConstStringConst | 8.805 | 8.119 | 8.45% |
| StringConcat.concatConstStringConstInt | 10.376 | 11.351 | -8.59% |
| StringConcat.concatEmptyConstInt | 7.178 | 7.154 | 0.34% |
| StringConcat.concatEmptyConstString | 3.713 | 3.705 | 0.22% |
| StringConcat.concatEmptyLeft | 3.610 | 3.594 | 0.45% |
| StringConcat.concatEmptyRight | 3.554 | 3.642 | -2.42% |
| StringConcat.concatMethodConstString | 6.411 | 6.597 | -2.82% |
| StringConcat.concatMix4String | 54.681 | 56.998 | -4.07% |
| StringConcat.concatStringBoolString | 7.586 | 7.672 | -1.12% |
| StringConcat.concatStringBooleanString | 7.923 | 7.807 | 1.49% |
| StringConcat.concatStringIntString | 11.593 | 10.253 | 13.07% |
| StringConcat.concatStringIntegerString | 7.731 | 7.571 | 2.11% |
| StringConcatStartup.MixedLarge.run | 780.243 | 376.343 | 107.32% |
| StringConcatStartup.MixedSmall.run | 51.802 | 15.111 | 242.81% |
| StringConcatStartup.StringLarge.run | 192.342 | 60.500 | 217.92% |
| StringConcatStartup.StringSingle.constBool | 4.495 | 0.941 | 377.68% |
| StringConcatStartup.StringSingle.constBoolString | 0.528 | 1.243 | -57.52% |
| StringConcatStartup.StringSingle.constBoolean | 0.293 | 0.237 | 23.63% |
| StringConcatStartup.StringSingle.constBooleanString | 7.413 | 1.728 | 328.99% |
| StringConcatStartup.StringSingle.constFloat | 5.812 | 1.278 | 354.77% |
| StringConcatStartup.StringSingle.constFloatString | 9.359 | 2.310 | 305.15% |
| StringConcatStartup.StringSingle.constInt | 4.281 | 1.001 | 327.67% |
| StringConcatStartup.StringSingle.constIntString | 0.294 | 0.179 | 64.25% |
| StringConcatStartup.StringSingle.constInteger | 0.283 | 0.228 | 24.12% |
| StringConcatStartup.StringSingle.constIntegerString | 7.213 | 1.683 | 328.58% |
| StringConcatStartup.StringSingle.constString | 0.276 | 0.209 | 32.06% |
| StringConcatStartup.StringThree.stringIntString | 12.289 | 2.824 | 335.16% |
| StringConcatStartup.StringThree.stringIntegerString | 10.503 | 1.923 | 446.18% |


## 2.4 ALiyun ECS c8y
* Linux Arm CPU (aarch64)
[StringFormat.result_aliyun_c8y.txt](https://github.com/user-attachments/files/16610088/StringFormat.result_aliyun_c8y.txt)

|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 1193.343 | 1317.495 | -9.42% |
| StringConcat.concat13String | 50.786 | 45.430 | 11.79% |
| StringConcat.concat13StringConst | 194.426 | 164.292 | 18.34% |
| StringConcat.concat23String | 145.115 | 120.893 | 20.04% |
| StringConcat.concat23StringConst | 229.838 | 226.715 | 1.38% |
| StringConcat.concat30Mix | 319.229 | 364.161 | -12.34% |
| StringConcat.concat3String | 10.958 | 10.370 | 5.67% |
| StringConcat.concat4String | 12.897 | 11.632 | 10.88% |
| StringConcat.concat6String | 16.710 | 15.167 | 10.17% |
| StringConcat.concatConst2String | 18.325 | 10.500 | 74.52% |
| StringConcat.concatConst4String | 17.919 | 13.252 | 35.22% |
| StringConcat.concatConst6Object | 87.184 | 81.847 | 6.52% |
| StringConcat.concatConst6String | 20.055 | 20.952 | -4.28% |
| StringConcat.concatConstBool | 9.528 | 9.090 | 4.82% |
| StringConcat.concatConstBoolByte | 15.628 | 14.653 | 6.65% |
| StringConcat.concatConstBoolString | 15.861 | 11.606 | 36.66% |
| StringConcat.concatConstBoolean | 10.753 | 10.076 | 6.72% |
| StringConcat.concatConstBooleanConst | 12.083 | 12.422 | -2.73% |
| StringConcat.concatConstBooleanString | 12.770 | 13.067 | -2.27% |
| StringConcat.concatConstFloat | 51.561 | 50.420 | 2.26% |
| StringConcat.concatConstFloatConst | 53.687 | 52.982 | 1.33% |
| StringConcat.concatConstFloatString | 53.466 | 53.410 | 0.10% |
| StringConcat.concatConstInt | 10.845 | 9.828 | 10.35% |
| StringConcat.concatConstIntConst | 12.712 | 11.287 | 12.63% |
| StringConcat.concatConstIntConstInt | 14.058 | 13.670 | 2.84% |
| StringConcat.concatConstIntString | 13.832 | 16.458 | -15.96% |
| StringConcat.concatConstInteger | 11.899 | 11.111 | 7.09% |
| StringConcat.concatConstIntegerConst | 13.850 | 13.887 | -0.27% |
| StringConcat.concatConstIntegerString | 15.831 | 14.525 | 8.99% |
| StringConcat.concatConstObjectConst | 26.479 | 26.881 | -1.50% |
| StringConcat.concatConstString | 10.044 | 9.380 | 7.08% |
| StringConcat.concatConstStringConst | 13.301 | 11.200 | 18.76% |
| StringConcat.concatConstStringConstInt | 15.919 | 18.425 | -13.60% |
| StringConcat.concatEmptyConstInt | 10.591 | 10.235 | 3.48% |
| StringConcat.concatEmptyConstString | 6.376 | 6.076 | 4.94% |
| StringConcat.concatEmptyLeft | 6.432 | 6.170 | 4.25% |
| StringConcat.concatEmptyRight | 6.225 | 6.111 | 1.87% |
| StringConcat.concatMethodConstString | 9.718 | 9.552 | 1.74% |
| StringConcat.concatMix4String | 73.730 | 75.615 | -2.49% |
| StringConcat.concatStringBoolString | 10.388 | 9.894 | 4.99% |
| StringConcat.concatStringBooleanString | 10.968 | 11.110 | -1.28% |
| StringConcat.concatStringIntString | 12.599 | 12.020 | 4.82% |
| StringConcat.concatStringIntegerString | 11.930 | 11.939 | -0.08% |
| StringConcatStartup.MixedLarge.run | 724.882 | 320.302 | 126.31% |
| StringConcatStartup.MixedSmall.run | 48.453 | 14.320 | 238.36% |
| StringConcatStartup.StringLarge.run | 158.741 | 51.739 | 206.81% |
| StringConcatStartup.StringSingle.constBool | 3.845 | 0.816 | 371.20% |
| StringConcatStartup.StringSingle.constBoolString | 0.388 | 1.148 | -66.20% |
| StringConcatStartup.StringSingle.constBoolean | 0.243 | 0.200 | 21.50% |
| StringConcatStartup.StringSingle.constBooleanString | 6.473 | 1.580 | 309.68% |
| StringConcatStartup.StringSingle.constFloat | 4.755 | 1.072 | 343.56% |
| StringConcatStartup.StringSingle.constFloatString | 8.233 | 2.019 | 307.78% |
| StringConcatStartup.StringSingle.constInt | 3.724 | 0.800 | 365.50% |
| StringConcatStartup.StringSingle.constIntString | 0.209 | 0.145 | 44.14% |
| StringConcatStartup.StringSingle.constInteger | 0.232 | 0.197 | 17.77% |
| StringConcatStartup.StringSingle.constIntegerString | 6.561 | 1.540 | 326.04% |
| StringConcatStartup.StringSingle.constString | 0.238 | 0.193 | 23.32% |
| StringConcatStartup.StringThree.stringIntString | 11.319 | 2.662 | 325.21% |
| StringConcatStartup.StringThree.stringIntegerString | 9.637 | 1.625 | 493.05% |

## 2.5 AWS ECS C5
* Linux Intel CPU (x65)

[StringFormat.result_aws_c5.txt](https://github.com/user-attachments/files/16610089/StringFormat.result_aws_c5.txt)

|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 2278.946 | 2498.133 | -8.77% |
| StringConcat.concat13String | 99.197 | 95.471 | 3.90% |
| StringConcat.concat13StringConst | 192.350 | 174.860 | 10.00% |
| StringConcat.concat23String | 237.929 | 324.679 | -26.72% |
| StringConcat.concat23StringConst | 271.060 | 284.983 | -4.89% |
| StringConcat.concat30Mix | 556.924 | 607.789 | -8.37% |
| StringConcat.concat3String | 22.134 | 20.345 | 8.79% |
| StringConcat.concat4String | 28.023 | 25.839 | 8.45% |
| StringConcat.concat6String | 41.292 | 38.681 | 6.75% |
| StringConcat.concatConst2String | 16.730 | 16.828 | -0.58% |
| StringConcat.concatConst4String | 29.613 | 29.629 | -0.05% |
| StringConcat.concatConst6Object | 85.482 | 82.400 | 3.74% |
| StringConcat.concatConst6String | 42.033 | 42.510 | -1.12% |
| StringConcat.concatConstBool | 7.067 | 6.994 | 1.04% |
| StringConcat.concatConstBoolByte | 9.980 | 9.053 | 10.24% |
| StringConcat.concatConstBoolString | 13.256 | 12.798 | 3.58% |
| StringConcat.concatConstBoolean | 7.528 | 7.432 | 1.29% |
| StringConcat.concatConstBooleanConst | 8.712 | 8.661 | 0.59% |
| StringConcat.concatConstBooleanString | 13.337 | 12.514 | 6.58% |
| StringConcat.concatConstFloat | 60.324 | 59.159 | 1.97% |
| StringConcat.concatConstFloatConst | 61.755 | 60.417 | 2.21% |
| StringConcat.concatConstFloatString | 68.358 | 70.086 | -2.47% |
| StringConcat.concatConstInt | 8.657 | 8.977 | -3.56% |
| StringConcat.concatConstIntConst | 9.255 | 9.251 | 0.04% |
| StringConcat.concatConstIntConstInt | 13.937 | 13.282 | 4.93% |
| StringConcat.concatConstIntString | 15.815 | 15.634 | 1.16% |
| StringConcat.concatConstInteger | 6.757 | 6.724 | 0.49% |
| StringConcat.concatConstIntegerConst | 8.080 | 8.051 | 0.36% |
| StringConcat.concatConstIntegerString | 13.460 | 12.847 | 4.77% |
| StringConcat.concatConstObjectConst | 19.584 | 19.376 | 1.07% |
| StringConcat.concatConstString | 9.148 | 9.162 | -0.15% |
| StringConcat.concatConstStringConst | 12.574 | 11.360 | 10.69% |
| StringConcat.concatConstStringConstInt | 16.472 | 17.830 | -7.62% |
| StringConcat.concatEmptyConstInt | 9.418 | 9.485 | -0.71% |
| StringConcat.concatEmptyConstString | 4.027 | 4.018 | 0.22% |
| StringConcat.concatEmptyLeft | 4.284 | 4.285 | -0.02% |
| StringConcat.concatEmptyRight | 4.392 | 4.400 | -0.18% |
| StringConcat.concatMethodConstString | 9.076 | 9.186 | -1.20% |
| StringConcat.concatMix4String | 158.463 | 152.295 | 4.05% |
| StringConcat.concatStringBoolString | 18.256 | 16.784 | 8.77% |
| StringConcat.concatStringBooleanString | 18.087 | 16.824 | 7.51% |
| StringConcat.concatStringIntString | 22.540 | 21.448 | 5.09% |
| StringConcat.concatStringIntegerString | 17.860 | 17.747 | 0.64% |
| StringConcatStartup.MixedLarge.run | 914.410 | 416.416 | 119.59% |
| StringConcatStartup.MixedSmall.run | 58.886 | 17.765 | 231.47% |
| StringConcatStartup.StringLarge.run | 220.709 | 70.726 | 212.06% |
| StringConcatStartup.StringSingle.constBool | 4.955 | 1.062 | 366.57% |
| StringConcatStartup.StringSingle.constBoolString | 0.576 | 1.520 | -62.11% |
| StringConcatStartup.StringSingle.constBoolean | 0.311 | 0.263 | 18.25% |
| StringConcatStartup.StringSingle.constBooleanString | 8.322 | 2.145 | 287.97% |
| StringConcatStartup.StringSingle.constFloat | 6.136 | 1.396 | 339.54% |
| StringConcatStartup.StringSingle.constFloatString | 10.110 | 2.803 | 260.68% |
| StringConcatStartup.StringSingle.constInt | 4.814 | 1.073 | 348.65% |
| StringConcatStartup.StringSingle.constIntString | 0.312 | 0.202 | 54.46% |
| StringConcatStartup.StringSingle.constInteger | 0.294 | 0.278 | 5.76% |
| StringConcatStartup.StringSingle.constIntegerString | 8.129 | 2.123 | 282.90% |
| StringConcatStartup.StringSingle.constString | 0.283 | 0.253 | 11.86% |
| StringConcatStartup.StringThree.stringIntString | 14.069 | 3.514 | 300.37% |
| StringConcatStartup.StringThree.stringIntegerString | 11.896 | 2.206 | 439.26% |


# 3. Summary:
1. The startup performance has been significantly improved, but the scenario StringConcatStartup.StringSingle.constBoolString has decreased, which is surprising. It may be that the JVM was warmed up during startup.

2. When the number of parameters is greater than the default inline threshold of 16, some scenarios will have performance regression, such as

StringConcat.concat123String
StringConcat.concat30Mix

These scenarios were originally implemented based on StringBuilder, not compared with MH. Whether to ignore or add StringBuilder implementation in the code.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288243097

From duke at openjdk.org  Wed Aug 14 09:13:57 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 14 Aug 2024 09:13:57 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <9IG7yay_pakXNtvw_c-JsWU6533v5WXHJkBybKf0jng=.925a81e9-1e8a-45f0-b743-a9286a599a35@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
 <9IG7yay_pakXNtvw_c-JsWU6533v5WXHJkBybKf0jng=.925a81e9-1e8a-45f0-b743-a9286a599a35@github.com>
Message-ID: <NkoTgUgMp_JzoqQP1e4oXSVQW5DMaZI5ka7ypcujrdw=.6a2241aa-911a-4a0f-9607-7cb55374b73f@github.com>

On Wed, 14 Aug 2024 07:47:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Tier 1-5 testing passed (a few unrelated test failures)

Is there any work for me to do?

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288249819

From asotona at openjdk.org  Wed Aug 14 09:13:59 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Aug 2024 09:13:59 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v10]
In-Reply-To: <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
Message-ID: <hdWhMTIYi9hVMdGK92lj--c4-ncreGYKr1Z2Yu7akr4=.1a300276-2fd1-4549-9eb3-42d9c0054c21@github.com>

On Tue, 13 Aug 2024 19:56:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed JLS prefix from web review

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2237594219

From aboldtch at openjdk.org  Wed Aug 14 09:24:34 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 09:24:34 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v19]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <4g1C6IMPhW60t2IygFaP6KBhaOtr0VEepPM2D6fWMPE=.91c3d202-a5e1-4669-9846-e89e6a360e91@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Use jdk.test.lib.Utils.getRandomInstance()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/3f29e6d6..4d67422f

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

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

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

From redestad at openjdk.org  Wed Aug 14 09:36:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Aug 2024 09:36:01 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <NkoTgUgMp_JzoqQP1e4oXSVQW5DMaZI5ka7ypcujrdw=.6a2241aa-911a-4a0f-9607-7cb55374b73f@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
 <9IG7yay_pakXNtvw_c-JsWU6533v5WXHJkBybKf0jng=.925a81e9-1e8a-45f0-b743-a9286a599a35@github.com>
 <NkoTgUgMp_JzoqQP1e4oXSVQW5DMaZI5ka7ypcujrdw=.6a2241aa-911a-4a0f-9607-7cb55374b73f@github.com>
Message-ID: <ncQFuaZffZirIJ_d1WWcEs68lDtYIMKB22Hd6NKuuJY=.f0894ef8-df71-4c32-9a6c-3b3222540a88@github.com>

On Wed, 14 Aug 2024 09:11:21 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Is there any work for me to do?

No, barring any further review comments from others I think we're good for this PR. 

Reaching out and getting help evaluating this at scale would be very valuable. So far I've only seen positives when testing this out on other benchmarks, especially startup tests. 

I'm of course biased, but I think this work already represents a significant move forward by much reducing startup and warmup overheads -- while staying mostly throughput neutral (with a few noisy exceptions).

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288290860

From aboldtch at openjdk.org  Wed Aug 14 09:37:59 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 14 Aug 2024 09:37:59 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <Nt7rViCh3ufr94M4mx4U0sSwjkmLfhEyoeqdfWMgqK0=.9101c1d4-fb06-4747-bc57-771e05849657@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
 <Nt7rViCh3ufr94M4mx4U0sSwjkmLfhEyoeqdfWMgqK0=.9101c1d4-fb06-4747-bc57-771e05849657@github.com>
Message-ID: <kb36HycZkfg2pv_gFmvuht9uUJqYt0HB7Ad5KazAs2I=.883111da-811c-4edf-ae52-323318b113c2@github.com>

On Tue, 13 Aug 2024 21:56:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace and nits
>
> src/hotspot/share/runtime/vframe.cpp line 252:
> 
>> 250:           if (mark.has_monitor()) {
>> 251:             ObjectMonitor* mon = ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
>> 252:             if (// if the monitor is null we must be in the process of locking
> 
> nit - please add a space after `(`

Should I align the rest of the lines? Adding the extra space here looks strange to me. But the inlined comments looks strange as well. This is all pre-existing code that just moved around a bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1716616351

From duke at openjdk.org  Wed Aug 14 09:47:55 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 14 Aug 2024 09:47:55 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <j6h01uMHxqqg4l_2lxoPUyW1df_gkrr1SfeQiy0xkuw=.b3206981-2b64-4d86-ba20-a042ed37d763@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

In the `StringConcat.concat123String` scenario, setting the inlineThreshold to 150 still shows a performance improvement, although this is crazy. But this can be used as a performance optimization parameter.

Here are the performance numbers for the current version running on a MacBook M1 Pro


make test TEST="micro:java.lang.StringConcat.concat123String" 

Benchmark                     (intValue)  Mode  Cnt     Score   Error  Units
StringConcat.concat123String        4711  avgt   15  1089.723 ? 9.913  ns/op

make test TEST="micro:java.lang.StringConcat.concat123String" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.inlineThreshold=150"

Benchmark                     (intValue)  Mode  Cnt    Score    Error  Units
StringConcat.concat123String        4711  avgt   15  719.557 ? 10.208  ns/op

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288314682

From redestad at openjdk.org  Wed Aug 14 10:01:57 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Aug 2024 10:01:57 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <j6h01uMHxqqg4l_2lxoPUyW1df_gkrr1SfeQiy0xkuw=.b3206981-2b64-4d86-ba20-a042ed37d763@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
 <j6h01uMHxqqg4l_2lxoPUyW1df_gkrr1SfeQiy0xkuw=.b3206981-2b64-4d86-ba20-a042ed37d763@github.com>
Message-ID: <3SrBhTYcJuqAF8oRhm5OzA3zte5qW1-FCJVo7LKPhE0=.b14070e7-83e5-4406-be37-cdd2a4f742ad@github.com>

On Wed, 14 Aug 2024 09:45:24 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> In the `StringConcat.concat123String` scenario, setting the inlineThreshold to 150 still shows a performance improvement, although this is crazy. But this can be used as a performance optimization parameter.

I'd suggest looking at JIT compilation overheads when doing any such tuning, though: `-XX:CompileCommand=MemStat,*::concat123*,print` for example will show that cost of compiling `concat123String` goes up by orders of magnitude, both in time and memory use. It's less extreme than for the MH-based implementation, but still I think it's a feature of the new implementation that we do less force inlining at the high end.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288342800

From duke at openjdk.org  Wed Aug 14 11:00:58 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 14 Aug 2024 11:00:58 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <mGabnQmhb1M8quowk_ENdB5GBR3QuApaAWgXl1AqfAg=.53896dc7-58d0-4e05-aab2-3c49c4c21764@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

When the number of parameters is large, such as greater than the current threshold of 16, the possibility of reuse will be very low. At this time, we can not use the cache and directly generate constants in the bytecode, which can be used as a follow-up work.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288448113

From redestad at openjdk.org  Wed Aug 14 11:10:58 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Aug 2024 11:10:58 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <Ka7cFkXV91f0q3y1DHpeE56tTesZRXWmyS1-EriAd0g=.a0123dc6-bfbf-4e94-9695-97eaa972a397@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

Sure, specialization is a great topic for future work and research. Ideally we would want something that can leverage the existing framework for profiling and customizing MHs and customize to a specialized form when it's deemed profitable.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2288464676

From alan.bateman at oracle.com  Wed Aug 14 11:31:54 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 14 Aug 2024 12:31:54 +0100
Subject: compatibility impact of JDK-8325621 (Improve jspawnhelper version
 checks)
In-Reply-To: <CAL4QsgvmX7UDTTB79eds+JM3Lmj3_BrSJ820jc1LT_bEKse7ug@mail.gmail.com>
References: <CAL4QsgvmX7UDTTB79eds+JM3Lmj3_BrSJ820jc1LT_bEKse7ug@mail.gmail.com>
Message-ID: <59a110b9-2946-46b1-be24-aab47c635aea@oracle.com>

On 13/08/2024 17:48, Liam Miller-Cushon wrote:
> Hi,
>
> I have a data point to share on the compatibility impact of
> JDK-8325621 (Improve jspawnhelper version checks), which was
> backported to earlier release trains.
>
> As a result of that change, doing an in-place upgrade from 22.0.1 to
> 22.0.2 breaks long-running Java applications that create subprocesses.
> This is an expected consequence of the change, which adds version
> checks to jspawnhelper to detect if a JVM is updated in-place to a
> version with an incompatible jspawnhelper.
>
> I'm curious if the list has suggestions on the best way to mitigate
> the compatibility impact. One possibility is that replacing a JVM
> in-place for a running process should never happen, and installers
> should use new directories, or ensure any long-running Java processes
> are shut down during the upgrade. Is that considered a best practice?
>
There was some discussion about this scenario at the time (someone 
brought it up here). I think the summary is that upgrading in-place with 
running VMs isn't a good idea. When upgrading like this then you need to 
ensure that all usages are shutdown first.

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

From jpai at openjdk.org  Wed Aug 14 11:44:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 14 Aug 2024 11:44:08 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
 [v9]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <8vhOrUuChIsS-WydzDA2wnbnQOzYRg6yabkqf56Ey4c=.e0ca6a02-390e-4084-93e2-28c91a3b3f88@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 19 commits:

 - merge latest from master branch
 - merge latest from master branch
 - 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
 - ... and 9 more: https://git.openjdk.org/jdk/compare/3dd07b91...49abed2e

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

Changes: https://git.openjdk.org/jdk/pull/2752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=2752&range=08
  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 syan at openjdk.org  Wed Aug 14 12:08:50 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 14 Aug 2024 12:08:50 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v3]
In-Reply-To: <bV_dhvlSPFgsvq-DtnqbKrFrqBCVAocF-6ZDBaN3Xfk=.f0b810c3-70b5-44e1-b6d2-c06560000d79@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <qYlDMFi4Z_E0F6ipu3EzaKl0TWr6-65JHc6H-LiOAUc=.a70eae2d-15a6-4c78-a319-83aa3b6c6805@github.com>
 <Wfcla1lC25tl6dDXHUDyqTo3VnNCMw8vWyYjB2VksI8=.5652d072-d9a3-4162-9786-af97f17a7a6b@github.com>
 <ts6GhXeUowc-PjrNOjqPJeCRcK3ukchrsQMCGM7g9HE=.d940a280-efc9-4022-a356-b0793f807ac0@github.com>
 <CvG1vWBDO1elw3nULkPHV-3aBARkinOXedCrEkPOsnU=.935b647d-1c3f-442d-8485-2a13abfaed82@github.com>
 <Q7h_Fv3raigdjimuDmwDwnWhdOAUxGknf-eMMN1AKfg=.f7dcc182-e4d9-4830-947d-86d91e0e5b3a@github.com>
 <bV_dhvlSPFgsvq-DtnqbKrFrqBCVAocF-6ZDBaN3Xfk=.f0b810c3-70b5-44e1-b6d2-c06560000d79@github.com>
Message-ID: <4Xnk9_8fEAOIRHL9K9KkYTZ9WSGYr5-c-7aSKJ-vUuQ=.30e8d4e3-6650-477d-8cba-73efd7e4728d@github.com>

On Thu, 25 Jul 2024 13:23:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group.
>> 
>> Currently we observer only this test fails of tier1.
>
>> > Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group.
>> 
>> Currently we observer only this test fails of tier1.
> 
> Is this because you only run tier1 or do you mean this is the only test that fails?

@AlanBateman Does this PR suitable to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2288566011

From liach at openjdk.org  Wed Aug 14 13:30:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Aug 2024 13:30:58 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <NMoxJKohWG3-swgETqpgRZPHBT-9Skp-pFJaBIDFZNU=.1118d3da-dd3e-4789-8025-56e81678e829@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

Thanks for this patch and the unloading test.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20273#pullrequestreview-2238171369

From alanb at openjdk.org  Wed Aug 14 13:30:56 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Aug 2024 13:30:56 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]
In-Reply-To: <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
Message-ID: <q_JqnFViGdgPVKi0AeJjbzceGHgi5Y1txGo49raAkQc=.58d3393e-4c0e-440d-a716-0ddbd3e18e54@github.com>

On Thu, 20 Jun 2024 19:17:25 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:
> 
>   Expanding coverage of remove()

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19527#pullrequestreview-2238171169

From alanb at openjdk.org  Wed Aug 14 13:30:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Aug 2024 13:30:57 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v3]
In-Reply-To: <PaAlrwQm_PJNGZOt_3DPmVUOiil94nfHw8KZ0r80-a4=.bb6780d6-0e6a-4feb-aaf1-e24bb575a1fc@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>
 <PaAlrwQm_PJNGZOt_3DPmVUOiil94nfHw8KZ0r80-a4=.bb6780d6-0e6a-4feb-aaf1-e24bb575a1fc@github.com>
Message-ID: <S3WtdE5A0uN3Ce7OV4t-4HyHfhy-CL-jpWho3dN8IBQ=.73b4ee44-090f-42ca-bf15-9e8656a66d56@github.com>

On Wed, 19 Jun 2024 12:52:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman -- could you please take a look? Thanks.
>
>> @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 change? Part of me wonders if remove(int) needs to do the same as someone will show up sometime to ask.

> @AlanBateman review please.

Yes, I think this is okay.

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

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

From prappo at openjdk.org  Wed Aug 14 13:43:07 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Aug 2024 13:43:07 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos
Message-ID: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>

This PR fixes a few trivial grammar issues and typos in documentation.

The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).

I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  

* https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
* https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 

@DougLea, thoughts?

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

Commit messages:
 - Initial commit

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

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

From alanb at openjdk.org  Wed Aug 14 13:54:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Aug 2024 13:54:51 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v3]
In-Reply-To: <bV_dhvlSPFgsvq-DtnqbKrFrqBCVAocF-6ZDBaN3Xfk=.f0b810c3-70b5-44e1-b6d2-c06560000d79@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <qYlDMFi4Z_E0F6ipu3EzaKl0TWr6-65JHc6H-LiOAUc=.a70eae2d-15a6-4c78-a319-83aa3b6c6805@github.com>
 <Wfcla1lC25tl6dDXHUDyqTo3VnNCMw8vWyYjB2VksI8=.5652d072-d9a3-4162-9786-af97f17a7a6b@github.com>
 <ts6GhXeUowc-PjrNOjqPJeCRcK3ukchrsQMCGM7g9HE=.d940a280-efc9-4022-a356-b0793f807ac0@github.com>
 <CvG1vWBDO1elw3nULkPHV-3aBARkinOXedCrEkPOsnU=.935b647d-1c3f-442d-8485-2a13abfaed82@github.com>
 <Q7h_Fv3raigdjimuDmwDwnWhdOAUxGknf-eMMN1AKfg=.f7dcc182-e4d9-4830-947d-86d91e0e5b3a@github.com>
 <bV_dhvlSPFgsvq-DtnqbKrFrqBCVAocF-6ZDBaN3Xfk=.f0b810c3-70b5-44e1-b6d2-c06560000d79@github.com>
Message-ID: <KkKknY-HJ6bQjvWELxOjjS4iM6HnKmsCiCNsRYzoJ9Y=.c2cbe929-3ae0-4ff1-82f0-3e51e5251db2@github.com>

On Thu, 25 Jul 2024 13:23:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group.
>> 
>> Currently we observer only this test fails of tier1.
>
>> > Okay, but doesn't mean that lots of other tests will fail too, esp. tests in jdk_nio test group.
>> 
>> Currently we observer only this test fails of tier1.
> 
> Is this because you only run tier1 or do you mean this is the only test that fails?

> @AlanBateman Does this PR suitable to integrate.

The testing scenario is very unusual but I think it's okay to skip when POSIX permissions aren't supported.

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

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2288819987

From duke at openjdk.org  Wed Aug 14 14:08:53 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 14 Aug 2024 14:08:53 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]
In-Reply-To: <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
Message-ID: <EAe5EC2PQwfvw3M2Y1ZxxnaFDEK1D3dfcHhdCrSOPyc=.350ddb61-37c0-4db5-8425-299cbfbe6366@github.com>

On Thu, 20 Jun 2024 19:17:25 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:
> 
>   Expanding coverage of remove()

Thank you!

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

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

From duke at openjdk.org  Wed Aug 14 14:08:53 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 14:08:53 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]
In-Reply-To: <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
Message-ID: <3OQOhvNZyeNQ_a9v-HLoM4R6NQzM_gDBtKZQ8S3GmRI=.7c24529e-78a3-4ef7-b088-36353cbe7ab2@github.com>

On Thu, 20 Jun 2024 19:17:25 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:
> 
>   Expanding coverage of remove()

@jengebr 
Your change (at version 2ff93ab6f752ad285411d635c7755e9f47a571b2) is now ready to be sponsored by a Committer.

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

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

From shade at openjdk.org  Wed Aug 14 14:14:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 14:14:55 GMT
Subject: RFR: 8332842: Optimize empty CopyOnWriteArrayList allocations [v4]
In-Reply-To: <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
References: <lN1gbLh3gbk9i40n-3uBH83Gx0auhmgvPv4WPZ9r5To=.12c5a887-10e4-4cbe-9582-2416a80f1aeb@github.com>
 <Uc7S5PnY_epb6X8ABFmHfwsckP2LdjouegGbJ1iTV8k=.19dec2aa-7fc2-421c-8821-f83071f3df37@github.com>
Message-ID: <rmn42e05K6jvXXgSOxL4P1cc8qPDzPFKkezi44PC00Y=.010a437a-b499-4675-a084-be604e9ea548@github.com>

On Thu, 20 Jun 2024 19:17:25 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:
> 
>   Expanding coverage of remove()

Still good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19527#pullrequestreview-2238308683

From duke at openjdk.org  Wed Aug 14 14:14:56 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 14 Aug 2024 14:14:56 GMT
Subject: Integrated: 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: <TSrPwu-SipRuJguLcy4Rwu2XBFcP9m0BzPPoPfNIP78=.c1cca809-a3b0-4b14-9708-f6f72be7ec0f@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
> 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

This pull request has now been integrated.

Changeset: a5d948fb
Author:    John Engebretson <jengebr at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a5d948fb9841f654cccc9567c60e8d28e7d719ae
Stats:     184 lines in 2 files changed: 180 ins; 0 del; 4 mod

8332842: Optimize empty CopyOnWriteArrayList allocations

Reviewed-by: shade, alanb

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

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

From dcubed at openjdk.org  Wed Aug 14 15:10:56 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Aug 2024 15:10:56 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v16]
In-Reply-To: <kb36HycZkfg2pv_gFmvuht9uUJqYt0HB7Ad5KazAs2I=.883111da-811c-4edf-ae52-323318b113c2@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <I8WQ5Yvb-WaWULSJrSbmpA2L26lLppL7z93pjPMbW00=.35e81818-e0f3-47ce-abdb-e4cb2cc4782f@github.com>
 <Nt7rViCh3ufr94M4mx4U0sSwjkmLfhEyoeqdfWMgqK0=.9101c1d4-fb06-4747-bc57-771e05849657@github.com>
 <kb36HycZkfg2pv_gFmvuht9uUJqYt0HB7Ad5KazAs2I=.883111da-811c-4edf-ae52-323318b113c2@github.com>
Message-ID: <qq8b8MC1hbRvr43sU16rUdhhlVmlGPkl-jKhMP5UP7o=.85467944-cc1e-4048-b533-1552ed2bdd6c@github.com>

On Wed, 14 Aug 2024 09:35:10 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> src/hotspot/share/runtime/vframe.cpp line 252:
>> 
>>> 250:           if (mark.has_monitor()) {
>>> 251:             ObjectMonitor* mon = ObjectSynchronizer::read_monitor(current, monitor->owner(), mark);
>>> 252:             if (// if the monitor is null we must be in the process of locking
>> 
>> nit - please add a space after `(`
>
> Should I align the rest of the lines? Adding the extra space here looks strange to me. But the inlined comments looks strange as well. This is all pre-existing code that just moved around a bit.

I'm just not fond of a `// comment` butting right against code.
Your call on whether to leave it alone or how to reformat it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717114224

From syan at openjdk.org  Wed Aug 14 15:46:51 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 14 Aug 2024 15:46:51 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v3]
In-Reply-To: <KkKknY-HJ6bQjvWELxOjjS4iM6HnKmsCiCNsRYzoJ9Y=.c2cbe929-3ae0-4ff1-82f0-3e51e5251db2@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <qYlDMFi4Z_E0F6ipu3EzaKl0TWr6-65JHc6H-LiOAUc=.a70eae2d-15a6-4c78-a319-83aa3b6c6805@github.com>
 <Wfcla1lC25tl6dDXHUDyqTo3VnNCMw8vWyYjB2VksI8=.5652d072-d9a3-4162-9786-af97f17a7a6b@github.com>
 <ts6GhXeUowc-PjrNOjqPJeCRcK3ukchrsQMCGM7g9HE=.d940a280-efc9-4022-a356-b0793f807ac0@github.com>
 <CvG1vWBDO1elw3nULkPHV-3aBARkinOXedCrEkPOsnU=.935b647d-1c3f-442d-8485-2a13abfaed82@github.com>
 <Q7h_Fv3raigdjimuDmwDwnWhdOAUxGknf-eMMN1AKfg=.f7dcc182-e4d9-4830-947d-86d91e0e5b3a@github.com>
 <bV_dhvlSPFgsvq-DtnqbKrFrqBCVAocF-6ZDBaN3Xfk=.f0b810c3-70b5-44e1-b6d2-c06560000d79@github.com>
 <KkKknY-HJ6bQjvWELxOjjS4iM6HnKmsCiCNsRYzoJ9Y=.c2cbe929-3ae0-4ff1-82f0-3e51e5251db2@github.com>
Message-ID: <IWFXUz-7cAduMHQh36axMmJOmV7jsCqNqtemqtTdSSA=.bf3ac990-a873-481c-9b89-56c49a9d1bcf@github.com>

On Wed, 14 Aug 2024 13:52:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The testing scenario is very unusual but I think it's okay to skip when POSIX permissions aren't supported.

Thanks. /integrate

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

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2289149517

From duke at openjdk.org  Wed Aug 14 15:53:49 2024
From: duke at openjdk.org (duke)
Date: Wed, 14 Aug 2024 15:53:49 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v4]
In-Reply-To: <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
Message-ID: <Ecgk_lkxie3wOZ-8buK-Pc5bJ8Vlz1Vs_Oz9rrm0kYg=.dfbf7404-4b7c-4f20-a67a-60131872c39b@github.com>

On Fri, 26 Jul 2024 06:29:05 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.
>> 
>> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails.
>> 
>> 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 the exception's toString() into SkipException

@sendaoYan 
Your change (at version b3af3f87486d7641011f6b3fd8bb0e7521711a1a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2289163041

From sgehwolf at openjdk.org  Wed Aug 14 16:53:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 14 Aug 2024 16:53:56 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v20]
In-Reply-To: <armE1TJT6euiIdqBUr7syBd5IAuArt4sTywLVp0CSgU=.4d85d1c0-d07a-4d3f-b2ed-6d871d1ec731@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <armE1TJT6euiIdqBUr7syBd5IAuArt4sTywLVp0CSgU=.4d85d1c0-d07a-4d3f-b2ed-6d871d1ec731@github.com>
Message-ID: <Ikvesf5FPkQc0ZD4A3yfb7pKekPzA539BoxXq5TNgQY=.f74eb83d-6763-4eed-bb07-b128f969b91a@github.com>

On Wed, 14 Aug 2024 02:59:33 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Fix by  Severin Gehwolf.
>> Testcase by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Testcase update upon review by Severin Gehwolf

I've got my quibbles with the NestedCgroup test. In a nutshell, `TestTwoLimits` and `TestNoController` are the same. Only for the latter the `cpu` controller is enabled, we set the same `memory` limits for that tree and then assert the same as for `TestTwoLimits`. I have to ask: why is `TestNoController` useful? It might have been in some version of the patch, but not in its current form. In OpenJDK we just assume that certain controllers (`cpu` and `memory` are enabled). If they aren't then we return unlimited. We don't look at `cgroup.subtree_control` files.

That leaves `TestTwoLimits` which essentially tests for a system that's badly configured and we haven't seen in the wild. For what purpose? So that we encode in a test what we know we don't yet support, because "you ain't gonna need it". If you really insist to keep it, then please clean it up. I've spent way too many cycles understanding it and would like to spare somebody else needing to do the same.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 91:

> 89: 
> 90:         public Test(String controller_) throws Exception {
> 91:             controller = controller_;

You are re-assigning a static class value's value in a constructor. This is bound to break.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 109:

> 107: 
> 108:             // Alpine Linux 3.20.1 needs cgcreate1 otherwise:
> 109:             // cgcreate: can't create cgroup [...]: No such file or directory

Suggestion:

            // Create the parent cgroup hierarchy

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 118:

> 116:              || output.contains("cgcreate: can't create cgroup " + CGROUP_OUTER + ": Cgroup, requested group parameter does not exist")) {
> 117:                 throw new SkippedException("Missing root permission: " + output.getStderr());
> 118:             }

That we are the UID 0 ought to be checked in `NestedCgroup.main` before any test is being run. Not here somewhere down the line. Use `Platform.isRoot()`.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 139:

> 137:             } else {
> 138:               throw new IllegalArgumentException();
> 139:             }

This can be done once in `NestedCgroup.main` and then passed in on instantiation of `Test*` classes.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 146:

> 144: 
> 145:             HookResult hookResult = hook();
> 146:             // C++ CgroupController

Please remove this comment (or rephrase). It's not useful as it is.

test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 160:

> 158:             HookResult hookResult = new HookResult();
> 159: 
> 160:             // CgroupV1Subsystem::read_memory_limit_in_bytes considered hierarchical_memory_limit only when inner memory.limit_in_bytes is unlimited.

There is no `hierarchical_memory_limit` any more. Please remove the comment. It might get stale soon. If you really want a comment add a more high level one.

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

PR Review: https://git.openjdk.org/jdk/pull/17198#pullrequestreview-2237962572
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1717191803
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1717095471
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1716837525
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1717193195
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1717096997
PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1716803597

From sgehwolf at openjdk.org  Wed Aug 14 16:53:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 14 Aug 2024 16:53:57 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v19]
In-Reply-To: <kc3sPHmAj7e37Z6QNA9BoA9PkG0wXfO_NlSC-7sDoRY=.722cf7e7-6c20-4da6-a89b-89d87d1763d2@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <UJEH6O85W5S7EPcsD74dXIcXqmYamjdsDuKeSb0ID-Y=.492ccb0e-85eb-41d4-a9ad-3f4fc47a1bb4@github.com>
 <al8-84qIReC0un3wrpfUBFS8d2Xbfzxc4yqCVaWkzlY=.958d09a8-afc1-41fb-8dce-e6adb9823dee@github.com>
 <kc3sPHmAj7e37Z6QNA9BoA9PkG0wXfO_NlSC-7sDoRY=.722cf7e7-6c20-4da6-a89b-89d87d1763d2@github.com>
Message-ID: <u4O2lzhvycEgER3-TfMgCFk3Nh2zVigOtBtt55zWt-0=.aa28e3a4-e191-4f1f-b27c-7cb0e656327c@github.com>

On Wed, 14 Aug 2024 03:26:02 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 217:
>> 
>>> 215: 
>>> 216:             // KFAIL - verify the CgroupSubsystem::initialize_hierarchy() and jdk.internal.platform.CgroupSubsystem.initializeHierarchy() bug
>>> 217:             // TestTwoLimits does not see the lower MEMORY_MAX_OUTER limit.
>> 
>> Remove this obsolete(?) comment.
>
> This comment is documenting what the `TestTwoLimits` testcase does. Which I find useful.
> It is KFAIL - Known Failure - the current OpenJDK code does not properly simulate what Linux kernel does. If you do:
> 
> cgset -r memory.max=$[1024*1024*1024] a/b
> cgset -r memory.max=$[512*1024] a
> cgexec -g memory:a/b java...
> 
> Then OpenJDK thinks it is `1024*1024*1024 KB` but Linux kernel will limit OpenJDK to `512*1024 KB`. So this problem is documented and tested.

I see. Please update the comment. `KFAIL` isn't something I was familiar with as an acronym. Code/method references in tests don't seem appropriate since as soon as the code gets changed the comment is out of date/misleading. Refrain from having references to code.

More general remarks:
- No well-behaved system should set the limit at a deeper nesting level to anything non-`max`. That's why the code currently doesn't handle it. It's an optimization if you will and I don't see the benefit of walking the full hierarchy every time for such bad systems.
- Please use a more high level comment for this test. Something like `"Since only non-well-behaved systems have a higher limit (other than unlimited) at a lower hierarchy level in the tree we stop iterating once we've encountered a limit that is not unlimited (-1). This test simulates this by asserting that the first non-unlimited value is detected by HotSpot, not the actual enforced limit of the kernel higher up the hierarchy."`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1716819006

From liach at openjdk.org  Wed Aug 14 17:12:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Aug 2024 17:12:04 GMT
Subject: RFR: 8338406: BytecodeHelpers using wrong bootstrap method descriptor
 for condy
Message-ID: <U9Xicf-Myj2Hr0JYiiD6A9DuHroF4oYjZVRu8lZ8ys0=.3854987d-6d7e-4032-b04c-8ae4da3ca20b@github.com>

`BytecodeHelpers.handleConstantDescToHandleInfo` is incorrectly using `DirectMethodHandleDesc.invocationType`, which accidentally works for static bootstrap methods so it's discovered only now with more extensive testing from bytebuddy. Cleaned up by reusing the correct `handleDescToHandleInfo` instead. Thanks to @raphw for the report.

For now, a workaround can be instead of using `DynamicConstantDesc`, translate to `ConstantDynamicEntry` in user applications.

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

Commit messages:
 - Copyright year
 - 8338406: BytecodeHelpers using wrong invocation descriptor for condy

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

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

From mgronlun at openjdk.org  Wed Aug 14 20:58:03 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 14 Aug 2024 20:58:03 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the JFR
 string pool monitor
Message-ID: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>

Greetings,

Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.

During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.

A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.

Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 

Testing: jdk_jfr

Thanks
Markus

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

Commit messages:
 - 8338417

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

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

From duke at openjdk.org  Wed Aug 14 21:05:51 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Wed, 14 Aug 2024 21:05:51 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos
In-Reply-To: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
Message-ID: <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>

On Wed, 14 Aug 2024 13:38:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR fixes a few trivial grammar issues and typos in documentation.
> 
> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
> 
> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
> 
> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
> 
> @DougLea, thoughts?

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1075:

> 1073:     /**
> 1074:      * Tries to join this task, returning true if it completed
> 1075:      * (possibly exceptionally) before the given timeout elapses and

Seems like mixed tense now: do we want completes/elapses or completed/elapsed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1717549619

From dcubed at openjdk.org  Wed Aug 14 21:07:59 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Aug 2024 21:07:59 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v19]
In-Reply-To: <4g1C6IMPhW60t2IygFaP6KBhaOtr0VEepPM2D6fWMPE=.91c3d202-a5e1-4669-9846-e89e6a360e91@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <4g1C6IMPhW60t2IygFaP6KBhaOtr0VEepPM2D6fWMPE=.91c3d202-a5e1-4669-9846-e89e6a360e91@github.com>
Message-ID: <ri8r6ZteeyIQqs8MZL6FSv7v6JPK7ezVsn1RB1RCMY8=.3b249cbf-a41e-4764-b30d-0fc35a7598b5@github.com>

On Wed, 14 Aug 2024 09:24:34 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jdk.test.lib.Utils.getRandomInstance()

Just a couple of comments this time. I originally reviewed v10
and this time I reviewed v10..v18.

src/hotspot/share/runtime/synchronizer.hpp line 126:

> 124: 
> 125:   static bool quick_notify(oopDesc* obj, JavaThread* current, bool All);
> 126: 

Why add the extra blank line?

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2239178344
PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717549253

From dcubed at openjdk.org  Wed Aug 14 21:08:00 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 14 Aug 2024 21:08:00 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
Message-ID: <hnh3EOQc8Bffe_OT0gXVr6oI8MYMRELpS-60UpYbL1o=.d7650a2f-c958-4540-800c-237a4a4f62f8@github.com>

On Tue, 13 Aug 2024 17:24:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the last OMWorld references
>>  - Rename omworldtable_work to object_monitor_table_work
>
> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
> 
>> 339: 
>> 340: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor_from_table(oop object, JavaThread* current, bool* inserted) {
>> 341:   assert(LockingMode == LM_LIGHTWEIGHT, "must be");
> 
> Do you want to assert: `inserted != nullptr`?

What was the resolution? I don't see a reply or a change here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717543005

From prappo at openjdk.org  Wed Aug 14 22:13:49 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Aug 2024 22:13:49 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos
In-Reply-To: <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>
Message-ID: <73YOEeZKhvhWh9BP7GHJ57K15BcsM-ARlXTgA7HvnMg=.00091e11-3c1a-4b13-bd14-098e28bf4df6@github.com>

On Wed, 14 Aug 2024 21:03:05 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

>> This PR fixes a few trivial grammar issues and typos in documentation.
>> 
>> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
>> 
>> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
>> 
>> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
>> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
>> 
>> @DougLea, thoughts?
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1075:
> 
>> 1073:     /**
>> 1074:      * Tries to join this task, returning true if it completed
>> 1075:      * (possibly exceptionally) before the given timeout elapses and
> 
> Seems like mixed tense now: do we want completes/elapses or completed/elapsed?

I admit I had doubts about the sequence of tenses too. That's a pretty complex sentence, and I'm a non-native English speaker. It's hard to re-tense it while retaining its conditional nature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1717605188

From duke at openjdk.org  Wed Aug 14 22:33:18 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 14 Aug 2024 22:33:18 GMT
Subject: RFR: 8338409: Use record to simplify code
Message-ID: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>

j.u.Formatter$FixedString can be refactored to simplify the code using Record

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

Commit messages:
 - Update src/java.base/share/classes/java/util/Formatter.java
 - use record to simplify code

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

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

From liach at openjdk.org  Wed Aug 14 22:33:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Aug 2024 22:33:18 GMT
Subject: RFR: 8338409: Use record to simplify code
In-Reply-To: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
References: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
Message-ID: <vcFvdzFbdbSX77cEDZfefcz9tjEtMmU48O28Rxxx70s=.e1e13416-0878-4057-9e23-8229a152f4a5@github.com>

On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> j.u.Formatter$FixedString can be refactored to simplify the code using Record

src/java.base/share/classes/java/util/Formatter.java line 3024:

> 3022:     }
> 3023: 
> 3024:     private static record FixedString(String s, int start, int end) implements FormatString {

Suggestion:

    private record FixedString(String s, int start, int end) implements FormatString {

Records are always implicitly static.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20443#discussion_r1702079768

From redestad at openjdk.org  Wed Aug 14 22:37:53 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 14 Aug 2024 22:37:53 GMT
Subject: RFR: 8338409: Use record to simplify code
In-Reply-To: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
References: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
Message-ID: <n0g4ae0pto0NXiE20mY11EwwSsTLJLH-4JJliCMw-wA=.0ea742c7-c6dd-4004-9196-c5611a8b10b0@github.com>

On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> j.u.Formatter$FixedString can be refactored to simplify the code using Record

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20443#pullrequestreview-2239308638

From liach at openjdk.org  Wed Aug 14 22:47:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Aug 2024 22:47:48 GMT
Subject: RFR: 8338409: Use record to simplify code
In-Reply-To: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
References: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
Message-ID: <P_X58AB9aA1cI9q-Vd2Dn87YIxTCte6-TNEm-HDrAbY=.28bb67ad-64f2-4740-aafa-7a6fac2e1994@github.com>

On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> j.u.Formatter$FixedString can be refactored to simplify the code using Record

A simple cleanup.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20443#pullrequestreview-2239320206

From jkarthikeyan at openjdk.org  Thu Aug 15 03:03:49 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Thu, 15 Aug 2024 03:03:49 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
 <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
Message-ID: <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>

On Mon, 12 Aug 2024 06:29:03 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> its usage in existing patch is limited to [type comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542)

Ah, that makes sense to me. I took a closer look and I think since the patch is creating a `VectorReinterpret` node after unsigned vector nodes, it might be able to avoid cases where the type might get filtered/joined, like with `PhiNode::Value`. That might lead to errors since `empty_type->filter(other_type) == TOP`. It's unfortunate that it's not really possible to disambiguate between an empty type and an unsigned range, which would allow us to solve this elegantly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1717820103

From dholmes at openjdk.org  Thu Aug 15 04:09:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 04:09:51 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos
In-Reply-To: <73YOEeZKhvhWh9BP7GHJ57K15BcsM-ARlXTgA7HvnMg=.00091e11-3c1a-4b13-bd14-098e28bf4df6@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>
 <73YOEeZKhvhWh9BP7GHJ57K15BcsM-ARlXTgA7HvnMg=.00091e11-3c1a-4b13-bd14-098e28bf4df6@github.com>
Message-ID: <twYvZkUghlCNBmuuXCadt-fpoVbs9PuhSpzKoXnssR8=.b6fd775d-19ee-46c1-b14a-4c419ca391bc@github.com>

On Wed, 14 Aug 2024 22:11:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1075:
>> 
>>> 1073:     /**
>>> 1074:      * Tries to join this task, returning true if it completed
>>> 1075:      * (possibly exceptionally) before the given timeout elapses and
>> 
>> Seems like mixed tense now: do we want completes/elapses or completed/elapsed?
>
> I admit I had doubts about the sequence of tenses too. That's a pretty complex sentence, and I'm a non-native English speaker. It's hard to re-tense it while retaining its conditional nature.

Use "elapsed" here to match "completed".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1717850485

From dholmes at openjdk.org  Thu Aug 15 04:14:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 04:14:48 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor
In-Reply-To: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
Message-ID: <vIhW8gfMv4REmUIwJP3Ub1Nc-N49adfPo0E1X3bmpqg=.8db1a0dc-d04c-44c9-a5a1-2c6337ee183a@github.com>

On Wed, 14 Aug 2024 20:53:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
> 
> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
> 
> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
> 
> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Changes requested by dholmes (Reviewer).

src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 93:

> 91:     private static long storeString(String s) {
> 92:         try {
> 93:             pinVirtualThread();

The pin should be outside the try so that the finally can only happen if pinning was succesful.

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

PR Review: https://git.openjdk.org/jdk/pull/20588#pullrequestreview-2239597266
PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1717852378

From aboldtch at openjdk.org  Thu Aug 15 06:01:02 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Aug 2024 06:01:02 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v15]
In-Reply-To: <hnh3EOQc8Bffe_OT0gXVr6oI8MYMRELpS-60UpYbL1o=.d7650a2f-c958-4540-800c-237a4a4f62f8@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <ODOzIp_wcNzCbBdqQ0SDGxhoDQO_f-0KxviEUQC7tq4=.caf04180-0ce2-4189-ba2f-a826c136b7b6@github.com>
 <1fb1K_XEPWOFdZohDLyQmgXhulJfSelL9Ib0fpkmVFI=.c3beb140-6cb1-43db-ae6c-547d997c554b@github.com>
 <hnh3EOQc8Bffe_OT0gXVr6oI8MYMRELpS-60UpYbL1o=.d7650a2f-c958-4540-800c-237a4a4f62f8@github.com>
Message-ID: <gL8ccYVulh3aCR_o5aloauDEOFogosc0t4DT_9FDYLk=.2c04fbe7-b560-4130-b9e8-d23dac273edd@github.com>

On Wed, 14 Aug 2024 20:58:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
>> 
>>> 339: 
>>> 340: ObjectMonitor* LightweightSynchronizer::get_or_insert_monitor_from_table(oop object, JavaThread* current, bool* inserted) {
>>> 341:   assert(LockingMode == LM_LIGHTWEIGHT, "must be");
>> 
>> Do you want to assert: `inserted != nullptr`?
>
> What was the resolution? I don't see a reply or a change here.

_Must have missed pressing Comment_

The assert does not seem necessary, this member function is local to LightweightSynchronizer (private) and it will crash hard if it is called with a bad pointer for the out parameter.

It could have been a reference type here instead. I am not sure what is the best when it comes to out parameters, all styles have pros and cons. We seem to use all different combinations throughout hotspot.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1717996898

From aboldtch at openjdk.org  Thu Aug 15 06:12:22 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Aug 2024 06:12:22 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v20]
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Remove newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20067/files
  - new: https://git.openjdk.org/jdk/pull/20067/files/4d67422f..e287445d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20067&range=18-19

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

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

From aboldtch at openjdk.org  Thu Aug 15 06:12:22 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Aug 2024 06:12:22 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v19]
In-Reply-To: <ri8r6ZteeyIQqs8MZL6FSv7v6JPK7ezVsn1RB1RCMY8=.3b249cbf-a41e-4764-b30d-0fc35a7598b5@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <4g1C6IMPhW60t2IygFaP6KBhaOtr0VEepPM2D6fWMPE=.91c3d202-a5e1-4669-9846-e89e6a360e91@github.com>
 <ri8r6ZteeyIQqs8MZL6FSv7v6JPK7ezVsn1RB1RCMY8=.3b249cbf-a41e-4764-b30d-0fc35a7598b5@github.com>
Message-ID: <MHst4O1XTUTHvBOBje3BCCO1H9X-KLrbg6wyRIK6Dho=.d3bdd9e8-2c3a-4018-9c26-bdd11cf20c79@github.com>

On Wed, 14 Aug 2024 21:02:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use jdk.test.lib.Utils.getRandomInstance()
>
> src/hotspot/share/runtime/synchronizer.hpp line 126:
> 
>> 124: 
>> 125:   static bool quick_notify(oopDesc* obj, JavaThread* current, bool All);
>> 126: 
> 
> Why add the extra blank line?

The `quick` grouping seemed inconsistent. Was probably thinking about moving down `quick_enter_legacy`. But in the end, there is no obvious grouping. The newline must have slipped through, I'll revert it. 
Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1718006715

From jbhateja at openjdk.org  Thu Aug 15 07:02:53 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 15 Aug 2024 07:02:53 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
 <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
 <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>
Message-ID: <QfgwwVXsYjjdGR65TfJJZjAXTS81OUyP-WOvWRRmfBk=.9e3ff6c8-201e-4b0e-93a2-9de753904279@github.com>

On Thu, 15 Aug 2024 03:01:00 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> @jaskarth , its usage in existing patch is limited to [type comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542). 
>> 
>> My plan is to address intrinsification of new core lib APIs, associated value range folding optimization (since unsigned numbers have different value range of [0, MAX_VALUE) vs signed [-MIN_VALUE/2, +MAX_VALUE/2) numbers) and auto-vectorization in a follow up patch.
>> 
>> **Notes on C2 type system:**  
>> Unlike Type::FLOAT, integral type ranges are specified using _lo and _hi value range, these ranges are pruned using flow functions associated with each operation IR.  Constraining the value ranges allows logic pruning, e.g.  in1[TypeInt]  & 0x7FFFFFFF  will chop off -ve values ranges from in1,  thus a constrol structure like . `if (in1 < 0) { true_path ; } else { false_path; } `  which uses in1 as a flow condition will sweepout the true path.
>> 
>> C2 type system only maintains value ranges for integral types i.e. long and int, any sub-word type which as per JVM specification has an int storage "word" only constrains the value range of TypeInt.  
>> 
>> A type which represent a constant value has same _hi and _lo value.
>> 
>> Floating point types Type::FLOAT / DOUBLE cannot maintain upper  / lower value ranges due to rounding constraints.
>> Thus C2 type system maintains a separate type TypeF and TypeD which are singletons and represent a constant value.
>
>> its usage in existing patch is limited to [type comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542)
> 
> Ah, that makes sense to me. I took a closer look and I think since the patch is creating a `VectorReinterpret` node after unsigned vector nodes, it might be able to avoid cases where the type might get filtered/joined, like with `PhiNode::Value`. That might lead to errors since `empty_type->filter(other_type) == TOP`. It's unfortunate that it's not really possible to disambiguate between an empty type and an unsigned range, which would allow us to solve this elegantly.

@jaskarth , Central idea behind introducing VectorReinterpretNode after unsigned vector IR is to facilitate unboxing-boxing optimization, this explicit reinterpretation ensures type compatibility between value being boxed and box type which is always signed vector types.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1718044262

From lbourges at openjdk.org  Thu Aug 15 07:52:03 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 15 Aug 2024 07:52:03 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: <yJJzVKuDrI2EjZgOMLpRP2dx5czPKGnlH5r2TDIk6xw=.5af93a7f-f7c5-41cd-8fa1-560f62f6746e@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)

Keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-2290835657

From prappo at openjdk.org  Thu Aug 15 08:28:24 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Aug 2024 08:28:24 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <twYvZkUghlCNBmuuXCadt-fpoVbs9PuhSpzKoXnssR8=.b6fd775d-19ee-46c1-b14a-4c419ca391bc@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>
 <73YOEeZKhvhWh9BP7GHJ57K15BcsM-ARlXTgA7HvnMg=.00091e11-3c1a-4b13-bd14-098e28bf4df6@github.com>
 <twYvZkUghlCNBmuuXCadt-fpoVbs9PuhSpzKoXnssR8=.b6fd775d-19ee-46c1-b14a-4c419ca391bc@github.com>
Message-ID: <U5ABJJBsur2vqB89ja7uuY00yHHhWesi9ru2UZsuhms=.3ce372a1-a75b-4727-9f3b-f497198eabe0@github.com>

On Thu, 15 Aug 2024 04:07:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I admit I had doubts about the sequence of tenses too. That's a pretty complex sentence, and I'm a non-native English speaker. It's hard to re-tense it while retaining its conditional nature.
>
> Use "elapsed" here to match "completed".

I assume you both mean I should change "elapses" to "elapsed" throughout the PR, not just in that particular occurrence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718114508

From prappo at openjdk.org  Thu Aug 15 08:28:24 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Aug 2024 08:28:24 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
Message-ID: <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>

> This PR fixes a few trivial grammar issues and typos in documentation.
> 
> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
> 
> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
> 
> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
> 
> @DougLea, thoughts?

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

  Fix grammatical tense

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20584/files
  - new: https://git.openjdk.org/jdk/pull/20584/files/0c692020..3c05ab33

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

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

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

From dholmes at openjdk.org  Thu Aug 15 09:02:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 09:02:51 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <U5ABJJBsur2vqB89ja7uuY00yHHhWesi9ru2UZsuhms=.3ce372a1-a75b-4727-9f3b-f497198eabe0@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>
 <73YOEeZKhvhWh9BP7GHJ57K15BcsM-ARlXTgA7HvnMg=.00091e11-3c1a-4b13-bd14-098e28bf4df6@github.com>
 <twYvZkUghlCNBmuuXCadt-fpoVbs9PuhSpzKoXnssR8=.b6fd775d-19ee-46c1-b14a-4c419ca391bc@github.com>
 <U5ABJJBsur2vqB89ja7uuY00yHHhWesi9ru2UZsuhms=.3ce372a1-a75b-4727-9f3b-f497198eabe0@github.com>
Message-ID: <4aVBFDMu70wN8kdJ7KVHXRcX44kzEdqESM9cC2ItaF4=.f05bfd28-3b7a-466a-967d-290b5b27a540@github.com>

On Thu, 15 Aug 2024 08:24:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Use "elapsed" here to match "completed".
>
> I assume you both mean I should change "elapses" to "elapsed" throughout the PR, not just in that particular occurrence.

No, elsewhere you don't have an existing tense to match - I only want the sentence to be self-consistent. The question of whether the docs overall should be expressed in past or future tense is a much bigger issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718155121

From dholmes at openjdk.org  Thu Aug 15 09:02:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 09:02:52 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <4aVBFDMu70wN8kdJ7KVHXRcX44kzEdqESM9cC2ItaF4=.f05bfd28-3b7a-466a-967d-290b5b27a540@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <maP5najD8mDQCTNLZ6GYLDXgjlZWcA77J937TvogFIk=.83dab853-12c9-4ed6-bee1-85aa6308e7ae@github.com>
 <73YOEeZKhvhWh9BP7GHJ57K15BcsM-ARlXTgA7HvnMg=.00091e11-3c1a-4b13-bd14-098e28bf4df6@github.com>
 <twYvZkUghlCNBmuuXCadt-fpoVbs9PuhSpzKoXnssR8=.b6fd775d-19ee-46c1-b14a-4c419ca391bc@github.com>
 <U5ABJJBsur2vqB89ja7uuY00yHHhWesi9ru2UZsuhms=.3ce372a1-a75b-4727-9f3b-f497198eabe0@github.com>
 <4aVBFDMu70wN8kdJ7KVHXRcX44kzEdqESM9cC2ItaF4=.f05bfd28-3b7a-466a-967d-290b5b27a540@github.com>
Message-ID: <tlNnnlE6y_-fJMsOFk_U1PxxPGqSMzIFFKh_YfhkUGA=.4ebedfb0-cee3-4eab-9679-90c93776b665@github.com>

On Thu, 15 Aug 2024 08:58:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I assume you both mean I should change "elapses" to "elapsed" throughout the PR, not just in that particular occurrence.
>
> No, elsewhere you don't have an existing tense to match - I only want the sentence to be self-consistent. The question of whether the docs overall should be expressed in past or future tense is a much bigger issue.

Oops I see the others do also have "completed" - my bad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718157359

From mgronlun at openjdk.org  Thu Aug 15 09:48:57 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 Aug 2024 09:48:57 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor
In-Reply-To: <vIhW8gfMv4REmUIwJP3Ub1Nc-N49adfPo0E1X3bmpqg=.8db1a0dc-d04c-44c9-a5a1-2c6337ee183a@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <vIhW8gfMv4REmUIwJP3Ub1Nc-N49adfPo0E1X3bmpqg=.8db1a0dc-d04c-44c9-a5a1-2c6337ee183a@github.com>
Message-ID: <QxDmVcYjo2R9IfoPH-i8p51lMXPJCBaKeB5dOMb_zFg=.de2094bd-f9df-4a77-b46a-edfa11bc12ca@github.com>

On Thu, 15 Aug 2024 04:11:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Greetings,
>> 
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
>> 
>> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
>> 
>> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
>> 
>> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 93:
> 
>> 91:     private static long storeString(String s) {
>> 92:         try {
>> 93:             pinVirtualThread();
> 
> The pin should be outside the try so that the finally can only happen if pinning was succesful.

Good point, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718199292

From alanb at openjdk.org  Thu Aug 15 09:48:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Aug 2024 09:48:57 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor
In-Reply-To: <QxDmVcYjo2R9IfoPH-i8p51lMXPJCBaKeB5dOMb_zFg=.de2094bd-f9df-4a77-b46a-edfa11bc12ca@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <vIhW8gfMv4REmUIwJP3Ub1Nc-N49adfPo0E1X3bmpqg=.8db1a0dc-d04c-44c9-a5a1-2c6337ee183a@github.com>
 <QxDmVcYjo2R9IfoPH-i8p51lMXPJCBaKeB5dOMb_zFg=.de2094bd-f9df-4a77-b46a-edfa11bc12ca@github.com>
Message-ID: <356ijNTheClKy5NxqnXtCInT3MIY6rLL88RxYbl8N5k=.cea3a7ad-1e71-4e5d-afdf-9cbbe7b59649@github.com>

On Thu, 15 Aug 2024 09:45:20 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 93:
>> 
>>> 91:     private static long storeString(String s) {
>>> 92:         try {
>>> 93:             pinVirtualThread();
>> 
>> The pin should be outside the try so that the finally can only happen if pinning was succesful.
>
> Good point, thanks.

Yes, it should only unpin if pin completed successfully.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718199915

From mgronlun at openjdk.org  Thu Aug 15 09:54:24 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 Aug 2024 09:54:24 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v2]
In-Reply-To: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
Message-ID: <fUl2ELaWGFU3mKMcW8YqDuqLw8Pzye6fRrbkyZU_yjA=.71286010-7fe7-4fdc-9900-760b9efae5e2@github.com>

> Greetings,
> 
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
> 
> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
> 
> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
> 
> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  hoist pinVirtualThread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20588/files
  - new: https://git.openjdk.org/jdk/pull/20588/files/6a63f340..b047b95c

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

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

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

From mgronlun at openjdk.org  Thu Aug 15 09:54:24 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 Aug 2024 09:54:24 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v2]
In-Reply-To: <356ijNTheClKy5NxqnXtCInT3MIY6rLL88RxYbl8N5k=.cea3a7ad-1e71-4e5d-afdf-9cbbe7b59649@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <vIhW8gfMv4REmUIwJP3Ub1Nc-N49adfPo0E1X3bmpqg=.8db1a0dc-d04c-44c9-a5a1-2c6337ee183a@github.com>
 <QxDmVcYjo2R9IfoPH-i8p51lMXPJCBaKeB5dOMb_zFg=.de2094bd-f9df-4a77-b46a-edfa11bc12ca@github.com>
 <356ijNTheClKy5NxqnXtCInT3MIY6rLL88RxYbl8N5k=.cea3a7ad-1e71-4e5d-afdf-9cbbe7b59649@github.com>
Message-ID: <Qbz-1UgPXeyk2LkxAATXGiqCOKQlzbSAUrP8J6ThyY0=.2320d55a-ea2e-4756-a9fe-c09e0bae4c84@github.com>

On Thu, 15 Aug 2024 09:46:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Good point, thanks.
>
> Yes, it should only unpin if pin completed successfully.

Please see updated changeset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718203932

From alanb at openjdk.org  Thu Aug 15 10:48:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Aug 2024 10:48:48 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v2]
In-Reply-To: <fUl2ELaWGFU3mKMcW8YqDuqLw8Pzye6fRrbkyZU_yjA=.71286010-7fe7-4fdc-9900-760b9efae5e2@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <fUl2ELaWGFU3mKMcW8YqDuqLw8Pzye6fRrbkyZU_yjA=.71286010-7fe7-4fdc-9900-760b9efae5e2@github.com>
Message-ID: <e9hvG5LWaqsf-TV10vVc4a_ntkONJ73Dqc6boekoWY0=.91eab8ae-eb8e-4427-b477-b62595eb311b@github.com>

On Thu, 15 Aug 2024 09:54:24 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
>> 
>> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
>> 
>> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
>> 
>> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hoist pinVirtualThread

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20588#pullrequestreview-2240145153

From mgronlun at openjdk.org  Thu Aug 15 11:20:23 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 15 Aug 2024 11:20:23 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v3]
In-Reply-To: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
Message-ID: <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>

> Greetings,
> 
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
> 
> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
> 
> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
> 
> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  update test comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20588/files
  - new: https://git.openjdk.org/jdk/pull/20588/files/b047b95c..b96b411f

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

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

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

From viktor.klang at oracle.com  Thu Aug 15 11:27:09 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 15 Aug 2024 11:27:09 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
Message-ID: <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Anthony,

Thanks for the input?it's much appreciated!

Introducing yet another, user-facing, type parameter to get slightly improved type inference is unfortunately for me a too high of a price to pay. Ideally, type inference/unification will be improved over time making this issue go away without impacting any signatures.

I'm warming up to the idea of shipping a Gatherers.identity(), and before that happens I would like to see more use-cases where having such a thing would provide a real edge. I can come up with a bunch of synthetic scenarios where it's a win, but it's always better to see app logic numbers.

Getting rid of the rawtypes in Value could be done, at any point since it isn't exposed to user code. I'll keep this in mind for any upcoming maintenance ?

Keep the feedback coming ?

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: Anthony Vanelverdinghe <dev at anthonyv.be>
Sent: Tuesday, 13 August 2024 18:32
To: Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback

Hi Viktor

Your previous response inspired me to experiment some more with Gatherers
As a result I'd like to make a couple propositions:

* add an additional type parameter.
  After doing so, type inference no longer needs any assistance:
  `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
* add an identity Gatherer with an optimized `andThen` implementation
  as well as an optimization in the default implementation of `Gatherer::andThen`
* eliminate the use of raw types in `Gatherers.Value`

Code that implements these propositions is in this gist: https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVct8oxUqg$

Kind regards,
Anthony

July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> Hi Anthony,
>
> >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
>
> `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
>
> Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
>
> >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
>
> Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
>
> >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
>
> Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVdv0LXetA$
>
> Cheers,
>
> ?
>
> **Viktor Klang**
> Software Architect, Java Platform Group
>
> Oracle
>
> ????????????????????????????????????????????????????????????????
>
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Tuesday, 30 July 2024 17:20
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
>
>
> July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
>
> >
>
> > Hi Anthony,
>
> Hi Viktor
>
> > Thank you for your patience, and for providing feedback, it is always much appreciated.
>
> >
>
> > >When writing factory methods for Gatherers, there's sometimes a
>
> > degenerate case that requires returning a no-op Gatherer. So I'd like a
>
> > way to mark a no-op Gatherer as such, allowing the Stream implementation
>
> > to recognize and eliminate it from the pipeline. One idea is to add
>
> > Gatherer.defaultIntegrator(), analogous to the other default? methods.
>
> > Another is to add Gatherers.identity(), analogous to Function.identity().
>
> >
>
> > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
>
> > but rather adding it in case it was deemed necessary.
>
> >
>
> > Do you have a concrete use-case (code) that you could share?
>
> The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
>
> `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
>
> > >Sometimes a factory method returns a Gatherer that only works correctly
>
> > if the upstream has certain characteristics, for example
>
> > Spliterator.SORTED or Spliterator.DISTINCT.
>
> >
>
> > Do you have a concrete use-case (code) that you could share?
>
> All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
>
> > >One idea is to add methods
>
> > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
>
> > implementation would be able to recognize and eliminate these from the
>
> > pipeline if the upstream already has these characteristics. That way
>
> > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
>
> > idea is to provide a Gatherer with a way to inspect the upstream
>
> > characteristics. If the upstream is missing the required
>
> > characteristic(s), it could then throw an IllegalStateException.
>
> I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
>
> > For a rather long time Gatherer had characteristics, however,
>
> > what I noticed is that given composition of Gatherers what ended up happening
>
> > almost always was that the combination of characteristics added overhead and devolved into the empty set
>
> > real fast.
>
> >
>
> > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
>
> > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
>
> In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
>
> That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
>
> > >The returns clause of Gatherer.Integrator::integrate just states "true
>
> > if subsequent integration is desired, false if not". In particular, it
>
> > doesn't document the behavior I'm observing, that returning false also
>
> > causes downstream to reject any further output elements.
>
> >
>
> > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
>
> I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$  ), but this is indeed already fixed in JDK 23-ea.
>
> This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
>
> > Cheers,
>
> >
>
> > ?
>
> >
>
> > **Viktor Klang**
>
> > Software Architect, Java Platform Group
>
> >
>
> > Oracle
>
> Kind regards,
>
> Anthony
>
> > ????????????????????????????????????????????????????????????????
>
> >
>
> > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
>
> > **Sent:** Saturday, 27 July 2024 08:57
>
> > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
>
> > **Subject:** Stream Gatherers (JEP 473) feedback
>
> >
>
> >
>
> > When writing factory methods for Gatherers, there's sometimes a
>
> >
>
> > degenerate case that requires returning a no-op Gatherer. So I'd like a
>
> >
>
> > way to mark a no-op Gatherer as such, allowing the Stream implementation
>
> >
>
> > to recognize and eliminate it from the pipeline. One idea is to add
>
> >
>
> > Gatherer.defaultIntegrator(), analogous to the other default? methods.
>
> >
>
> > Another is to add Gatherers.identity(), analogous to Function.identity().
>
> >
>
> > Sometimes a factory method returns a Gatherer that only works correctly
>
> >
>
> > if the upstream has certain characteristics, for example
>
> >
>
> > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
>
> >
>
> > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
>
> >
>
> > implementation would be able to recognize and eliminate these from the
>
> >
>
> > pipeline if the upstream already has these characteristics. That way
>
> >
>
> > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
>
> >
>
> > idea is to provide a Gatherer with a way to inspect the upstream
>
> >
>
> > characteristics. If the upstream is missing the required
>
> >
>
> > characteristic(s), it could then throw an IllegalStateException.
>
> >
>
> > The returns clause of Gatherer.Integrator::integrate just states "true
>
> >
>
> > if subsequent integration is desired, false if not". In particular, it
>
> >
>
> > doesn't document the behavior I'm observing, that returning false also
>
> >
>
> > causes downstream to reject any further output elements.
>
> >
>
> > In the Implementation Requirements section of Gatherer, rephrasing
>
> >
>
> > "Outputs and state later in the input sequence will be discarded if
>
> >
>
> > processing an earlier partition short-circuits." to something like the
>
> >
>
> > following would be clearer to me: "As soon as any partition
>
> >
>
> > short-circuits, the whole Gatherer short-circuits. The state of other
>
> >
>
> > partitions is discarded, i.e. there are no further invocations of the
>
> >
>
> > combiner. The finisher is invoked with the short-circuiting partition's
>
> >
>
> > state." I wouldn't mention discarding of outputs, since that's implied
>
> >
>
> > by the act of short-circuiting.
>
> >
>
> > Anthony
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240815/3973a5db/attachment-0001.htm>

From aboldtch at openjdk.org  Thu Aug 15 12:00:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Aug 2024 12:00:57 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v6]
In-Reply-To: <ZrdkZBka-bE3JWmIIozLSyuncmU2cAi8MB-sdZE0ue0=.f8f5c66a-da77-4bad-b8f4-842158312cb4@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <wRW8TABXS8LovbQ9qF8fosFD7FxYzpJdrG2LOvR6xDk=.19d62ec7-b2e4-41a1-8443-0480761288bf@github.com>
 <ZrdkZBka-bE3JWmIIozLSyuncmU2cAi8MB-sdZE0ue0=.f8f5c66a-da77-4bad-b8f4-842158312cb4@github.com>
Message-ID: <D1tIvbidAP7ju3gTT0iH17VFLgJ1Hvwm4YgGVnRbQkU=.774726f2-de20-4879-bf53-409ecd172bf2@github.com>

On Fri, 12 Jul 2024 10:12:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update arguments.cpp
>
> Is there a plan to get rid of the UseObjectMonitorTable flag in a future release? Ideally we would have one fast-locking implementation (LW locking) with one OM mapping (+UOMT), right?

@rkennke Is there any issue/blocker you want resolved before integrating?

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

PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2291141036

From dholmes at openjdk.org  Thu Aug 15 12:30:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 12:30:48 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v3]
In-Reply-To: <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>
Message-ID: <zAW8mAquOAoa1B9hs-tcOCiL20LMQU5Tl_mbT6yxB1E=.d5cf093c-871f-4838-b5a0-ee5ec737b166@github.com>

On Thu, 15 Aug 2024 11:20:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
>> 
>> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
>> 
>> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
>> 
>> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test comment

Functionally seems fine. Could be optimised a bit.

src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 86:

> 84: 
> 85:     private static void unpinVirtualThread() {
> 86:         if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) {

If you are at all concerned about overhead here then pin could return a boolean to indicate if the pin happened and oyu could then unpin just by checking that boolean and avoid doing the isVirtual and isSupported checks again.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20588#pullrequestreview-2240268782
PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718332618

From szaldana at openjdk.org  Thu Aug 15 13:30:52 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 15 Aug 2024 13:30:52 GMT
Subject: Integrated: 8338014: Improve usage of @jvms tags in class file API
In-Reply-To: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
References: <V4KYAZzWDBNRYpjCYxT3icdU15xcsjIwYwlHcpIgiCQ=.a16d46a6-ee69-47eb-a948-6b7341aaffd2@github.com>
Message-ID: <PiB3oKiEZObuMWGySYRcmFGVt8ZnhcNNLq0J4Zbr2TA=.80de1c91-7fe9-4ec6-9299-c4b5183595e1@github.com>

On Thu, 8 Aug 2024 18:15:29 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8338014](https://bugs.openjdk.org/browse/JDK-8338014) improving the use of `@jvms` tags by adding `JVMS` prior to the tag. 
> 
> Thanks, 
> Sonia

This pull request has now been integrated.

Changeset: 56dec215
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/56dec215b0d056fc23137372ecb3376af2a7b891
Stats:     76 lines in 40 files changed: 0 ins; 0 del; 76 mod

8338014: Improve usage of @jvms tags in class file API

Reviewed-by: darcy, liach, asotona

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

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

From duke at openjdk.org  Thu Aug 15 13:43:58 2024
From: duke at openjdk.org (duke)
Date: Thu, 15 Aug 2024 13:43:58 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <Pn1-SA1EbDwxs-omZOg0TF6ae234ZHo-ysAHAkoeT5I=.52ed0475-8697-471c-a3b6-00799711ec3b@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This PR implements the same algorithm as the current generateMHInlineCopy based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

@wenshao 
Your change (at version 7d481ece8e008c3ae55f29d27d10cb59e86212a1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2291288254

From yzheng at openjdk.org  Thu Aug 15 13:47:58 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 15 Aug 2024 13:47:58 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v20]
In-Reply-To: <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
Message-ID: <xWD2HgYXvYEnJojBFklAy4s7k0IbEjZcVgX1CaGbQ9M=.bfc705bf-2763-4db5-8f86-cf0b280bfcf1@github.com>

On Thu, 15 Aug 2024 06:12:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove newline

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 677:

> 675: 
> 676:       // Check for match.
> 677:       cmpptr(obj, Address(t));

`Address(t)` can be cached (in rax?) and reused in the subsequent `comptr`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1718426158

From egahlin at openjdk.org  Thu Aug 15 14:20:49 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 15 Aug 2024 14:20:49 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v3]
In-Reply-To: <zAW8mAquOAoa1B9hs-tcOCiL20LMQU5Tl_mbT6yxB1E=.d5cf093c-871f-4838-b5a0-ee5ec737b166@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>
 <zAW8mAquOAoa1B9hs-tcOCiL20LMQU5Tl_mbT6yxB1E=.d5cf093c-871f-4838-b5a0-ee5ec737b166@github.com>
Message-ID: <0INfIrm9TACgn075XGV2jWKju2Pfk5-yvbSOM3s_54Y=.43e8ef44-ef35-49ab-b2ba-38d023f7b465@github.com>

On Thu, 15 Aug 2024 12:26:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update test comment
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 86:
> 
>> 84: 
>> 85:     private static void unpinVirtualThread() {
>> 86:         if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) {
> 
> If you are at all concerned about overhead here then pin could return a boolean to indicate if the pin happened and oyu could then unpin just by checking that boolean and avoid doing the isVirtual and isSupported checks again.

Would it be possible to create a boolean in the EventWriter that indicates if it is associated with a carrier thread or a normal thread (which can never be virtual) and then have two methods.

    long l = this.carrierThread ? StringPool.addPinnedString(s) : StringPool.addString(s);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718464765

From alanb at openjdk.org  Thu Aug 15 14:34:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Aug 2024 14:34:48 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v3]
In-Reply-To: <0INfIrm9TACgn075XGV2jWKju2Pfk5-yvbSOM3s_54Y=.43e8ef44-ef35-49ab-b2ba-38d023f7b465@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>
 <zAW8mAquOAoa1B9hs-tcOCiL20LMQU5Tl_mbT6yxB1E=.d5cf093c-871f-4838-b5a0-ee5ec737b166@github.com>
 <0INfIrm9TACgn075XGV2jWKju2Pfk5-yvbSOM3s_54Y=.43e8ef44-ef35-49ab-b2ba-38d023f7b465@github.com>
Message-ID: <rZAAk5to5rc1xBmZONFr02MtB_Pq-VU8A5j8XywU-F0=.94a7d53f-df74-4f4c-afce-f00d516cd504@github.com>

On Thu, 15 Aug 2024 14:16:11 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/StringPool.java line 86:
>> 
>>> 84: 
>>> 85:     private static void unpinVirtualThread() {
>>> 86:         if (Thread.currentThread().isVirtual() && ContinuationSupport.isSupported()) {
>> 
>> If you are at all concerned about overhead here then pin could return a boolean to indicate if the pin happened and oyu could then unpin just by checking that boolean and avoid doing the isVirtual and isSupported checks again.
>
> Would it be possible to create a boolean in the EventWriter that indicates if it is associated with a carrier thread or a normal thread (which can never be virtual) and then have two methods.
> 
>     long l = this.carrierThread ? StringPool.addPinnedString(s) : StringPool.addString(s);

Thread.currentThread() has an intrinsic, and isVirtual is just a type check. ContinuationSupport.isSupported reads a static final so will disappear once compiled. The pattern we are using in other areas is for the pin to return a boolean (like David suggested).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1718489921

From aboldtch at openjdk.org  Thu Aug 15 14:34:58 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 15 Aug 2024 14:34:58 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v20]
In-Reply-To: <xWD2HgYXvYEnJojBFklAy4s7k0IbEjZcVgX1CaGbQ9M=.bfc705bf-2763-4db5-8f86-cf0b280bfcf1@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
 <xWD2HgYXvYEnJojBFklAy4s7k0IbEjZcVgX1CaGbQ9M=.bfc705bf-2763-4db5-8f86-cf0b280bfcf1@github.com>
Message-ID: <BJ7MD7uefTcfG1ZuEebJj3d8IR2fNTU7JLpVKjZQvLI=.1c7c96c3-c52c-432a-aa94-e5dbbd3631d6@github.com>

On Thu, 15 Aug 2024 13:45:11 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove newline
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 677:
> 
>> 675: 
>> 676:       // Check for match.
>> 677:       cmpptr(obj, Address(t));
> 
> `Address(t)` can be cached (in rax?) and reused in the subsequent `comptr`

It can. Just a quick test with `LockUnlock.testInflated` ?benchmarks shows a ~5% regression when using a mov of [T] into rax and then using rax for cmp. (On my current AMD machine). But worth pursuing in a more extensive followup. 

I'll note this in the followup RFEs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20067#discussion_r1718488820

From asotona at openjdk.org  Thu Aug 15 14:50:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Aug 2024 14:50:49 GMT
Subject: RFR: 8338406: BytecodeHelpers using wrong bootstrap method
 descriptor for condy
In-Reply-To: <U9Xicf-Myj2Hr0JYiiD6A9DuHroF4oYjZVRu8lZ8ys0=.3854987d-6d7e-4032-b04c-8ae4da3ca20b@github.com>
References: <U9Xicf-Myj2Hr0JYiiD6A9DuHroF4oYjZVRu8lZ8ys0=.3854987d-6d7e-4032-b04c-8ae4da3ca20b@github.com>
Message-ID: <duzGzoL5mZ_dDDINR0ynJiRhYuWIPCoAxbFxAi082gU=.6f6f1b17-3b95-4fb0-ace1-3c51a2b77df5@github.com>

On Wed, 14 Aug 2024 17:07:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> `BytecodeHelpers.handleConstantDescToHandleInfo` is incorrectly using `DirectMethodHandleDesc.invocationType`, which accidentally works for static bootstrap methods so it's discovered only now with more extensive testing from bytebuddy. Cleaned up by reusing the correct `handleDescToHandleInfo` instead. Thanks to @raphw for the report.
> 
> For now, a workaround can be instead of using `DynamicConstantDesc`, translate to `ConstantDynamicEntry` in user applications.

Looks good to me, thanks for the fix.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20586#pullrequestreview-2240563027

From aivanov at openjdk.org  Thu Aug 15 15:37:50 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 15 Aug 2024 15:37:50 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
Message-ID: <DdJ8LwxCTxovFaCoF-m45QOuhPC_YecWtX8ebBOFOxE=.daadcfdf-2510-44a6-9663-7a002b7392b2@github.com>

On Thu, 15 Aug 2024 08:28:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR fixes a few trivial grammar issues and typos in documentation.
>> 
>> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
>> 
>> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
>> 
>> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
>> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
>> 
>> @DougLea, thoughts?
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix grammatical tense

Marked as reviewed by aivanov (Reviewer).

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

> 856:      * usages of ForkJoinTasks ignore interrupt status when executing
> 857:      * or awaiting completion.  Otherwise, reporting task results or
> 858:      * exceptions is preferred to throwing InterruptedExceptions,

I wonder whether _?InterruptedExceptions?_ should be marked up with `{@code InterruptedException}`s to refer to the class. As far as I can see, classes and methods aren't marked up with `{@code}` here, so it's better to leave it as is.

src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1076:

> 1074:      * Tries to join this task, returning true if it completed
> 1075:      * (possibly exceptionally) before the given timeout elapsed and
> 1076:      * the current thread has not been interrupted.

Suggestion:

     * (possibly exceptionally) before the given timeout elapsed and if
     * the current thread has not been interrupted.

Would it be clearer with another _?if?_? I assume, the meaning is ??returning true if it completed ? and if the current thread has not been interrupted.?

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

PR Review: https://git.openjdk.org/jdk/pull/20584#pullrequestreview-2240653963
PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718569155
PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718579194

From prappo at openjdk.org  Thu Aug 15 15:44:51 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Aug 2024 15:44:51 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <DdJ8LwxCTxovFaCoF-m45QOuhPC_YecWtX8ebBOFOxE=.daadcfdf-2510-44a6-9663-7a002b7392b2@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
 <DdJ8LwxCTxovFaCoF-m45QOuhPC_YecWtX8ebBOFOxE=.daadcfdf-2510-44a6-9663-7a002b7392b2@github.com>
Message-ID: <XgAISX7uR74iB7OpD-8CZGTTE3BAq7Ke4I3WADqpXOw=.732dd8f7-2623-466b-bbde-d0cb427d8ade@github.com>

On Thu, 15 Aug 2024 15:29:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix grammatical tense
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 858:
> 
>> 856:      * usages of ForkJoinTasks ignore interrupt status when executing
>> 857:      * or awaiting completion.  Otherwise, reporting task results or
>> 858:      * exceptions is preferred to throwing InterruptedExceptions,
> 
> I wonder whether _?InterruptedExceptions?_ should be marked up with `{@code InterruptedException}`s to refer to the class. As far as I can see, classes and methods aren't marked up with `{@code}` here, so it's better to leave it as is.

That comment is not javadoc, so no need for markup. Although, I agree that this trailing "s" reads ugly because it interferes with the class name.

> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1076:
> 
>> 1074:      * Tries to join this task, returning true if it completed
>> 1075:      * (possibly exceptionally) before the given timeout elapsed and
>> 1076:      * the current thread has not been interrupted.
> 
> Suggestion:
> 
>      * (possibly exceptionally) before the given timeout elapsed and if
>      * the current thread has not been interrupted.
> 
> Would it be clearer with another _?if?_? I assume, the meaning is ??returning true if it completed ? and if the current thread has not been interrupted.?

I'd leave it to @DougLea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718586858
PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1718587545

From dhanalla at openjdk.org  Thu Aug 15 17:03:17 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 15 Aug 2024 17:03:17 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath
Message-ID: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>

Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.


The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:

1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
3. Some parts of the code are written in C others in C++.

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

Commit messages:
 - fix spaces
 - Use GetTempPath2 API instead of GetTempPath

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

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

From liach at openjdk.org  Thu Aug 15 17:52:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 Aug 2024 17:52:59 GMT
Subject: Integrated: 8338406: BytecodeHelpers using wrong bootstrap method
 descriptor for condy
In-Reply-To: <U9Xicf-Myj2Hr0JYiiD6A9DuHroF4oYjZVRu8lZ8ys0=.3854987d-6d7e-4032-b04c-8ae4da3ca20b@github.com>
References: <U9Xicf-Myj2Hr0JYiiD6A9DuHroF4oYjZVRu8lZ8ys0=.3854987d-6d7e-4032-b04c-8ae4da3ca20b@github.com>
Message-ID: <Mzi2zzG_nO0BCyggNzf2g1SceVBekPG0MzsLmHeEEe0=.bf4a069a-7eaf-40fd-97ce-0abfaea6ff5f@github.com>

On Wed, 14 Aug 2024 17:07:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> `BytecodeHelpers.handleConstantDescToHandleInfo` is incorrectly using `DirectMethodHandleDesc.invocationType`, which accidentally works for static bootstrap methods so it's discovered only now with more extensive testing from bytebuddy. Cleaned up by reusing the correct `handleDescToHandleInfo` instead. Thanks to @raphw for the report.
> 
> For now, a workaround can be instead of using `DynamicConstantDesc`, translate to `ConstantDynamicEntry` in user applications.

This pull request has now been integrated.

Changeset: ace49651
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ace496515f4f91e802a51cec43d387eed61bd935
Stats:     194 lines in 3 files changed: 105 ins; 87 del; 2 mod

8338406: BytecodeHelpers using wrong bootstrap method descriptor for condy

Reviewed-by: asotona

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

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

From rkennke at openjdk.org  Thu Aug 15 18:08:02 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Aug 2024 18:08:02 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v20]
In-Reply-To: <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
Message-ID: <ZR0jxeWAnJcQaTXZIgG-WNlvxZ9BQL8a1R8UQDfKa3U=.4e18b431-8526-4f89-b484-d66917e37318@github.com>

On Thu, 15 Aug 2024 06:12:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove newline

Looks good to me, thank you! Great work!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20067#pullrequestreview-2241022506

From cjplummer at openjdk.org  Thu Aug 15 18:37:49 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Aug 2024 18:37:49 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath
In-Reply-To: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
Message-ID: <tSiem9-jZPu7WXCp_-jkYkB7_fdWcJZ1rKq_vocz9zg=.09805d67-f316-4195-83fc-45519d27e071@github.com>

On Thu, 15 Aug 2024 16:23:18 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
> 
> 
> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
> 
> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
> 3. Some parts of the code are written in C others in C++.

src/hotspot/os/windows/os_windows.cpp line 1522:

> 1520: const char* os::get_temp_directory() {
> 1521:   static char path_buf[MAX_PATH];
> 1522:   if (_GetTempPath2A != nullptr) {

Where does _GetTempPath2A get initialized?

src/hotspot/os/windows/os_windows.cpp line 1525:

> 1523:     if (_GetTempPath2A(MAX_PATH, path_buf) > 0) {
> 1524:     return path_buf;
> 1525:     }

Need to indent line 1524.

src/hotspot/os/windows/os_windows.cpp line 1527:

> 1525:     }
> 1526:   }
> 1527:   else if (GetTempPath(MAX_PATH, path_buf) > 0) {

Suggestion:

  } else if (GetTempPath(MAX_PATH, path_buf) > 0) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1718830564
PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1718831669
PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1718832664

From redestad at openjdk.org  Thu Aug 15 20:10:01 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Aug 2024 20:10:01 GMT
Subject: RFR: 8333793: Improve BootstrapMethodInvoker for
 ConstantBootstraps and ProxyGenerator [v3]
In-Reply-To: <QF6We-mvzM73X-Ib_LENQe_lqACvlaOCXrg-IDpmAn0=.e0331e4c-06ce-4f14-be66-332020f4053c@github.com>
References: <aFNm1JtFl8CLsvHp2FnRs7smayOcwvpQXFQ-z3Jm2ss=.dfc0b236-581d-459a-b2b5-cbc97cfde70a@github.com>
 <QF6We-mvzM73X-Ib_LENQe_lqACvlaOCXrg-IDpmAn0=.e0331e4c-06ce-4f14-be66-332020f4053c@github.com>
Message-ID: <F382gL7Og0m6zCWCWWMcKzARNo6p7i5TVHRRIQFs6d0=.fd820072-deae-407d-b746-4343aacfdd24@github.com>

On Mon, 10 Jun 2024 10:09:38 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:
> 
>   Copy-paste error; CONDY_INVOKE returns Object. Fixes TestDynamicConstant.java

Since [JDK-8332457](https://bugs.openjdk.org/browse/JDK-8332457) was more or less backed out there's no obvious gain from parts of this patch. I'd like to rework it and add startup tests that verify the ConstantBootstraps. Closing for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/19598#issuecomment-2292126179

From redestad at openjdk.org  Thu Aug 15 20:10:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 15 Aug 2024 20:10:02 GMT
Subject: Withdrawn: 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: <vSMm47wJ1XmP9LvCQLwmbxlxY_7t7km2nsgF9Wr_A6A=.ccc529f9-9fd1-4cea-9b68-aae2f704ea86@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

This pull request has been closed without being integrated.

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

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

From dhanalla at openjdk.org  Thu Aug 15 20:28:28 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 15 Aug 2024 20:28:28 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
Message-ID: <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>

> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
> 
> 
> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
> 
> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
> 3. Some parts of the code are written in C others in C++.

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

  fix missing code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20600/files
  - new: https://git.openjdk.org/jdk/pull/20600/files/6969e669..32fce98e

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

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

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

From duke at openjdk.org  Thu Aug 15 21:15:02 2024
From: duke at openjdk.org (Myp)
Date: Thu, 15 Aug 2024 21:15:02 GMT
Subject: RFR: 8338242: RoundingMode.HALF_UP gives different results with
 NumberFormat
Message-ID: <Kjxluy_pwph_tlhSr0fy8Hq2B29GlK55BWO4nvcxw6w=.c385d8ac-09ed-4409-835d-80fb7934c299@github.com>

Fix of problem RoundingMode.HALF_UP gives different results with NumberFormat

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

Commit messages:
 - 8338242: RoundingMode.HALF_UP gives different results with NumberFormat

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

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

From dhanalla at openjdk.org  Thu Aug 15 22:08:50 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 15 Aug 2024 22:08:50 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <tSiem9-jZPu7WXCp_-jkYkB7_fdWcJZ1rKq_vocz9zg=.09805d67-f316-4195-83fc-45519d27e071@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <tSiem9-jZPu7WXCp_-jkYkB7_fdWcJZ1rKq_vocz9zg=.09805d67-f316-4195-83fc-45519d27e071@github.com>
Message-ID: <6LGN5xTLdIbedU4dkz-gfZnc8F2-eDg8zicm_DlYhFg=.3eeb23dd-172c-49b4-991b-75b99c0b01da@github.com>

On Thu, 15 Aug 2024 18:32:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix missing code
>
> src/hotspot/os/windows/os_windows.cpp line 1522:
> 
>> 1520: const char* os::get_temp_directory() {
>> 1521:   static char path_buf[MAX_PATH];
>> 1522:   if (_GetTempPath2A != nullptr) {
> 
> Where does _GetTempPath2A get initialized?

Thanks @plummercj for reviewing this PR. Fixed the missing initialization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1719058178

From cjplummer at openjdk.org  Thu Aug 15 22:14:49 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Aug 2024 22:14:49 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <6LGN5xTLdIbedU4dkz-gfZnc8F2-eDg8zicm_DlYhFg=.3eeb23dd-172c-49b4-991b-75b99c0b01da@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <tSiem9-jZPu7WXCp_-jkYkB7_fdWcJZ1rKq_vocz9zg=.09805d67-f316-4195-83fc-45519d27e071@github.com>
 <6LGN5xTLdIbedU4dkz-gfZnc8F2-eDg8zicm_DlYhFg=.3eeb23dd-172c-49b4-991b-75b99c0b01da@github.com>
Message-ID: <lTRNQDqBOtSVcA8OfWb3ERGUS2OhKxzA3SAo-ZbrpsY=.3bdf7001-96c6-41ea-88c0-0a3ce077ef86@github.com>

On Thu, 15 Aug 2024 22:06:14 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 1522:
>> 
>>> 1520: const char* os::get_temp_directory() {
>>> 1521:   static char path_buf[MAX_PATH];
>>> 1522:   if (_GetTempPath2A != nullptr) {
>> 
>> Where does _GetTempPath2A get initialized?
>
> Thanks @plummercj for reviewing this PR. Fixed the missing initialization.

FYI I'm not familiar with these Windows APIs, so I probably won't give this review approval myself. I only took a look because there was an svc file involved (AttachProviderImpl.c). Hopefully others with a better understanding of the changes will provide reviews.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1719063072

From naoto at openjdk.org  Thu Aug 15 22:28:49 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 Aug 2024 22:28:49 GMT
Subject: RFR: 8338242: RoundingMode.HALF_UP gives different results with
 NumberFormat
In-Reply-To: <Kjxluy_pwph_tlhSr0fy8Hq2B29GlK55BWO4nvcxw6w=.c385d8ac-09ed-4409-835d-80fb7934c299@github.com>
References: <Kjxluy_pwph_tlhSr0fy8Hq2B29GlK55BWO4nvcxw6w=.c385d8ac-09ed-4409-835d-80fb7934c299@github.com>
Message-ID: <q85RIkllfCYYsLY9U_MjdProjAMKL0DgBRmswvAxVVQ=.5fe3cb9c-c7b8-4489-8d59-9e0859465767@github.com>

On Wed, 14 Aug 2024 11:46:31 GMT, Myp <duke at openjdk.org> wrote:

> Fix of problem RoundingMode.HALF_UP gives different results with NumberFormat

It may look counterintuitive, but the existing behavior is the expected one. Please see the comment I added in the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/20580#issuecomment-2292396454

From duke at openjdk.org  Thu Aug 15 22:59:51 2024
From: duke at openjdk.org (duke)
Date: Thu, 15 Aug 2024 22:59:51 GMT
Subject: RFR: 8338409: Use record to simplify code
In-Reply-To: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
References: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
Message-ID: <Cpx8EfqdKzjkgvXWiYLPkRuUi97Wzs6QrjmM4zw91q4=.d0595c0e-c9b5-424e-b9d0-319c61e70157@github.com>

On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> j.u.Formatter$FixedString can be refactored to simplify the code using Record

@wenshao 
Your change (at version c7ce3c724183ad3b4a09a95555fac1d7411fdd8e) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20443#issuecomment-2292421421

From duke at openjdk.org  Thu Aug 15 22:59:51 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Thu, 15 Aug 2024 22:59:51 GMT
Subject: Integrated: 8338409: Use record to simplify code
In-Reply-To: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
References: <7084vGdpZn4ldqhTpoU87mCJ6KhyOvXq9sSwsxaPHtA=.18663e1b-2b25-4a5d-ae0d-2d7ea9752efb@github.com>
Message-ID: <ruD1A9WPKF7h0f53wy0ofTtYo09O6WTJeRwpbaresW8=.d6b47fc2-61de-431a-9f02-811c9e179d8c@github.com>

On Fri, 2 Aug 2024 16:14:41 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> j.u.Formatter$FixedString can be refactored to simplify the code using Record

This pull request has now been integrated.

Changeset: 74066bcc
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74066bcca82749722e6fee57469520d418bf3430
Stats:     9 lines in 1 file changed: 0 ins; 8 del; 1 mod

8338409: Use record to simplify code

Reviewed-by: redestad, liach

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

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

From darcy at openjdk.org  Fri Aug 16 03:30:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 16 Aug 2024 03:30:49 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
Message-ID: <MvL8iMzp_fXIy9_gc_3xBF58bgdZJRfRtFZpmaoX4EU=.5134e96b-e52e-4f57-87e2-c333fe6a99b0@github.com>

On Tue, 13 Aug 2024 23:41:06 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> When a type uses a type variable without a declaration, no exception is thrown. This change triggers a `TypeNotFoundException` to be thrown.
>
> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337302: Fix copyright years.

test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 43:

> 41: public class TestMissingTypeVariable {
> 42: 
> 43:     public static void main(String[] args) throws Exception {

To make the test more understandable to casual readers, I suggest putting the corresponding source code, as much as possible, as a comment.

test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 52:

> 50:                     classBuilder.withField("f",
> 51:                             ClassDesc.of("java.lang.Object"),
> 52:                             fieldBuilder -> fieldBuilder.withFlags(AccessFlag.PUBLIC).with(SignatureAttribute.of(Signature.parseFrom("TA;"))));

If the signature is incorrect, please leave a comment describing how it is incorrect. "// Type A is non-existent" etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1719247725
PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1719248512

From liach at openjdk.org  Fri Aug 16 04:48:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 04:48:50 GMT
Subject: RFR: 8337302: Undefined type variable results in null [v4]
In-Reply-To: <MvL8iMzp_fXIy9_gc_3xBF58bgdZJRfRtFZpmaoX4EU=.5134e96b-e52e-4f57-87e2-c333fe6a99b0@github.com>
References: <PSZCRXUrF3PhA5cdD09bmAGSuyaTzB-dr2ceiclGLY8=.82295333-f737-419b-97e0-37608d36c41f@github.com>
 <XETC31Em1pZTXNpJghRN326_gLRfs-dIzQQsaV8ESPw=.49d1f520-1bcd-41d3-8ea7-e081add5526e@github.com>
 <MvL8iMzp_fXIy9_gc_3xBF58bgdZJRfRtFZpmaoX4EU=.5134e96b-e52e-4f57-87e2-c333fe6a99b0@github.com>
Message-ID: <bxnN1OfVCtIen4iUXaiCzyFxOjiGp92d1OlpNzIRVO4=.8633b068-9b82-42c4-a4b1-3ce17d3996a4@github.com>

On Fri, 16 Aug 2024 03:27:27 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Rafael Winterhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337302: Fix copyright years.
>
> test/jdk/java/lang/reflect/Generics/TestMissingTypeVariable.java line 43:
> 
>> 41: public class TestMissingTypeVariable {
>> 42: 
>> 43:     public static void main(String[] args) throws Exception {
> 
> To make the test more understandable to casual readers, I suggest putting the corresponding source code, as much as possible, as a comment.

An alternative approach could be to write a package-private or nested class in the same file:

static class Generic<T> {
    T field;
}

// ...

var cf = ClassFile.of();
var generic = cf.parse(Path.of(System.getProperty("test.classes"), "TestMissingTypeVariable$Generic.class"));
var result = cf.transformClass(generic, ClassTransform.dropping(ce -> ce instanceof SignatureAttribute);
var missing = ByteCodeLoader.load("TestMissingTypeVariable$Generic", result);
// proceed


Would be more straightforward to readers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20535#discussion_r1719294839

From aboldtch at openjdk.org  Fri Aug 16 06:23:01 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Aug 2024 06:23:01 GMT
Subject: RFR: 8315884: New Object to ObjectMonitor mapping [v20]
In-Reply-To: <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
 <hFEHBMxfqGlJMijx55dvtW9-6Z-I1yhg5an5ufky3AA=.b0404eac-4da5-408f-8f7d-b26f90dd566b@github.com>
Message-ID: <HVg3N-Xqu4nmUx9iE7vkEqYrGs-Hyc061IKBOxYt24M=.46041aa5-d6bd-486e-9d09-e8ea872ce4ad@github.com>

On Thu, 15 Aug 2024 06:12:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
>> 
>> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
>> 
>> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
>> 
>> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
>> 
>> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
>> 
>> # Cleanups
>> 
>> Cleaned up displaced header usage for:
>>   * BasicLock
>>     * Contains some Zero changes
>>     * Renames one exported JVMCI field
>>   * ObjectMonitor
>>     * Updates comments and tests consistencies
>> 
>> # Refactoring
>> 
>> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
>> 
>> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
>> 
>> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
>> 
>> # LightweightSynchronizer
>> 
>> Working on adapting and incorporating the following section as a comment in the source code
>> 
>> ## Fast Locking
>> 
>>   CAS on locking bits in markWord. 
>>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
>> 
>>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
>> 
>>   If 0b10 (Inflated) is observed or there is to...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove newline

Thanks for all the reviews and contributions.

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

PR Comment: https://git.openjdk.org/jdk/pull/20067#issuecomment-2292891722

From aboldtch at openjdk.org  Fri Aug 16 06:23:04 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Aug 2024 06:23:04 GMT
Subject: Integrated: 8315884: New Object to ObjectMonitor mapping
In-Reply-To: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
References: <kDoJ_F8U3ie4XyLwRlIbwqaH2jyVUt61fMs8fsFDpA8=.23d22903-a08b-4f7d-a3e5-d65a98a1b6e0@github.com>
Message-ID: <xLiznLsD8ma9zuw05c8DhOb6kXNygqkMjH6cL0eGda0=.65067a12-329e-45b0-a080-f10a189bdd54@github.com>

On Mon, 8 Jul 2024 08:18:42 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> When inflating a monitor the `ObjectMonitor*` is written directly over the `markWord` and any overwritten data is displaced into a displaced `markWord`. This is problematic for concurrent GCs which needs extra care or looser semantics to use this displaced data. In Lilliput this data also contains the klass forcing this to be something that the GC has to take into account everywhere.
> 
> This patch introduces an alternative solution where locking only uses the lock bits of the `markWord` and inflation does not override and displace the `markWord`. This is done by keeping associations between objects and `ObjectMonitor*` in an external hash table. Different caching techniques are used to speedup lookups from compiled code.
> 
> A diagnostic VM option is introduced called `UseObjectMonitorTable`. It is only supported in combination with the LM_LIGHTWEIGHT locking mode (the default). 
> 
> This patch has been evaluated to be performance neutral when `UseObjectMonitorTable` is turned off (the default). 
> 
> Below is a more detailed explanation of this change and how `LM_LIGHTWEIGHT` and `UseObjectMonitorTable` works.
> 
> # Cleanups
> 
> Cleaned up displaced header usage for:
>   * BasicLock
>     * Contains some Zero changes
>     * Renames one exported JVMCI field
>   * ObjectMonitor
>     * Updates comments and tests consistencies
> 
> # Refactoring
> 
> `ObjectMonitor::enter` has been refactored an a `ObjectMonitorContentionMark` witness object has been introduced to the signatures. Which signals that the contentions reference counter is being held. More details are given below in the section about deflation.
> 
> The initial purpose of this was to allow `UseObjectMonitorTable` to interact more seamlessly with the `ObjectMonitor::enter` code. 
> 
> _There is even more `ObjectMonitor` refactoring which can be done here to create a more understandable and enforceable API. There are a handful of invariants / assumptions which are not always explicitly asserted which could be trivially abstracted and verified by the type system by using similar witness objects._
> 
> # LightweightSynchronizer
> 
> Working on adapting and incorporating the following section as a comment in the source code
> 
> ## Fast Locking
> 
>   CAS on locking bits in markWord. 
>   0b00 (Fast Locked) <--> 0b01 (Unlocked)
> 
>   When locking and 0b00 (Fast Locked) is observed, it may be beneficial to avoid inflating by spinning a bit.
> 
>   If 0b10 (Inflated) is observed or there is to much contention or to long critical sections for spinning to be feasible, inf...

This pull request has now been integrated.

Changeset: bd4160ce
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd4160cea8b6b0fcf0507199ed76a12f5d0aaba9
Stats:     3612 lines in 68 files changed: 2691 ins; 318 del; 603 mod

8315884: New Object to ObjectMonitor mapping

Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Reviewed-by: rkennke, coleenp, dcubed

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

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

From aturbanov at openjdk.org  Fri Aug 16 08:51:56 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 16 Aug 2024 08:51:56 GMT
Subject: Integrated: 8337839: Make a few fields in MergeCollation static
In-Reply-To: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>
References: <bIRJcYo1NDcZz25l9lFZEK8y9EYuQF4SOo7amjIssWU=.64ede33e-8099-4254-b597-f639b791d883@github.com>
Message-ID: <-uqGgqWVziPxiiM7q34DCuIMQjWOiMgcKNr-Pgnfxo8=.c536a1b0-dec1-4be1-a160-2abcc1ec1448@github.com>

On Thu, 25 Jul 2024 08:59:17 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in java.text.MergeCollation could be made 'static':
> 1. BITARRAYMASK
> 2. BYTEPOWER
> 3. BYTEMASK

This pull request has now been integrated.

Changeset: 60c9b5cd
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60c9b5cd9f18830f0fb1aea6cb3dc43af3908cc5
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8337839: Make a few fields in MergeCollation static

Reviewed-by: jpai, naoto

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

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

From jkratochvil at openjdk.org  Fri Aug 16 10:47:54 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 16 Aug 2024 10:47:54 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v20]
In-Reply-To: <Ikvesf5FPkQc0ZD4A3yfb7pKekPzA539BoxXq5TNgQY=.f74eb83d-6763-4eed-bb07-b128f969b91a@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <armE1TJT6euiIdqBUr7syBd5IAuArt4sTywLVp0CSgU=.4d85d1c0-d07a-4d3f-b2ed-6d871d1ec731@github.com>
 <Ikvesf5FPkQc0ZD4A3yfb7pKekPzA539BoxXq5TNgQY=.f74eb83d-6763-4eed-bb07-b128f969b91a@github.com>
Message-ID: <Gs1bsoRH0Bk2FmVMupfrAohfU0BDvqsC6ZQouvqmXlk=.adcb96cb-1f5f-440b-aca1-ebcdb47e07b6@github.com>

On Wed, 14 Aug 2024 14:56:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Testcase update upon review by Severin Gehwolf
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 109:
> 
>> 107: 
>> 108:             // Alpine Linux 3.20.1 needs cgcreate1 otherwise:
>> 109:             // cgcreate: can't create cgroup [...]: No such file or directory
> 
> Suggestion:
> 
>             // Create the parent cgroup hierarchy

_"Create the parent cgroup hierarchy"_ would be commenting an obvious thing so such comment is best to rather remove. The problem my comment is trying to describe is that on normal (tested Fedora) systems it is OK to do only:

cgcreate -g memory:a/b

On Alpine Linux it does not work (I did not investigate why). On Alpine Linux one has to do:

cgcreate -g memory:a
cgcreate -g memory:a/b

Developers probably will not use Alpine Linux so they may delete the first line

cgcreate -g memory:a

as it looks redundant. But it will break Alpine Linux.

Suggestion:

            // Alpine Linux 3.20.1 needs cgcreate1 as while regular Linuxes are fine with:
            //   cgcreate -g memory:a/b
            // Alpine Linux 3.20.1 needs both commands:
            //   cgcreate -g memory:a
            //   cgcreate -g memory:a/b
            // With only the second line Alpine Linux 3.20.1 would error with:
            //   cgcreate: can't create cgroup [...]: No such file or directory

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1719681365

From dl at openjdk.org  Fri Aug 16 12:14:50 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 16 Aug 2024 12:14:50 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <XgAISX7uR74iB7OpD-8CZGTTE3BAq7Ke4I3WADqpXOw=.732dd8f7-2623-466b-bbde-d0cb427d8ade@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
 <DdJ8LwxCTxovFaCoF-m45QOuhPC_YecWtX8ebBOFOxE=.daadcfdf-2510-44a6-9663-7a002b7392b2@github.com>
 <XgAISX7uR74iB7OpD-8CZGTTE3BAq7Ke4I3WADqpXOw=.732dd8f7-2623-466b-bbde-d0cb427d8ade@github.com>
Message-ID: <D3RZfhFhD9TDFOHHAl81QRiNGhegCPT7ssAc289S72Q=.5a851728-6680-4bc1-b843-41653cbd2b18@github.com>

On Thu, 15 Aug 2024 15:41:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 858:
>> 
>>> 856:      * usages of ForkJoinTasks ignore interrupt status when executing
>>> 857:      * or awaiting completion.  Otherwise, reporting task results or
>>> 858:      * exceptions is preferred to throwing InterruptedExceptions,
>> 
>> I wonder whether _?InterruptedExceptions?_ should be marked up with `{@code InterruptedException}`s to refer to the class. As far as I can see, classes and methods aren't marked up with `{@code}` here, so it's better to leave it as is.
>
> That comment is not javadoc, so no need for markup. Although, I agree that this trailing "s" reads ugly because it interferes with the class name.

It would also be OK to just drop that "s" -> InterruptedException.

>> src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 1076:
>> 
>>> 1074:      * Tries to join this task, returning true if it completed
>>> 1075:      * (possibly exceptionally) before the given timeout elapsed and
>>> 1076:      * the current thread has not been interrupted.
>> 
>> Suggestion:
>> 
>>      * (possibly exceptionally) before the given timeout elapsed and if
>>      * the current thread has not been interrupted.
>> 
>> Would it be clearer with another _?if?_? I assume, the meaning is ??returning true if it completed ? and if the current thread has not been interrupted.?
>
> I'd leave it to @DougLea.

The extra "if" doesn't seem to add clarity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1719761582
PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1719762896

From dl at openjdk.org  Fri Aug 16 12:18:53 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 16 Aug 2024 12:18:53 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
Message-ID: <Kdb3DENuyeR4s5KPiYEBLmZcc7jsPUJLtPf5m4NSb0A=.5e6b2593-2b6a-45a7-a715-7cbcfa7e30d0@github.com>

On Thu, 15 Aug 2024 08:28:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR fixes a few trivial grammar issues and typos in documentation.
>> 
>> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
>> 
>> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
>> 
>> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
>> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
>> 
>> @DougLea, thoughts?
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix grammatical tense

The overall inconsistency addressed here is that sometime "timeout" refers to a duration, and sometimes an event. Which is pretty common, but reworking docs to only mean duration seems reasonable.

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

PR Comment: https://git.openjdk.org/jdk/pull/20584#issuecomment-2293401618

From prappo at openjdk.org  Fri Aug 16 12:33:50 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 16 Aug 2024 12:33:50 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <Kdb3DENuyeR4s5KPiYEBLmZcc7jsPUJLtPf5m4NSb0A=.5e6b2593-2b6a-45a7-a715-7cbcfa7e30d0@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
 <Kdb3DENuyeR4s5KPiYEBLmZcc7jsPUJLtPf5m4NSb0A=.5e6b2593-2b6a-45a7-a715-7cbcfa7e30d0@github.com>
Message-ID: <9wvS4rn_wbqGL78cTlZteVQQZsoHSjw9_WJGC0suUH8=.0c4876d3-01f7-45dc-aa53-542c7d292352@github.com>

On Fri, 16 Aug 2024 12:15:47 GMT, Doug Lea <dl at openjdk.org> wrote:

> The overall inconsistency addressed here is that sometime "timeout" refers to a duration, and sometimes an event. Which is pretty common, but reworking docs to only mean duration seems reasonable.

Am I correct reading your comment as an effective approval of this PR in its current state?

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

PR Comment: https://git.openjdk.org/jdk/pull/20584#issuecomment-2293425606

From dl at openjdk.org  Fri Aug 16 12:37:48 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 16 Aug 2024 12:37:48 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
Message-ID: <oC_OMRgTzLPcXfjt1YzF_qYMlCABnDo2lYVT7K_Lwbk=.e4112e0e-6486-4714-bd61-07d8b7709f8a@github.com>

On Thu, 15 Aug 2024 08:28:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This PR fixes a few trivial grammar issues and typos in documentation.
>> 
>> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
>> 
>> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
>> 
>> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
>> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
>> 
>> @DougLea, thoughts?
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix grammatical tense

Yes :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/20584#issuecomment-2293432029

From prappo at openjdk.org  Fri Aug 16 12:53:48 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 16 Aug 2024 12:53:48 GMT
Subject: RFR: 8338398: Trivially fix grammar and typos [v2]
In-Reply-To: <D3RZfhFhD9TDFOHHAl81QRiNGhegCPT7ssAc289S72Q=.5a851728-6680-4bc1-b843-41653cbd2b18@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
 <UhQ_mqzp5gk1Dah6s_dmbXmuwU1qxwjaBqoBLZ9KWhA=.1ae5efd4-7de4-4cc3-b7cf-c0ad4a99caeb@github.com>
 <DdJ8LwxCTxovFaCoF-m45QOuhPC_YecWtX8ebBOFOxE=.daadcfdf-2510-44a6-9663-7a002b7392b2@github.com>
 <XgAISX7uR74iB7OpD-8CZGTTE3BAq7Ke4I3WADqpXOw=.732dd8f7-2623-466b-bbde-d0cb427d8ade@github.com>
 <D3RZfhFhD9TDFOHHAl81QRiNGhegCPT7ssAc289S72Q=.5a851728-6680-4bc1-b843-41653cbd2b18@github.com>
Message-ID: <LeFTD_6JZTSTabqFQHXapKdpnLMJ-miNs3MlnLUlyxo=.85ded601-3a81-49cb-ba0b-bd38cd83814b@github.com>

On Fri, 16 Aug 2024 12:10:32 GMT, Doug Lea <dl at openjdk.org> wrote:

> It would also be OK to just drop that "s" -> InterruptedException.

True, but there are other similar cases in that same file, maybe it's okay to leave it like that. Similar cases: ForkJoinTasks, Futures, CountedCompleters, InterruptibleTasks, WorkQueues, Deques, Workers, ForkJoinPools, SecurityManagers, ThreadLocals, VirtualThreads, ForkJoinWorkerThreads, VarHandles (this one actually clashes with the existing class).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20584#discussion_r1719800990

From liach at openjdk.org  Fri Aug 16 13:23:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 13:23:02 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <sjULxpRxHhCzzesqrCxsp-okCahbdGYlJHlYlxCXw8A=.69dcbb19-abb7-4d42-a62b-1e699b6274ce@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current strategy for bootstrapping JEP 280 String concat expressions uses either an optimized MH expression tree, or, due to scalability issues with that implementation, a per call-site StringBuilder-based class generation scheme.
>> 
>> This RFE seeks to unify these into a single strategy that uses per-shape class generation emitting code semantically similar to the optimized MH expression tree. Using hidden classes installed into java.lang with access to the StringConcatHelper set of utility methods this can achieve similar throughput performance, while reducing the number of generated classes at high arities, reducing startup overheads, and improving warmup characteristics.
>> 
>> This RFE was initially prompted by a suggestion of @cl4es in the discussion of PR #20253 (https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866), and then evolved after collaborating on this issue into this full re-implementation.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

Should we add a release note for this huge feature?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2293493871

From redestad at openjdk.org  Fri Aug 16 13:23:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 16 Aug 2024 13:23:02 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <sjULxpRxHhCzzesqrCxsp-okCahbdGYlJHlYlxCXw8A=.69dcbb19-abb7-4d42-a62b-1e699b6274ce@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
 <sjULxpRxHhCzzesqrCxsp-okCahbdGYlJHlYlxCXw8A=.69dcbb19-abb7-4d42-a62b-1e699b6274ce@github.com>
Message-ID: <WC19g8V86N4ADzDxVbAeKyxhytN9aPd8jVUpQaPThfg=.fab4acd5-bc18-4b30-a763-7f9a158c7015@github.com>

On Fri, 16 Aug 2024 13:17:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> Should we add a release note for this huge feature?

I think it would be reasonable to add something, yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2293498875

From duke at openjdk.org  Fri Aug 16 13:23:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 16 Aug 2024 13:23:03 GMT
Subject: Integrated: 8336856: Efficient hidden class-based string concatenation
 strategy
In-Reply-To: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
Message-ID: <QDbt590wtmy4AT-plD_RMIZwjB5GN5sh7sp4kqgwpp0=.76e58008-d0f1-4523-ba24-5341e70c8fcf@github.com>

On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current strategy for bootstrapping JEP 280 String concat expressions uses either an optimized MH expression tree, or, due to scalability issues with that implementation, a per call-site StringBuilder-based class generation scheme.
> 
> This RFE seeks to unify these into a single strategy that uses per-shape class generation emitting code semantically similar to the optimized MH expression tree. Using hidden classes installed into java.lang with access to the StringConcatHelper set of utility methods this can achieve similar throughput performance, while reducing the number of generated classes at high arities, reducing startup overheads, and improving warmup characteristics.
> 
> This RFE was initially prompted by a suggestion of @cl4es in the discussion of PR #20253 (https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866), and then evolved after collaborating on this issue into this full re-implementation.

This pull request has now been integrated.

Changeset: 5022109b
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5022109b2a33a8cf2608eb829098b27641b731a4
Stats:     1345 lines in 8 files changed: 1212 ins; 29 del; 104 mod

8336856: Efficient hidden class-based string concatenation strategy

Co-authored-by: Claes Redestad <redestad at openjdk.org>
Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20273

From duke at openjdk.org  Fri Aug 16 13:46:00 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 16 Aug 2024 13:46:00 GMT
Subject: RFR: 8336856: Efficient hidden class-based string concatenation
 strategy [v55]
In-Reply-To: <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
References: <uTQr881vmph7ZSta2Gw_rwn5TcpVBT46OXS1WCt6Osk=.11dea36c-6e74-4c3c-94d6-0be09962b5e0@github.com>
 <Wx58C0Uh5r8vrtE3HeaANdmQz_98Seb1_WHTDbyL6Jc=.4baf626e-f9d3-44a6-a49a-33dd6e6d59e9@github.com>
Message-ID: <f3mK4VqM4SGWpuM3NQEHx-DEFEjGcT-UbaDL0lAgGaw=.bd882566-b12f-4ea7-9edf-a867efe3c68c@github.com>

On Tue, 13 Aug 2024 16:34:18 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current strategy for bootstrapping JEP 280 String concat expressions uses either an optimized MH expression tree, or, due to scalability issues with that implementation, a per call-site StringBuilder-based class generation scheme.
>> 
>> This RFE seeks to unify these into a single strategy that uses per-shape class generation emitting code semantically similar to the optimized MH expression tree. Using hidden classes installed into java.lang with access to the StringConcatHelper set of utility methods this can achieve similar throughput performance, while reducing the number of generated classes at high arities, reducing startup overheads, and improving warmup characteristics.
>> 
>> This RFE was initially prompted by a suggestion of @cl4es in the discussion of PR #20253 (https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866), and then evolved after collaborating on this issue into this full re-implementation.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - static final
>  - code style

135 comments, 112 + 28 conversations (28 in draft PR #20248), this is a huge work!

@cl4es provided ideas and solved several key technical problems, including solving reusability and forceinline to make C2 work, erase argument, and solving WithSecurityManager build errors.

@liach provided a way to run without trusted lookup permissions.

Thanks to @cl4es and @liach, it is your help to complete this huge work, or more accurately, we worked together efficiently and well to complete this huge work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2293538032

From prappo at openjdk.org  Fri Aug 16 14:08:53 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 16 Aug 2024 14:08:53 GMT
Subject: Integrated: 8338398: Trivially fix grammar and typos
In-Reply-To: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
References: <mRK3wyfa-gMIy8U-k1fw16b7m75dbBO2hMyiEYGpZfs=.f7fee917-8c92-4a32-b171-584eb7b9eea0@github.com>
Message-ID: <1lAv9XHVwCJyRQJ0xnmTuL11o4FFsqdNYrGOIDD4Fkk=.e14fb46d-ed69-4cb9-9556-287cb3f062b7@github.com>

On Wed, 14 Aug 2024 13:38:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR fixes a few trivial grammar issues and typos in documentation.
> 
> The main issue is the use of the word "timeout". To my mind, timeout, a duration, is not the same as deadline, which is a point in time, an instant, which allows "before" and "after". While one can think of timeout as of an event, which can occur, it usually expires, or elapses. An activity can also "time out" (phrasal verb).
> 
> I think the proposed change might read better and match wording already used throughout `java.util.concurrent.**`, for example, here:  
> 
> * https://github.com/openjdk/jdk/blob/00e6c63cd12e3f92d0c1d007aab4f74915616ffb/src/java.base/share/classes/java/util/concurrent/ExecutorService.java#L211-L223
> * https://github.com/openjdk/jdk/blob/fbe4cc96e223882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036 
> 
> @DougLea, thoughts?

This pull request has now been integrated.

Changeset: 07352c67
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07352c67448f3f35827395c83ac95e3ca0e4c6bc
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8338398: Trivially fix grammar and typos

Reviewed-by: aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/20584

From liach at openjdk.org  Fri Aug 16 15:28:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:28:03 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v11]
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Missed JLS prefix from web review
 - More bad terms and redundancy
 - Fix terminology
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - Stage
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - remove compile, use element-value, break long sentences
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
 - ... and 10 more: https://git.openjdk.org/jdk/compare/07352c67...802775ee

-------------

Changes: https://git.openjdk.org/jdk/pull/20247/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20247&range=10
  Stats: 374 lines in 20 files changed: 131 ins; 114 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/20247.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20247/head:pull/20247

PR: https://git.openjdk.org/jdk/pull/20247

From liach at openjdk.org  Fri Aug 16 15:28:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:28:03 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v10]
In-Reply-To: <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <U6mBQBNNIVxcw97b216npIXvusHkx2idSBBAM4QW340=.d13d7d56-d4b9-40a9-b536-01125033eada@github.com>
Message-ID: <DxjT4RbKeot_mRG0QaXsaV8vAMEs5DrKdn-nn2ZkX3k=.35205e14-18b7-47ae-b5cf-9d062f40b69b@github.com>

On Tue, 13 Aug 2024 19:56:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed JLS prefix from web review

Swallowed the 2 conflicts from #20513: The tags are already correct in this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2293712126

From asotona at openjdk.org  Fri Aug 16 15:44:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 16 Aug 2024 15:44:51 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v11]
In-Reply-To: <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
Message-ID: <p-MYukNHMpJWWbfq-l9kgtBADyMGmP2WVoY9iAH45jU=.e0367801-f143-4a0d-b8c7-9005cd988bd0@github.com>

On Fri, 16 Aug 2024 15:28:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Missed JLS prefix from web review
>  - More bad terms and redundancy
>  - Fix terminology
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Stage
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/07352c67...802775ee

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20247#pullrequestreview-2243000645

From liach at openjdk.org  Fri Aug 16 15:52:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:52:09 GMT
Subject: RFR: 8336754: Remodel TypeAnnotation to "has" instead of "be" an
 Annotation [v11]
In-Reply-To: <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
 <vMD3r9ouqcQILcoIuG6GXofSNF1dvu7pEIUJP7wKq4w=.a6a9ebb1-7043-40cf-9147-3f913e2c1228@github.com>
Message-ID: <yHfD4ZEt1V_KlwziM_MKMB6FwUMDCpa4q4M8GUl4IKc=.3a143031-ccb4-4146-ba0b-d97c64107b76@github.com>

On Fri, 16 Aug 2024 15:28:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
>> 
>> Depends on #20205.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Missed JLS prefix from web review
>  - More bad terms and redundancy
>  - Fix terminology
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - Stage
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - remove compile, use element-value, break long sentences
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typeanno-model
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/07352c67...802775ee

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20247#issuecomment-2293747699

From liach at openjdk.org  Fri Aug 16 15:52:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Aug 2024 15:52:09 GMT
Subject: Integrated: 8336754: Remodel TypeAnnotation to "has" instead of "be"
 an Annotation
In-Reply-To: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
References: <f1DcSXp5z92oqlxD0215g9cMqpd_GZNMuLvdvpumBeU=.55fcc643-7985-4e4e-b0d7-32d67bd471d9@github.com>
Message-ID: <RDK7N3d2Q1upLL1wGWV4Vk3qTY-9WcEoBXT0DK_MWpE=.e8a265c8-2fe2-4112-a00d-427bd2944396@github.com>

On Fri, 19 Jul 2024 01:55:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> `TypeAnnotation` is not an annotation, as it should not be used in places like `AnnotationValue.ofAnnotation`. Thus it's remodeled to contain an annotation at a given location instead of to be an annotation.
> 
> Depends on #20205.

This pull request has now been integrated.

Changeset: 961e944f
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/961e944fa731dc84be2764c01e4b326187474605
Stats:     374 lines in 20 files changed: 131 ins; 114 del; 129 mod

8336754: Remodel TypeAnnotation to "has" instead of "be" an Annotation

Co-authored-by: Alex Buckley <abuckley at openjdk.org>
Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20247

From john.r.rose at oracle.com  Fri Aug 16 23:38:45 2024
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 16 Aug 2024 19:38:45 -0400
Subject: RFR: 8338023: Support two vector selectFrom API
In-Reply-To: <C34zJEYsU2d4uOH6X3-hwmvkF2gfcfUcUw-vPpE45IU=.6c234fee-a4f9-441c-905e-fea9e82a44fe@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <z_ZtI1BJ66rCzes21Spb19ZQHYkKwhe45ZpvKV0htD8=.e1d290eb-3560-4283-94e6-3e4b792c099a@github.com>
 <C34zJEYsU2d4uOH6X3-hwmvkF2gfcfUcUw-vPpE45IU=.6c234fee-a4f9-441c-905e-fea9e82a44fe@github.com>
Message-ID: <A079E0C6-AE5F-472D-BD8A-D0271A962D1E@oracle.com>

(Better late than never, although I wish I?d been more explicit
about this on panama-dev.)

I think we should be moving away from throwing exceptions on all
reorder/shuffle/permute vector ops, and moving toward wrapping.
These ops all operate on vectors (small arrays) of vector lane
indexes (small array indexes in a fixed domain, always a power
of two).  The throwing behavior checks an input for bad indexes
and throws a (scalar) exception if there are any at all.  The
wrapping behavior reduces bad indexes to good ones by an unsigned
modulo operation (which is at worst a mask for powers of two).

If I?m right, then new API points should start out with wrap
semantics, not throw semantics.  And old API points should be
migrated ASAP.

There?s no loss of functionality in such a move.  Instead the
defaults are moved around.  Before, throwing was the default
and wrapping was an explicit operation.  After, wrapping would
be the default and throwing would be explicit.  Both wrapping
and throwing checks are available through explicit calls to
VectorShuffle methods checkIndexes and wrapIndexes.

OK, so why is wrapping better than throwing?  And first, why
did we start with throwing as the default?  Well, we chose
throwing as the default to make the vector operations
more Java-like.  Java scalar operations don?t try to reduce
bad array indexes into the array domain; they throw.  Since
a shuffle op is like an array reference, it makes sense to
emulate the checks built into Java array references.

Or it did make sense.  I think there is a technical debt
here which is turning out to be hard to pay off.  The tech
debt is to suppress or hoist or strength-reduce the vector
instructions that perform the check for invalid indexes
(in parallel), then ask ?did any of those checks fail??
(a mask reduction), then do a conditional branch to
failure code.  I think I was over-confident that our
scalar tactics for reducing array range checks would
apply to vectors as well.  On second thought, vectorizing
our key optimization, of loop range splitting (pre/main/post
loops) is kind of a nightmare.

Instead, consider the alternative of wrapping.  First,
you use vpand or the like to mask the indexes down to
the valid range.  Then you run the shuffle/permute
instruction.  That?s it.  There is no scalar query
or branch.  And, there are probably some circumstances
where you can omit the vpand operation:  Perhaps the
hardware already masks the inputs (as with shift
instructions).  Or, perhaps C2 can do bitwise inference
of the vectors and figure out that the vpand is a nop.
(I am agitating for bitwise types in C2; this is a use
case for them.)  In the worst case, the vpand op is
fast and pipelines well.

This is why I think we should switch, ASAP, to masking
instead of throwing, on bad indexes.

I think some of our reports from customers have shown
that the extra checks necessary for throwing on bad
indexes are giving their code surprising slowdowns,
relative to C-based vector code.

Did I miss a point?

? John

On 14 Aug 2024, at 3:43, Jatin Bhateja wrote:

> On Mon, 12 Aug 2024 22:03:44 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:
>
>> The results look promising. I can provide guidance on the specification e.g., we can specify the behavior in terms of rearrange, with the addition of throwing on out of bounds indexes.
>>
>> Regarding the throwing of exceptions, some wider context will help to know where we are heading before we finalize the specification. I believe we are considering changing the default throwing behavior for index out of bounds to wrapping, thereby we can avoid bounds checks. If that is the case we should wait until that is done then update rather than submitting a CSR just yet?
>>
>> I see you created a specific intrinsic, which will avoid the cost of shuffle creation. Should we apply the same approach (in a subsequent PR) to the single argument shuffle? Or perhaps if we manage to optimize shuffles and change the default wrapping we don't require a specific intrinsic and can just use defer to rearrange?
>
> Hi @PaulSandoz ,
> Thanks for your comments. With this new API we intend to enforce stricter specification w.r.t to index values to emit a lean instruction sequence preventing any cycles spent on massaging inputs to a consumable form, thus preventing redundant wrapping and unwrapping operations.
>
> Existing [two vector rearrange API](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html#rearrange(jdk.incubator.vector.VectorShuffle,jdk.incubator.vector.Vector)) has a flexible specification which allows wrapping out of bounds shuffle indexes into exceptional index with a -ve value.
>
> Even if we optimize existing two vector rearrange implementation we will still need to emit additional instructions to generate an indexes which lie within two vector range [0, 2*VLEN). I see this as a specialized API like vector compress/expand which cater to targets like x86-AVX512+ and aarch64-SVE which offers direct instruction for two vector lookups.
>
> May be the API nomenclature can be refined to better reflect its semantics i.e. from selectFrom to twoVectorLookup ?
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2288062038

From jkratochvil at openjdk.org  Sat Aug 17 04:47:55 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 17 Aug 2024 04:47:55 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v19]
In-Reply-To: <al8-84qIReC0un3wrpfUBFS8d2Xbfzxc4yqCVaWkzlY=.958d09a8-afc1-41fb-8dce-e6adb9823dee@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <UJEH6O85W5S7EPcsD74dXIcXqmYamjdsDuKeSb0ID-Y=.492ccb0e-85eb-41d4-a9ad-3f4fc47a1bb4@github.com>
 <al8-84qIReC0un3wrpfUBFS8d2Xbfzxc4yqCVaWkzlY=.958d09a8-afc1-41fb-8dce-e6adb9823dee@github.com>
Message-ID: <JtRuzzklYESrafbgHdhw1sTA8k235ZcMhwLy6e-i0og=.c30293f3-88a5-45a2-a69b-da6ca121b322@github.com>

On Mon, 12 Aug 2024 18:36:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Inline adjust_controller() twice
>>  - Revert "Unify 4 copies of adjust_controller()"
>>    
>>    This reverts commit 77a81d07d74c8ae9bf34bfd8df9bcaca451ede9a.
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 120:
> 
>> 118:             args.add(jdkTool);
>> 119:             args.add("-cp");
>> 120:             args.add(System.getProperty("java.class.path"));
> 
> Should probably be `test.classes` instead of `java.class.path`.

It cannot be as the testcases spawns a new Java process and it cannot replicate its own commandline from JTREG (I haven't found it in system properties). In such case `java.class.path` works but `java.classes` is null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1720603883

From jkratochvil at openjdk.org  Sat Aug 17 04:53:58 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 17 Aug 2024 04:53:58 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v20]
In-Reply-To: <Ikvesf5FPkQc0ZD4A3yfb7pKekPzA539BoxXq5TNgQY=.f74eb83d-6763-4eed-bb07-b128f969b91a@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <armE1TJT6euiIdqBUr7syBd5IAuArt4sTywLVp0CSgU=.4d85d1c0-d07a-4d3f-b2ed-6d871d1ec731@github.com>
 <Ikvesf5FPkQc0ZD4A3yfb7pKekPzA539BoxXq5TNgQY=.f74eb83d-6763-4eed-bb07-b128f969b91a@github.com>
Message-ID: <0VFyedOoFVbZw_G3pTpH_8z0Y6rmzdOMuyoPdGnQv_Y=.638e8f3b-e6d3-458c-b5ea-a2551e7b1db8@github.com>

On Wed, 14 Aug 2024 15:55:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Testcase update upon review by Severin Gehwolf
>
> test/hotspot/jtreg/containers/cgroup/NestedCgroup.java line 139:
> 
>> 137:             } else {
>> 138:               throw new IllegalArgumentException();
>> 139:             }
> 
> This can be done once in `NestedCgroup.main` and then passed in on instantiation of `Test*` classes.

It cannot because jdk.internal.platform.Metrics is JDK-private and it must be exported by jtreg `@modules java.base/jdk.internal.platform`. And this jtreg export does not work for the newly spawned Java as I cannot replicate the jtreg commandline, I haven't found it in system properties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17198#discussion_r1720605769

From jkratochvil at openjdk.org  Sat Aug 17 05:29:31 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 17 Aug 2024 05:29:31 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v21]
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <Laro5HJ5erxe0pETqdeDbZB2PJuI_KXz8HVc6cafyhU=.66ba40c9-ae81-4f23-ab5a-ab2742568462@github.com>

> The testcase requires root permissions.
> 
> Fix by  Severin Gehwolf.
> Testcase 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 12 commits:

 - Functionality fixes after the refactorization
 - Fix up compilation
 - Merge remote-tracking branch 'origin/master' into master-cgroup
 - Merge remote-tracking branch 'origin/master' into master-cgroup
 - Testcase update upon review by Severin Gehwolf
 - Testcase update upon review by Severin Gehwolf
 - Inline adjust_controller() twice
 - Revert "Unify 4 copies of adjust_controller()"
   
   This reverts commit 77a81d07d74c8ae9bf34bfd8df9bcaca451ede9a.
 - Implement vm.cgroup.tools
 - Use Metrics.systemMetrics().getProvider()
 - ... and 2 more: https://git.openjdk.org/jdk/compare/07352c67...f06645f2

-------------

Changes: https://git.openjdk.org/jdk/pull/17198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17198&range=20
  Stats: 590 lines in 12 files changed: 514 ins; 54 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/17198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17198/head:pull/17198

PR: https://git.openjdk.org/jdk/pull/17198

From aturbanov at openjdk.org  Sat Aug 17 17:26:56 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 17 Aug 2024 17:26:56 GMT
Subject: RFR: 8338023: Support two vector selectFrom API
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <w_AlLdoYCAQ1oaDt7Iv0vohcXa-f5U0AvbHI6waC7tc=.c80f7e03-1567-4ea7-8544-abc63c2fdaa3@github.com>

On Thu, 8 Aug 2024 06:57:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 331:

> 329:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 330:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 331:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Double64VectorTests.java line 348:

> 346:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 347:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 348:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java line 353:

> 351:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 352:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 353:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Float128VectorTests.java line 348:

> 346:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 347:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 348:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Float256VectorTests.java line 348:

> 346:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 347:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 348:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Float512VectorTests.java line 348:

> 346:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 347:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 348:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java line 353:

> 351:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 352:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 353:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Int512VectorTests.java line 331:

> 329:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 330:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 331:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/IntMaxVectorTests.java line 336:

> 334:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 335:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 336:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Long256VectorTests.java line 288:

> 286:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 287:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 288:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Long64VectorTests.java line 288:

> 286:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 287:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 288:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

test/jdk/jdk/incubator/vector/Short256VectorTests.java line 331:

> 329:             boolean is_exceptional_idx = (int)order[idx] >= vector_len;
> 330:             int oidx = is_exceptional_idx ? ((int)order[idx] - vector_len) : (int)order[idx];
> 331:             Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " +  b[i + oidx]);

Suggestion:

            Assert.assertEquals(r[idx], (is_exceptional_idx ? b[i + oidx] : a[i + oidx]), "at index #" + idx + ", order = " + (int)order[idx] + ", a = " + a[i + oidx] + ", b = " + b[i + oidx]);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807165
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807191
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807216
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807254
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807143
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807202
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807129
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807262
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807098
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807239
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807206
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1720807231

From aturbanov at openjdk.org  Sat Aug 17 17:28:56 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 17 Aug 2024 17:28:56 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v3]
In-Reply-To: <JwEdPnjUezCjbmtad2sFbDMibfS5OrFBaBxQDHzkB3Y=.a73ade46-34b8-4ca0-87c2-03f8bc14fdde@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <JwEdPnjUezCjbmtad2sFbDMibfS5OrFBaBxQDHzkB3Y=.a73ade46-34b8-4ca0-87c2-03f8bc14fdde@github.com>
Message-ID: <9inKZjq3czAlh1fgRHhzGPxABxYlC6FEVpg7nloQYok=.9cd4a3f6-6d87-40c1-b9ee-63927bd7391f@github.com>

On Wed, 14 Aug 2024 04:59:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions

src/java.base/share/classes/java/lang/Byte.java line 81:

> 79:      * A constant holding polarity(sign) mask used by saturating operations.
> 80:      */
> 81:     public static final byte POLARITY_MASK_BYTE  = (byte)(1 << 7);

Suggestion:

    public static final byte POLARITY_MASK_BYTE = (byte)(1 << 7);

src/java.base/share/classes/java/lang/Byte.java line 672:

> 670:         byte res = (byte)(a + b);
> 671:         boolean overflow = Byte.compareUnsigned(res, (byte)(a | b)) < 0;
> 672:         if (overflow)  {

Suggestion:

        if (overflow) {

src/java.base/share/classes/java/lang/Long.java line 93:

> 91:      * A constant holding polarity(sign) mask used by saturating operations.
> 92:      */
> 93:     public static final long POLARITY_MASK_LONG  = 1L << 63;

Suggestion:

    public static final long POLARITY_MASK_LONG = 1L << 63;

src/java.base/share/classes/java/lang/Long.java line 2033:

> 2031:         long res = a + b;
> 2032:         boolean overflow = Long.compareUnsigned(res, (a | b)) < 0;
> 2033:         if (overflow)  {

Suggestion:

        if (overflow) {

src/java.base/share/classes/java/lang/Short.java line 707:

> 705:         short res = (short)(a + b);
> 706:         boolean overflow = Short.compareUnsigned(res, (short)(a | b)) < 0;
> 707:         if (overflow)  {

Suggestion:

        if (overflow) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1720807587
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1720807612
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1720807574
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1720807513
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1720807466

From liach at openjdk.org  Sun Aug 18 18:28:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 Aug 2024 18:28:58 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v3]
In-Reply-To: <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <7Or8-abveTsvZXbVkS5E93rJdGMyr92Eai04ATdFtcw=.8fb787ad-6418-46e6-9af6-dc7434d442e5@github.com>
Message-ID: <pGRt4dHdvddFLqnecQjzHNPNPohBURix2N--XqthRm0=.c1061973-5e1b-4ed5-9fc5-46960eb89661@github.com>

On Fri, 26 Apr 2024 22:27:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Add test to ensure reproducible iteration order
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Copyright year, revert changes for non-few element collections
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/a920af23...70583024

Keep-alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2295349673

From jpai at openjdk.org  Mon Aug 19 04:46:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Aug 2024 04:46:53 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v4]
In-Reply-To: <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
Message-ID: <eP-Nee4Av7yi_UQqFeSPrEC_PH_V-XJHXP8ksAVXjaM=.5276df70-cc50-4bf1-94d4-ee41c8718fd4@github.com>

On Fri, 26 Jul 2024 06:29:05 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.
>> 
>> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails.
>> 
>> 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 the exception's toString() into SkipException

tier1 testing with these changes against latest master branch completed without issues. I'll go ahead and sponsor this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2295657576

From syan at openjdk.org  Mon Aug 19 04:46:53 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 19 Aug 2024 04:46:53 GMT
Subject: Integrated: 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: <aKAvX9d63PxcILDZRPM21J2_S8j6BLSGlZ7Zj5JcLpo=.ad742813-698a-40ed-bbd1-0ba4ee2d073e@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.
> 
> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails.
> 
> Only change the testcase, the change has been verified locally, no risk.

This pull request has now been integrated.

Changeset: 2f7ba781
Author:    SendaoYan <syan at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f7ba781bf2e4e6d0fa658c19f86c6c05d60358a
Stats:     18 lines in 1 file changed: 7 ins; 6 del; 5 mod

8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/19905

From duke at openjdk.org  Mon Aug 19 06:32:22 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:22 GMT
Subject: RFR: 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor
Message-ID: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>

The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.

By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

-------------

Commit messages:
 - more descString
 - Consolidated parsing, now supports 9 params
 - clean up Wrapper.forPrimitiveType
 - use ConstantDescs.MTD_void
 - optimization for `Ljava/lang/Object;`
 - more descString
 - private PrimitiveClassDescImpl constructor
 - private PrimitiveClassDescImpl constructor
 - minor refactor
 - add comments
 - ... and 32 more: https://git.openjdk.org/jdk/compare/74066bcc...ee321904

Changes: https://git.openjdk.org/jdk/pull/20611/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20611&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338532
  Stats: 272 lines in 11 files changed: 160 ins; 61 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/20611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20611/head:pull/20611

PR: https://git.openjdk.org/jdk/pull/20611

From redestad at openjdk.org  Mon Aug 19 06:32:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 19 Aug 2024 06:32:23 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>

On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

Yes, this is a good one. I observed this oddity when I worked on #18971 but had a long list of other improvements to work on and didn't get around to filing an RFE. 

Can you check if the pre-existing MethodTypeDescFactories microbenchmark is sufficient to verify your optimization here?

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 309:

> 307:     private static ClassDesc resolveClassDesc(String descriptor, int start, int len) {
> 308:         if (len == 1) {
> 309:             return Wrapper.forPrimitiveType(descriptor.charAt(start)).basicClassDescriptor();

This was already piggy-backing on a quite fast routine. If it's a clean, significant win then I'm fine with this (untangling `Wrapper` from this is probably good, all things considered), but then we should also clean up `Wrapper` to not carry some descriptors around.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 109:

> 107:     public static MethodTypeDescImpl ofDescriptor(String descriptor) {
> 108:         // Implicit null-check of descriptor
> 109:         List<ClassDesc> ptypes = ConstantUtils.parseMethodDescriptor(descriptor);

This might have been the only use of parseMethodDescriptor - so you can probably remove that method, making this patch a net clean-up in terms of lines of code.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 137:

> 135:         var returnType = resolveClassDesc(descriptor, rightBracket + 1, retTypeLength);
> 136:         if (length == 3 && returnType == CD_void) {
> 137:             return Constants.MTD_void;

Feels a bit like overfitting with quite limited data.

Could this use `ConstantDescs.MTD_void` instead or does that cause a bootstrap cycle?

test/micro/org/openjdk/bench/java/lang/classfile/MethodTypeDescBench.java line 23:

> 21:  * questions.
> 22:  */
> 23: package org.openjdk.bench.java.lang.classfile;

Wrong package as the code being tested is in java.lang.constant. Also there is already a related microbenchmark in org.openjdk.bench.java.lang.constant.MethodTypeDescFactories - can you check if that covers your needs?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20611#pullrequestreview-2242492738
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721063121
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719707693
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721061415
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719709479

From duke at openjdk.org  Mon Aug 19 06:32:23 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:23 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>

On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

Below are the performance numbers running on a MacBook M1 Pro. 
1. In the scenario without parameters, the performance is regressed. 
2. When the number of parameters is >=1 and <=8, the performance is significantly improved. 
3. When the number of parameters is >8, the performance is regressed.

## Benchmark script

# baseline
git checkout 74066bcca82749722e6fee57469520d418bf3430
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# current
git checkout a2f88806e04eb08d9d4d64bfa7411fc72dd28497
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## Performance numbers

# baseline
Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   102.502 ?  3.680  ns/op
MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.840 ?  0.010  ns/op
MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   232.782 ? 60.823  ns/op
MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    25.170 ?  0.036  ns/op
MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   281.701 ? 61.816  ns/op
MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1117.963 ?  8.493  ns/op

# current
Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    53.423 ?  1.182  ns/op
MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     4.801 ?  0.065  ns/op
MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    68.220 ?  0.107  ns/op
MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    26.471 ?  0.165  ns/op
MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   123.778 ?  0.542  ns/op
MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1713.325 ? 13.985  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 102.502 | 53.423 | 91.87% |
| ()V | 3.840 | 4.801 | -20.02% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 232.782 | 68.220 | 241.22% |
| ()[Ljava/lang/String; | 25.170 | 26.471 | -4.91% |
| (..IIJ)V | 281.701 | 123.778 | 127.59% |
| (.....................). | 1117.963 | 1713.325 | -34.75% |

The performance regression problem in the scenario without parameters has been solved. It was caused by an extra lastIndexOf.

Below are the performance numbers running on a MacBook M1 Pro.

## Benchmark script

# baseline
git checkout 74066bcca82749722e6fee57469520d418bf3430
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# current
git checkout 8b262b2e4e146c72b7c331a89ac201b41893a8b3
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## Performance numbers


-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score     Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   104.154 ?   2.636  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.843 ?   0.014  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   221.013 ?  81.200  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.603 ?   0.026  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   221.404 ? 189.754  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1128.418 ?  16.850  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score   Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    53.000 ? 0.758  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.548 ? 0.007  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    68.731 ? 0.084  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.365 ? 0.173  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   128.002 ? 0.819  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1663.985 ? 4.529  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 104.154 | 53.000 | 96.52% |
| ()V | 3.843 | 3.548 | 8.31% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 221.013 | 68.731 | 221.56% |
| ()[Ljava/lang/String; | 20.603 | 20.365 | 1.17% |
| (..IIJ)V | 221.404 | 128.002 | 72.97% |
| (.....................). | 1128.418 | 1663.985 | -32.19% |

The following are the performance numbers on multiple platforms. When the number of parameters is > 8, the performance will regress by about 33%. When the number of parameters is <= 8, the performance will be significantly improved or neutral.

## 1. Benchmark script

# baseline
git checkout 74066bcca82749722e6fee57469520d418bf3430
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# current
git checkout c02d2306935d99685e34ef960aa72e10feb82a39
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## 2. Performance numbers

### 2.1 Mac Book M1 Pro

-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score     Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   104.154 ?   2.636  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.843 ?   0.014  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   221.013 ?  81.200  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.603 ?   0.026  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   221.404 ? 189.754  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1128.418 ?  16.850  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    53.900 ?  0.061  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.609 ?  0.017  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    69.666 ?  0.596  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.978 ?  0.197  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   126.968 ?  0.715  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1651.624 ? 30.462  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 104.154 | 53.900 | 93.24% |
| ()V | 3.843 | 3.609 | 6.48% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 221.013 | 69.666 | 217.25% |
| ()[Ljava/lang/String; | 20.603 | 20.978 | -1.79% |
| (..IIJ)V | 221.404 | 126.968 | 74.38% |
| (.....................). | 1128.418 | 1651.624 | -31.68% |


### 2.2 Aliyun ECS c8a
* AMD CPU (x64)
* Linux


-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    69.575 ?  0.197  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6    10.170 ?  0.065  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    91.331 ?  0.339  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    22.479 ?  0.108  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   143.278 ?  0.314  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1155.946 ? 26.590  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score   Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    58.870 ? 1.330  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.785 ? 0.039  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    77.584 ? 0.120  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    22.040 ? 0.060  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   139.849 ? 0.397  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1750.701 ? 3.811  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 69.575 | 58.870 | 18.18% |
| ()V | 10.170 | 3.785 | 168.69% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 91.331 | 77.584 | 17.72% |
| ()[Ljava/lang/String; | 22.479 | 22.040 | 1.99% |
| (..IIJ)V | 143.278 | 139.849 | 2.45% |
| (.....................). | 1155.946 | 1750.701 | -33.97% |


### 2.3 Aliyun ECS c8i
* Intel CPU (x64)
* Linux


-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score   Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    71.377 ? 0.531  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6    13.137 ? 0.039  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    90.090 ? 0.303  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    22.589 ? 0.127  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   149.114 ? 0.407  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1213.178 ? 6.771  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score   Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    57.653 ? 0.874  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     4.295 ? 0.028  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    73.995 ? 0.268  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    22.839 ? 0.148  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   152.082 ? 0.657  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1944.548 ? 8.628  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 71.377 | 57.653 | 23.80% |
| ()V | 13.137 | 4.295 | 205.87% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 90.090 | 73.995 | 21.75% |
| ()[Ljava/lang/String; | 22.589 | 22.839 | -1.09% |
| (..IIJ)V | 149.114 | 152.082 | -1.95% |
| (.....................). | 1213.178 | 1944.548 | -37.61% |

### 2.4 Aliyun ECS c8y
* CPU Aliyun Yitian 710 (aarch64)
* Linux


-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    87.788 ?  1.286  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     5.894 ?  0.121  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   130.803 ?  5.688  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    32.126 ?  0.292  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   195.543 ?  1.942  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1600.544 ? 16.898  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    82.522 ?  2.328  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     5.560 ?  0.224  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   101.175 ?  1.996  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    31.696 ?  0.736  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   194.115 ?  1.705  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  2592.137 ? 22.466  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 69.575 | 58.870 | 18.18% |
| ()V | 10.170 | 3.785 | 168.69% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 91.331 | 77.584 | 17.72% |
| ()[Ljava/lang/String; | 22.479 | 22.040 | 1.99% |
| (..IIJ)V | 143.278 | 139.849 | 2.45% |
| (.....................). | 1155.946 | 1750.701 | -33.97% |

We construct an image with statistical information as follows:


package jdk.internal.constant;

class MethodTypeDescImpl {
    static int invokeCount = 0;
    static int[] stats = new int[40];

    static MethodTypeDescImpl ofDescriptor(String descriptor) {
        // ...

        invokeCount++;
        stats[paramTypes.length]++;

        return result;
    }
}


Build a test to print statistics


public class MethodTypDescStats {
    public static void main(String[] args) throws Exception {
        var cl = Class.forName("jdk.internal.constant.MethodTypeDescImpl");

        Field statsField = cl.getDeclaredField("stats");
        statsField.setAccessible(true);

        Field invokeCountField = cl.getDeclaredField("invokeCount");
        invokeCountField.setAccessible(true);

        int invokeCount = (Integer) invokeCountField.get(null);
        int[] stats = (int[]) statsField.get(null);
        System.out.println("invokeCount : " + invokeCount);
        System.out.println(Arrays.toString(stats));
    }
}


Running Tests

java --add-opens java.base/jdk.internal.constant=ALL-UNNAMED MethodTypDescStats


Output

invokeCount : 110
[93, 24, 32, 37, 11, 7, 5, 3, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]


It can be seen that during the JVM startup process, the MethodTypeDescImpl#ofDescriptor method was executed 110 times, and the number of parameters was greater than 8 twice (both were 9).

According to this data, the optimization of the current version is getting better. It improves significantly when the number of parameters is less than or equal to 8, and decreases slightly when the number of parameters is greater than 8.

Here is where bootstrap uses MethodTypeDesc.ofDescriptor:

at java.base/java.lang.constant.MethodTypeDesc.ofDescriptor(MethodTypeDesc.java:60)
at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.methodTypeSymbol(DirectMethodBuilder.java:88)

Here are the descriptor statistics of bootstrap calling ofDescriptor, `()V` 99 times, accounting for 62.65% of the total, so `()V` should be optimized separately.


invokeCount : 158

99	()V
14	(Ljava/lang/Object;)Ljava/lang/Object;
13	(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
8	()Ljava/lang/Object;
6	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
6	(Ljava/lang/Object;Ljava/lang/Object;)V
5	(Ljava/lang/Object;)Z
4	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;)Ljava/lang/invoke/BoundMethodHandle;
4	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;J)Ljava/lang/invoke/BoundMethodHandle;
4	()Ljava/lang/invoke/BoundMethodHandle$SpeciesData;
4	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V
4	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;I)Ljava/lang/invoke/BoundMethodHandle;
4	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;D)Ljava/lang/invoke/BoundMethodHandle;
4	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;F)Ljava/lang/invoke/BoundMethodHandle;
4	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;)Ljava/lang/invoke/BoundMethodHandle;
3	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
3	(Ljava/lang/Object;Ljava/lang/Object;J)Ljava/lang/Object;
3	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V
3	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
3	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
3	(Ljava/lang/Object;Ljava/lang/Object;)I
2	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
2	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
2	(Ljava/lang/Object;JLjava/lang/Object;ILjava/lang/Object;)J
2	(Ljava/lang/Object;Ljava/lang/Object;JI)Ljava/lang/Object;
2	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)I
2	(Ljava/lang/Object;JI)J
2	(Ljava/lang/module/ModuleFinder;)V
1	(Ljava/lang/Object;I)J
1	(Ljava/lang/Object;I)I
1	(Ljdk/internal/module/SystemModuleFinders$1;Ljava/lang/String;)V
1	(Ljava/lang/Object;Ljava/lang/Object;I)Ljava/lang/Object;
1	(Ljava/lang/Object;I)V
1	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;J)Ljava/lang/Object;
1	(Ljava/lang/Object;JLjava/lang/Object;I)J
1	(Ljava/lang/Object;J)Ljava/lang/Object;
1	(Ljava/nio/file/Path;)V
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;J)Ljava/lang/invoke/BoundMethodHandle;
1	(Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/Object;ILjava/lang/Object;)J
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/invoke/BoundMethodHandle;
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V
1	(Ljava/lang/Object;)I
1	(Ljava/lang/Object;I)Ljava/lang/Object;
1	(Ljava/lang/Object;JI)Ljava/lang/Object;
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/invoke/BoundMethodHandle;
1	(Ljava/util/function/BiFunction;)V
1	(Ljava/lang/Object;)V
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;J)V
1	(Ljava/io/FileDescriptor;)V
1	(I)Z
1	(Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/Object;I)J
1	(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;J)Ljava/lang/Object;
1	(Ljava/lang/Object;Ljava/lang/Object;)J
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;)V
1	(Ljdk/internal/module/ModulePath;Ljava/nio/file/Path;)V
1	(Ljava/lang/module/ModuleDescriptor$Builder;)V
1	(Ljava/lang/Object;Ljava/lang/Object;I)J
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/invoke/BoundMethodHandle;
1	(ILjava/lang/Object;)Ljava/lang/Object;
1	(Ljava/lang/Object;Ljava/lang/Object;JI)J
1	(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V

Now, the performance of the most frequently called scenario `()V` has been significantly improved.

## 1. Benchmark script


# baseline
git checkout 1e17a42eda73bc5138e05502a004a8c293a93eb8
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# baseline
git checkout fa0895650e644602418dcadd9b57d58d1d5fb960
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## 2. Performance numbers

### 2.1 Mac Book M1 Pro


-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   102.574 ?  4.515  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.744 ?  0.007  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   227.739 ? 53.035  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.586 ?  0.054  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   251.047 ? 37.685  ns/op
-MethodTypeDescFactories.ofDescriptor                         ([III.Z[B..[.[B).  avgt    6   340.045 ?  1.722  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1187.174 ?  5.716  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    64.896 ?  2.925  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     1.397 ?  0.004  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    63.757 ?  0.962  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    21.169 ?  0.335  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   118.475 ?  0.806  ns/op
+MethodTypeDescFactories.ofDescriptor                         ([III.Z[B..[.[B).  avgt    6   349.402 ? 13.053  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1147.295 ?  6.988  ns/op



| pattern | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 102.574 | 64.896 | 58.06% |
| ()V | 3.744 | 1.397 | 168.00% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 227.739 | 63.757 | 257.20% |
| ()[Ljava/lang/String; | 20.586 | 21.169 | -2.75% |
| (..IIJ)V | 251.047 | 118.475 | 111.90% |
| ([III.Z[B..[.[B). | 340.045 | 349.402 | -2.68% |
| (.....................). | 1187.174 | 1147.295 | 3.48% |

I added two startup process descStrings to the benchmark, and now optimized the parameter type of `Ljava/lang/Object` as follows:

## 1. Benchmark script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline
git checkout b83e2705662aa444338586713a2a7b2fa7852ba6
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# current
git checkout 2405e63af284d4074056be40c550918541eead3a
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## 2. Performance numbers

### 2.1 Mac Book M1 Pro


-# baseline
-Benchmark                                                                         (descString)  Mode  Cnt     Score     Error  Units
-MethodTypeDescFactories.ofDescriptor                   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   100.245 ?   3.888  ns/op
-MethodTypeDescFactories.ofDescriptor                                                       ()V  avgt    6     3.762 ?   0.024  ns/op
-MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   148.798 ?  21.645  ns/op
-MethodTypeDescFactories.ofDescriptor                                      ()Ljava/lang/Object;  avgt    6    23.890 ?   0.053  ns/op
-MethodTypeDescFactories.ofDescriptor                  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   220.012 ?  63.268  ns/op
-MethodTypeDescFactories.ofDescriptor                                     ()[Ljava/lang/String;  avgt    6    20.612 ?   0.031  ns/op
-MethodTypeDescFactories.ofDescriptor                                                  (..IIJ)V  avgt    6   167.894 ? 153.553  ns/op
-MethodTypeDescFactories.ofDescriptor                                         ([III.Z[B..[.[B).  avgt    6   342.610 ?   2.296  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (.....................).  avgt    6  1115.834 ?   1.067  ns/op

+# current
+Benchmark                                                                         (descString)  Mode  Cnt     Score   Error  Units
+MethodTypeDescFactories.ofDescriptor                   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    48.616 ? 0.440  ns/op
+MethodTypeDescFactories.ofDescriptor                                                       ()V  avgt    6     1.400 ? 0.004  ns/op
+MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    56.567 ? 0.101  ns/op
+MethodTypeDescFactories.ofDescriptor                                      ()Ljava/lang/Object;  avgt    6    16.017 ? 0.036  ns/op
+MethodTypeDescFactories.ofDescriptor                  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    71.447 ? 0.392  ns/op
+MethodTypeDescFactories.ofDescriptor                                     ()[Ljava/lang/String;  avgt    6    20.948 ? 0.045  ns/op
+MethodTypeDescFactories.ofDescriptor                                                  (..IIJ)V  avgt    6   119.517 ? 0.606  ns/op
+MethodTypeDescFactories.ofDescriptor                                         ([III.Z[B..[.[B).  avgt    6   353.724 ? 7.413  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (.....................).  avgt    6  1161.422 ? 3.517  ns/op


| pattern | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 100.245 | 48.616 | 106.20% |
| ()V | 3.762 | 1.400 | 168.71% |
| (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; | 148.798 | 56.567 | 163.05% |
| ()Ljava/lang/Object; | 23.890 | 16.017 | 49.15% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 220.012 | 71.447 | 207.94% |
| ()[Ljava/lang/String; | 20.612 | 20.948 | -1.60% |
| (..IIJ)V | 167.894 | 119.517 | 40.48% |
| ([III.Z[B..[.[B). | 342.610 | 353.724 | -3.14% |
| (.....................). | 1115.834 | 1161.422 | -3.93% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2294501141
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2294534798
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2294905823
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295132102
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295300033
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295302133
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295328895
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295436632

From redestad at openjdk.org  Mon Aug 19 06:32:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 19 Aug 2024 06:32:23 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
Message-ID: <lS_yX5fcrhU1BQg46FKRGpBHFVLa8MVNA_r2iwkTT44=.0340ec40-64f4-4167-9554-878f263db8f5@github.com>

On Sat, 17 Aug 2024 00:39:35 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> 1. In the scenario without parameters, the performance is regressed.

You might be able to regain (some of) this by adding a check for `start == end` at the top of even before calling `paramTypes`

> 3. When the number of parameters is >8, the performance is regressed.

Under the assumption that low arity methods greatly outnumber high arity ones, some cost here would be acceptable. But let's try to avoid it while keeping things simple. 

An option would be to split the code into a fast-path that has an unrolled loop dealing with N args, then a slow path that does more or less the old logic with an ArrayList which we fall back to as soon as we hit either an argument that is too long or we go past N.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2294506811

From duke at openjdk.org  Mon Aug 19 06:32:23 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:23 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <lS_yX5fcrhU1BQg46FKRGpBHFVLa8MVNA_r2iwkTT44=.0340ec40-64f4-4167-9554-878f263db8f5@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
 <lS_yX5fcrhU1BQg46FKRGpBHFVLa8MVNA_r2iwkTT44=.0340ec40-64f4-4167-9554-878f263db8f5@github.com>
Message-ID: <7fRPIEQLzgxaIrGlH34sIi2Wgi03ti0Hge7aPdvi0TE=.5dca2442-3d40-4c66-a040-042e1688ee34@github.com>

On Sat, 17 Aug 2024 00:56:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Under the assumption that low arity methods greatly outnumber high arity ones, some cost here would be acceptable. But let's try to avoid it while keeping things simple.
> 
> An option would be to split the code into a fast-path that has an unrolled loop dealing with N args, then a slow path that does more or less the old logic with an ArrayList which we fall back to as soon as we hit either an argument that is too long or we go past N.

For the case where the number of parameters is greater than 8, we can also have another option, such as adding more lengths variables to cover more cases, such as:


   private static ClassDesc[] paramTypes(String descriptor, int start, int end) {
        /*
         * If the length of the first 8 parameters is <= 256, save them in lengths to avoid secondary scanning,
         * use 0 to indicate that the current parameter length is greater than 256 and needs to be reparsed
         */
        long lengths  = 0,
             lengths2 = 0,
             lengths3 = 0;

        int paramCount = 0;
        for (int cur = start; cur < end; ) {
            int len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end, false);
            if (len == 0) {
                throw badMethodDescriptor(descriptor);
            }
            int part = (len > 0xFF ? 0 : len);
            if (paramCount < 8) {
                lengths = (lengths << 8) | part;
            } else if (paramCount < 16) {
                lengths2 = (lengths2 << 8) | part;
            } else if (paramCount < 24) {
                lengths3 = (lengths3 << 8) | part;
            }
            paramCount++;
            cur += len;
        }

        var paramTypes         = new ClassDesc[paramCount];
        int paramIndex         = 0,
            cur                = start,
            lengthsParamCount  = Math.min(paramCount, 8 ) - 1,
            lengths2ParamCount = Math.min(paramCount, 16) - 9,
            lengths3ParamCount = Math.min(paramCount, 24) - 17;

        while (cur < end) {
            int len = 0
            if (paramIndex < 8) {
                int shift = (lengthsParamCount - paramIndex) << 3;
                len = (int) ((lengths & (0xFFL << shift)) >> shift) & 0xFF;
            } else if (paramIndex < 16) {
                int shift = (lengths2ParamCount - paramIndex) << 3;
                len = (int) ((lengths2 & (0xFFL << shift)) >> shift) & 0xFF;
            } else if (paramIndex < 24) {
                int shift = (lengths3ParamCount - paramIndex) << 3;
                len = (int) ((lengths3 & (0xFFL << shift)) >> shift) & 0xFF;
            }
            if (len == 0) {
                len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end, false);
            }
            paramTypes[paramIndex++] = ConstantUtils.resolveClassDesc(descriptor, cur, len);
            cur += len;
        }

        return paramTypes;
    }


But I agree with you that it's important to keep it simple.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2294592302

From liach at openjdk.org  Mon Aug 19 06:32:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:23 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
Message-ID: <LAEZf-NxbbY45PgQMu8GfZmdcXZXAkTt5HHo2jdGF48=.4abe80fd-ef7c-43e6-91da-5d0b29fbca58@github.com>

On Sat, 17 Aug 2024 16:27:50 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> The following are the performance numbers on multiple platforms. When the number of parameters is > 8, the performance will regress by about 33%. When the number of parameters is <= 8, the performance will be significantly improved or neutral.
> 
> ## 1. Benchmark script
> 
> # baseline
> git checkout 74066bcca82749722e6fee57469520d418bf3430
> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
> 
> # current
> git checkout c02d2306935d99685e34ef960aa72e10feb82a39
> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
> 
> 
> ## 2. Performance numbers
> 
> ### 2.1 Mac Book M1 Pro
> 
> -# baseline
> -Benchmark                                                         (descString)  Mode  Cnt     Score     Error  Units
> -MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   104.154 ?   2.636  ns/op
> -MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.843 ?   0.014  ns/op
> -MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   221.013 ?  81.200  ns/op
> -MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.603 ?   0.026  ns/op
> -MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   221.404 ? 189.754  ns/op
> -MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1128.418 ?  16.850  ns/op
> 
> +# current
> +Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
> +MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    53.900 ?  0.061  ns/op
> +MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.609 ?  0.017  ns/op
> +MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    69.666 ?  0.596  ns/op
> +MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.978 ?  0.197  ns/op
> +MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   126.968 ?  0.715  ns/op
> +MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1651.624 ? 30.462  ns/op
> 
> 
> | descString | baseline  | current | delta |
> | --- | --- | --- | --- |
> | (Ljava/lang/Object;Ljava/lang/String;)I | 104.154 | 53.900 | 93.24% |
> | ()V | 3.843 | 3.609 | 6.48% |
> | ([IJLjava/lang/String;Z)Ljava/util/List; ...

@wenshao Do you think we should resort back to allocating an `ArrayList` if our long cannot encode the descriptor's offset info? I think you can add a case of 10 args like `([III.Z[B..[.[B)` and see if your patch improves over the baseline. You can add this case to `MethodTypeDescFactories` too.

<details>
<summary>
Only look at this if your approach is still slower than ArrayList allocation in my given simpler case.
</summary>
My proposal for `paramTypes` is like:

 - Fast return if empty
 - Fast loop to fill up `lengths`
   - Break if we encounter the 9th params or a long field descriptor
 - At break, if `cur == len`, means fast path works, we go through fast path
 - Else, we fall back to the old path of using `ArrayList`; add elements collected in `lengths` and the element between the last of `lengths` and cur (so it's either 9th element or too long)

This approach completely avoids a 2nd scan.
</details>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295038272

From duke at openjdk.org  Mon Aug 19 06:32:23 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:23 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <LAEZf-NxbbY45PgQMu8GfZmdcXZXAkTt5HHo2jdGF48=.4abe80fd-ef7c-43e6-91da-5d0b29fbca58@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
 <LAEZf-NxbbY45PgQMu8GfZmdcXZXAkTt5HHo2jdGF48=.4abe80fd-ef7c-43e6-91da-5d0b29fbca58@github.com>
Message-ID: <-1c4GQ2ubJ8Bb5XMDUKzJNo47Ks0VUutzvggGPWzA-M=.9cbd0328-1dac-4b72-9e28-5785b12d2281@github.com>

On Sun, 18 Aug 2024 00:15:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The following are the performance numbers on multiple platforms. When the number of parameters is > 8, the performance will regress by about 33%. When the number of parameters is <= 8, the performance will be significantly improved or neutral.
>> 
>> ## 1. Benchmark script
>> 
>> # baseline
>> git checkout 74066bcca82749722e6fee57469520d418bf3430
>> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
>> 
>> # current
>> git checkout c02d2306935d99685e34ef960aa72e10feb82a39
>> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
>> 
>> 
>> ## 2. Performance numbers
>> 
>> ### 2.1 Mac Book M1 Pro
>> 
>> -# baseline
>> -Benchmark                                                         (descString)  Mode  Cnt     Score     Error  Units
>> -MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   104.154 ?   2.636  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.843 ?   0.014  ns/op
>> -MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   221.013 ?  81.200  ns/op
>> -MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.603 ?   0.026  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   221.404 ? 189.754  ns/op
>> -MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1128.418 ?  16.850  ns/op
>> 
>> +# current
>> +Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
>> +MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    53.900 ?  0.061  ns/op
>> +MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.609 ?  0.017  ns/op
>> +MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    69.666 ?  0.596  ns/op
>> +MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.978 ?  0.197  ns/op
>> +MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   126.968 ?  0.715  ns/op
>> +MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1651.624 ? 30.462  ns/op
>> 
>> 
>> | descString | baseline  | current | delta |
>> | --- | --- | --- | --- |
>> | (Ljava/lang/Object;Ljava/lang/String;)I | 104.154 | 53.900 | 93.24%...
>
> @wenshao Do you think we should resort back to allocating an `ArrayList` if our long cannot encode the descriptor's offset info? I think you can add a case of 10 args like `([III.Z[B..[.[B)` and see if your patch improves over the baseline. You can add this case to `MethodTypeDescFactories` too.
> 
> <details>
> <summary>
> Only look at this if your approach is still slower than ArrayList allocation in my given simpler case.
> </summary>
> My proposal for `paramTypes` is like:
> 
>  - Fast return if empty
>  - Fast loop to fill up `lengths`
>    - Break if we encounter the 9th params or a long field descriptor
>  - At break, if `cur == len`, means fast path works, we go through fast path
>  - Else, we fall back to the old path of using `ArrayList`; add elements collected in `lengths` and the element between the last of `lengths` and cur (so it's either 9th element or too long)
> 
> This approach completely avoids a 2nd scan.
> </details>

According to @liach s suggestion, the performance has improved in scenarios where the number of parameters is greater than 8.

## 1. Benchmark script

git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

# baseline
git checkout 1e17a42eda73bc5138e05502a004a8c293a93eb8
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# current
git checkout c4fe4a1bf0895661c5d3f2d8cef06760e5605ec9
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## 2. Performance numbers

### 2.1 Mac Book M1 Pro

-# baseline
-Benchmark                                                         (descString)  Mode  Cnt     Score     Error  Units
-MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    98.402 ?   5.075  ns/op
-MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.884 ?   0.094  ns/op
-MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   222.884 ?  42.684  ns/op
-MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    25.398 ?   0.154  ns/op
-MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   232.646 ? 153.202  ns/op
-MethodTypeDescFactories.ofDescriptor                         ([III.Z[B..[.[B).  avgt    6   338.739 ?   0.784  ns/op
-MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1105.693 ?   2.729  ns/op

+# current
+Benchmark                                                         (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    55.584 ?  0.254  ns/op
+MethodTypeDescFactories.ofDescriptor                                       ()V  avgt    6     3.596 ?  0.014  ns/op
+MethodTypeDescFactories.ofDescriptor  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    68.550 ?  0.658  ns/op
+MethodTypeDescFactories.ofDescriptor                     ()[Ljava/lang/String;  avgt    6    20.974 ?  0.191  ns/op
+MethodTypeDescFactories.ofDescriptor                                  (..IIJ)V  avgt    6   120.125 ?  0.983  ns/op
+MethodTypeDescFactories.ofDescriptor                         ([III.Z[B..[.[B).  avgt    6   373.592 ? 16.552  ns/op
+MethodTypeDescFactories.ofDescriptor                  (.....................).  avgt    6  1166.071 ?  4.203  ns/op


| descString | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 98.402 | 55.584 | 77.03% |
| ()V | 3.884 | 3.596 | 8.01% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 222.884 | 68.550 | 225.14% |
| ()[Ljava/lang/String; | 25.398 | 20.974 | 21.09% |
| (..IIJ)V | 232.646 | 120.125 | 93.67% |
| ([III.Z[B..[.[B). | 338.739 | 373.592 | -9.33% |
| (.....................). | 1105.693 | 1166.071 | -5.18% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295120437

From liach at openjdk.org  Mon Aug 19 06:32:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>

On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

Also note on ofDescriptor's use at bootstrap: This can be completely avoided as there should be no need for this method.

I think I have diagnosed the cause of such calls: one is here https://github.com/liachmodded/jdk/commit/64fd147bddd085fa3caa437a2b25a3dda3bb517a, and there are a few others in `SwitchBootstraps`. I need to check if there are still any other bootstrap usages after these are eliminated.

https://github.com/wenshao/jdk/pull/10
Sent a patch to allow fast parsing of 1 more parameter

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 296:

> 294:         // objectDesc appears a lot during the bootstrap process, so optimize it
> 295:         String objectDesc = "Ljava/lang/Object;";
> 296:         if (len == objectDesc.length() && descriptor.regionMatches(start, objectDesc, 0, len)) {

Note that from my bytestack investigations, `regionMatches` can be CPU-intensive like hashCode calculation. Running this trick against `Ljava/lang/String;` (same length) might cause a lot of misses and waste a lot of CPU time. Can you try on a case with many `Ljava/lang/String;` descriptors and see the results compared to the build without this special case?

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 304:

> 302:             throw new IllegalArgumentException("Bad method descriptor: " + descriptor);
> 303:         ptypes.set(0, resolveClassDesc(descriptor, cur, rLen));
> 304:         return ptypes;

You can remove `parseMethodDescriptor` now

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 108:

> 106:      */
> 107:     public static MethodTypeDescImpl ofDescriptor(String descriptor) {
> 108:         int rightBracket = descriptor.indexOf(')');

Would `lastIndexOf` be better for general purposes, since there's just one descriptor to the right?

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 111:

> 109:         int len = descriptor.length() - rightBracket - 1;
> 110:         if (rightBracket <= 0 || descriptor.charAt(0) != '(' || len == 0
> 111:                 || len != ConstantUtils.skipOverFieldSignature(descriptor, rightBracket + 1, descriptor.length(), true)

I think this is the only place we still need this `true`; inlining the `V` return type check here (should be simple, we just need to check `len == 1 && descriptor.charAt(rightBracket + 1) == 'V'` and rejecting `V` in `skipOverFieldSignature`) might (or might not) help C2 inlining.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 113:

> 111:                 || (rightBracket = (descriptor.charAt(1) == ')' ? 1 : descriptor.lastIndexOf(')'))) <= 0
> 112:                 || (len = descriptor.length() - rightBracket - 1) == 0
> 113:                 || (len != 1 && len != ConstantUtils.skipOverFieldSignature(descriptor, rightBracket + 1, descriptor.length()))

Has this be tested against input values like `()A`? I would prefer to fail explicitly with `descriptor.charAt(rightBracket + 1) == 'V'` instead of using `len != 1` and relying on `Wrapper.forBasicType`.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 125:

> 123:         int paramCount = 0;
> 124:         for (int cur = start; cur < end; ) {
> 125:             int len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end, false);

I recall skipping over signatures is the main reason descriptor parsing is slow. What is the benchmark result if you allocate a buffer array like `short[] offsets = new short[Math.min(end - start, 255)]` or a `BitSet offsets = new BitSet(end - start)`?

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 145:

> 143:     }
> 144: 
> 145:     private static void badMethodDescriptor(String descriptor) {

We usually make such utilities return an exception that we can throw in control flow; this trick is that otherwise, compiler will still ask for a return value after this `badMethodDescriptor` call which can be annoying sometimes.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 158:

> 156:             }
> 157:             if (len == 0) {
> 158:                 len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end);

This can use a simpler version of skip that doesn't validate, like:

int start = cur;
while (descriptor.charAt(cur) == '[') {
    cur++;
}
if (descriptor.charAt(cur++) == 'L') {
    cur = descriptor.indexOf(';', cur) + 1;
}
paramTypes[paramIndex++] = ConstantUtils.resolveClassDesc(descriptor, start, cur - start);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295266083
PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2295529521
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721097556
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719841359
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719838312
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719842641
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720768235
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719836907
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1719849066
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720767719

From liach at openjdk.org  Mon Aug 19 06:32:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
Message-ID: <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>

On Mon, 19 Aug 2024 00:20:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 296:
> 
>> 294:         // objectDesc appears a lot during the bootstrap process, so optimize it
>> 295:         String objectDesc = "Ljava/lang/Object;";
>> 296:         if (len == objectDesc.length() && descriptor.regionMatches(start, objectDesc, 0, len)) {
> 
> Note that from my bytestack investigations, `regionMatches` can be CPU-intensive like hashCode calculation. Running this trick against `Ljava/lang/String;` (same length) might cause a lot of misses and waste a lot of CPU time. Can you try on a case with many `Ljava/lang/String;` descriptors and see the results compared to the build without this special case?

Also `Double` `Module` `Number` `Record` `Thread` `System` are susceptible to taking more time in `regionMatches`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721104536

From liach at openjdk.org  Mon Aug 19 06:32:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>
Message-ID: <qI_HBCpWcm8pYwAwp9Q65mm6Sh3fsA0gHkvhyixwVjI=.6c5b5fb5-fd35-4938-b5aa-6a132d0008dc@github.com>

On Mon, 19 Aug 2024 00:46:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 296:
>> 
>>> 294:         // objectDesc appears a lot during the bootstrap process, so optimize it
>>> 295:         String objectDesc = "Ljava/lang/Object;";
>>> 296:         if (len == objectDesc.length() && descriptor.regionMatches(start, objectDesc, 0, len)) {
>> 
>> Note that from my bytestack investigations, `regionMatches` can be CPU-intensive like hashCode calculation. Running this trick against `Ljava/lang/String;` (same length) might cause a lot of misses and waste a lot of CPU time. Can you try on a case with many `Ljava/lang/String;` descriptors and see the results compared to the build without this special case?
>
> Also `Double` `Module` `Number` `Record` `Thread` `System` are susceptible to taking more time in `regionMatches`.

I think you can have the current patch RFR (ready for review) without this deduplication given my concerns. We can add deduplication of frequent descriptors in another patch after confirming it is a net positive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721132965

From duke at openjdk.org  Mon Aug 19 06:32:24 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
Message-ID: <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>

On Sun, 18 Aug 2024 21:27:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 309:
> 
>> 307:     private static ClassDesc resolveClassDesc(String descriptor, int start, int len) {
>> 308:         if (len == 1) {
>> 309:             return Wrapper.forPrimitiveType(descriptor.charAt(start)).basicClassDescriptor();
> 
> This was already piggy-backing on a quite fast routine. If it's a clean, significant win then I'm fine with this (untangling `Wrapper` from this is probably good, all things considered), but then we should also clean up `Wrapper` to not carry some descriptors around.

I have removed the Wrapper.forPrimitiveType(char) method. It seems that this is the only method that can be removed. Other descriptors related methods still need to be used.

> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 137:
> 
>> 135:         var returnType = resolveClassDesc(descriptor, rightBracket + 1, retTypeLength);
>> 136:         if (length == 3 && returnType == CD_void) {
>> 137:             return Constants.MTD_void;
> 
> Feels a bit like overfitting with quite limited data.
> 
> Could this use `ConstantDescs.MTD_void` instead or does that cause a bootstrap cycle?

Using ConstantDescs.MTD_void can also solve the bootstrap cycle, good idea, I have fixed it

> test/micro/org/openjdk/bench/java/lang/classfile/MethodTypeDescBench.java line 23:
> 
>> 21:  * questions.
>> 22:  */
>> 23: package org.openjdk.bench.java.lang.classfile;
> 
> Wrong package as the code being tested is in java.lang.constant. Also there is already a related microbenchmark in org.openjdk.bench.java.lang.constant.MethodTypeDescFactories - can you check if that covers your needs?

MethodTypeDescFactories has some illegal MethodTypeDesc, and throwing exceptions will affect the performance comparison of normal scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721080326
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721064527
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720100307

From duke at openjdk.org  Mon Aug 19 06:32:24 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <qI_HBCpWcm8pYwAwp9Q65mm6Sh3fsA0gHkvhyixwVjI=.6c5b5fb5-fd35-4938-b5aa-6a132d0008dc@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>
 <qI_HBCpWcm8pYwAwp9Q65mm6Sh3fsA0gHkvhyixwVjI=.6c5b5fb5-fd35-4938-b5aa-6a132d0008dc@github.com>
Message-ID: <KEfapxZvWVquZu_sbBvh9EDqrF4cku-tZBNBz44ZTXo=.729da33b-3c9c-4ae2-a8c0-b85db2321d62@github.com>

On Mon, 19 Aug 2024 02:04:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also `Double` `Module` `Number` `Record` `Thread` `System` are susceptible to taking more time in `regionMatches`.
>
> I think you can have the current patch RFR (ready for review) without this deduplication given my concerns. We can add deduplication of frequent descriptors in another patch after confirming it is a net positive.

regionMatches uses vectorizedMismatch for comparison. The length of `Ljava/lang/Object;` is 18. In the code without intrinsic, it will exit after two long comparisons. If there is vector128 optimization, it will exit after one comparison, and the overhead is very small.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721192307

From duke at openjdk.org  Mon Aug 19 06:32:24 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
Message-ID: <-iutmbe2G6-okhfdX9wVzmD1_Orso-_jwhBmpUzYGEM=.6f7e50dd-303c-4c49-b6a3-adcd46ca09c9@github.com>

On Sat, 17 Aug 2024 12:16:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 113:
> 
>> 111:                 || (rightBracket = (descriptor.charAt(1) == ')' ? 1 : descriptor.lastIndexOf(')'))) <= 0
>> 112:                 || (len = descriptor.length() - rightBracket - 1) == 0
>> 113:                 || (len != 1 && len != ConstantUtils.skipOverFieldSignature(descriptor, rightBracket + 1, descriptor.length()))
> 
> Has this be tested against input values like `()A`? I would prefer to fail explicitly with `descriptor.charAt(rightBracket + 1) == 'V'` instead of using `len != 1` and relying on `Wrapper.forBasicType`.

I have tested that `()A` will report an error. If length == 1, rely on Wrapper.forBasicType to detect illegal input.

> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 125:
> 
>> 123:         int paramCount = 0;
>> 124:         for (int cur = start; cur < end; ) {
>> 125:             int len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end, false);
> 
> I recall skipping over signatures is the main reason descriptor parsing is slow. What is the benchmark result if you allocate a buffer array like `short[] offsets = new short[Math.min(end - start, 255)]` or a `BitSet offsets = new BitSet(end - start)`?

Allocating a buffer will slow down, so I used a long, with each 8 bits storing a parameter length, which can improve performance when the number of parameters is <= 8.

> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 158:
> 
>> 156:             }
>> 157:             if (len == 0) {
>> 158:                 len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end);
> 
> This can use a simpler version of skip that doesn't validate, like:
> 
> int start = cur;
> while (descriptor.charAt(cur) == '[') {
>     cur++;
> }
> if (descriptor.charAt(cur++) == 'L') {
>     cur = descriptor.indexOf(';', cur) + 1;
> }
> paramTypes[paramIndex++] = ConstantUtils.resolveClassDesc(descriptor, start, cur - start);

Now this version merges the loops, your suggestion doesn't handle paramIndex >= 8, and it won't be faster, the current version of skipOverFieldSignature performs well enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720769514
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720452515
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720768233

From liach at openjdk.org  Mon Aug 19 06:32:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:24 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <KEfapxZvWVquZu_sbBvh9EDqrF4cku-tZBNBz44ZTXo=.729da33b-3c9c-4ae2-a8c0-b85db2321d62@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>
 <qI_HBCpWcm8pYwAwp9Q65mm6Sh3fsA0gHkvhyixwVjI=.6c5b5fb5-fd35-4938-b5aa-6a132d0008dc@github.com>
 <KEfapxZvWVquZu_sbBvh9EDqrF4cku-tZBNBz44ZTXo=.729da33b-3c9c-4ae2-a8c0-b85db2321d62@github.com>
Message-ID: <nKDMQZ9zbmrqCGhim9NWeLAty4xAXYIIrnQ-VCdu3vk=.02d3e5ef-4aa8-400d-ba0f-8c1c41a37b84@github.com>

On Mon, 19 Aug 2024 04:12:56 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> I think you can have the current patch RFR (ready for review) without this deduplication given my concerns. We can add deduplication of frequent descriptors in another patch after confirming it is a net positive.
>
> regionMatches uses vectorizedMismatch for comparison. The length of `Ljava/lang/Object;` is 18. In the code without intrinsic, it will exit after two long comparisons. If there is vector128 optimization, it will exit after one comparison, and the overhead is very small.

I think you can add a case where the parameters are all these vulnerable names like `Ljava/lang/Objecq;` and repeat 8 times, and see how big a negative impact these close mismatches have.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721217799

From liach at openjdk.org  Mon Aug 19 06:32:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <-iutmbe2G6-okhfdX9wVzmD1_Orso-_jwhBmpUzYGEM=.6f7e50dd-303c-4c49-b6a3-adcd46ca09c9@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <-iutmbe2G6-okhfdX9wVzmD1_Orso-_jwhBmpUzYGEM=.6f7e50dd-303c-4c49-b6a3-adcd46ca09c9@github.com>
Message-ID: <Y4uDE6WG27j2idAjhwQRS6QoGMlvteJMDcvXKDDMBX8=.4ba63e62-3cfe-43a2-853a-3ed7359160a1@github.com>

On Sat, 17 Aug 2024 12:25:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 113:
>> 
>>> 111:                 || (rightBracket = (descriptor.charAt(1) == ')' ? 1 : descriptor.lastIndexOf(')'))) <= 0
>>> 112:                 || (len = descriptor.length() - rightBracket - 1) == 0
>>> 113:                 || (len != 1 && len != ConstantUtils.skipOverFieldSignature(descriptor, rightBracket + 1, descriptor.length()))
>> 
>> Has this be tested against input values like `()A`? I would prefer to fail explicitly with `descriptor.charAt(rightBracket + 1) == 'V'` instead of using `len != 1` and relying on `Wrapper.forBasicType`.
>
> I have tested that `()A` will report an error. If length == 1, rely on Wrapper.forBasicType to detect illegal input.

We just exposed an internal exception behavior to public. Might add in wrapper.forBasicType that this IAE is part of public API.

>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 158:
>> 
>>> 156:             }
>>> 157:             if (len == 0) {
>>> 158:                 len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end);
>> 
>> This can use a simpler version of skip that doesn't validate, like:
>> 
>> int start = cur;
>> while (descriptor.charAt(cur) == '[') {
>>     cur++;
>> }
>> if (descriptor.charAt(cur++) == 'L') {
>>     cur = descriptor.indexOf(';', cur) + 1;
>> }
>> paramTypes[paramIndex++] = ConstantUtils.resolveClassDesc(descriptor, start, cur - start);
>
> Now this version merges the loops, your suggestion doesn't handle paramIndex >= 8, and it won't be faster, the current version of skipOverFieldSignature performs well enough.

Hmm? I mean this block can be a new method (the cur pointer moving part) and replace existing skipOver call that does extra validation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720770934
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720771392

From duke at openjdk.org  Mon Aug 19 06:32:25 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <Y4uDE6WG27j2idAjhwQRS6QoGMlvteJMDcvXKDDMBX8=.4ba63e62-3cfe-43a2-853a-3ed7359160a1@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <-iutmbe2G6-okhfdX9wVzmD1_Orso-_jwhBmpUzYGEM=.6f7e50dd-303c-4c49-b6a3-adcd46ca09c9@github.com>
 <Y4uDE6WG27j2idAjhwQRS6QoGMlvteJMDcvXKDDMBX8=.4ba63e62-3cfe-43a2-853a-3ed7359160a1@github.com>
Message-ID: <COCV91JUN955Irws46soYcZK1PNx4YLrKjUy8aHIlnw=.b1b1ca88-c23a-440b-9a4c-86b06427529b@github.com>

On Sat, 17 Aug 2024 12:38:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I have tested that `()A` will report an error. If length == 1, rely on Wrapper.forBasicType to detect illegal input.
>
> We just exposed an internal exception behavior to public. Might add in wrapper.forBasicType that this IAE is part of public API.

I've added a return type check for length == 1, and now the error behavior is the same as before.

>> Now this version merges the loops, your suggestion doesn't handle paramIndex >= 8, and it won't be faster, the current version of skipOverFieldSignature performs well enough.
>
> Hmm? I mean this block can be a new method (the cur pointer moving part) and replace existing skipOver call that does extra validation

I refactored the skipOverFieldSignature method and used the structure you mentioned above, so that the code is more concise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720776618
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720789009

From redestad at openjdk.org  Mon Aug 19 06:32:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <-iutmbe2G6-okhfdX9wVzmD1_Orso-_jwhBmpUzYGEM=.6f7e50dd-303c-4c49-b6a3-adcd46ca09c9@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <-iutmbe2G6-okhfdX9wVzmD1_Orso-_jwhBmpUzYGEM=.6f7e50dd-303c-4c49-b6a3-adcd46ca09c9@github.com>
Message-ID: <zuPvd6w7lvL7Sy7TTcdLto4TN-FlAKK40oEZrKrvdnc=.35befef7-648f-4f53-832b-0878f517a098@github.com>

On Fri, 16 Aug 2024 23:16:46 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 125:
>> 
>>> 123:         int paramCount = 0;
>>> 124:         for (int cur = start; cur < end; ) {
>>> 125:             int len = ConstantUtils.skipOverFieldSignature(descriptor, cur, end, false);
>> 
>> I recall skipping over signatures is the main reason descriptor parsing is slow. What is the benchmark result if you allocate a buffer array like `short[] offsets = new short[Math.min(end - start, 255)]` or a `BitSet offsets = new BitSet(end - start)`?
>
> Allocating a buffer will slow down, so I used a long, with each 8 bits storing a parameter length, which can improve performance when the number of parameters is <= 8.

Since we can't have empty descriptors (`len == 0`) you could leave a 0 in the bits to signify that the parameter is too large to fit and then re-parse it in the subsequent loop below. Might simplify the control flow a bit (no need for `largeParm`, maybe possible to merge the 2nd and 3rd loops)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720489188

From duke at openjdk.org  Mon Aug 19 06:32:25 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
Message-ID: <PJ7I5T2ag7fYDj7gA-LinoCYJrmW0b4fm7f0vuUxTYk=.3690845f-0132-4aad-9d4b-fc33a74e4e60@github.com>

On Sun, 18 Aug 2024 21:32:46 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 137:
>> 
>>> 135:         var returnType = resolveClassDesc(descriptor, rightBracket + 1, retTypeLength);
>>> 136:         if (length == 3 && returnType == CD_void) {
>>> 137:             return Constants.MTD_void;
>> 
>> Feels a bit like overfitting with quite limited data.
>> 
>> Could this use `ConstantDescs.MTD_void` instead or does that cause a bootstrap cycle?
>
> Using ConstantDescs.MTD_void can also solve the bootstrap cycle, good idea, I have fixed it

I think it is worthwhile to optimize the bootstrap scenario with less cost for other scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721065312

From redestad at openjdk.org  Mon Aug 19 06:32:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <PJ7I5T2ag7fYDj7gA-LinoCYJrmW0b4fm7f0vuUxTYk=.3690845f-0132-4aad-9d4b-fc33a74e4e60@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
 <PJ7I5T2ag7fYDj7gA-LinoCYJrmW0b4fm7f0vuUxTYk=.3690845f-0132-4aad-9d4b-fc33a74e4e60@github.com>
Message-ID: <uB2MEYC735AYqYx0HsE18fNDPjkoBmgd8JATW2OS2Nw=.96a52de0-57cd-43e3-aa24-cea12f7edd5e@github.com>

On Sun, 18 Aug 2024 21:36:07 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Using ConstantDescs.MTD_void can also solve the bootstrap cycle, good idea, I have fixed it
>
> I think it is worthwhile to optimize the bootstrap scenario with less cost for other scenarios.

Right, which is why we need to balance these microbenchmark speed-ups against any added static footprint and other factors. Going through fewer but less specialized methods can reduce runtime footprint and lead to quicker warmup, for example. Also, @liach pointed out elsewhere the we might be able to avoid many of these `ofDescriptor` calls with optimizations elsewhere, so perhaps let's not go overboard here and re-measure with those optimizations in place as it might make this work less impactful.

On a related note: Running micros with `-Xint` and `-XX:TieredStopAtLevel=1` can help indicate whether some optimization will be helpful during startup or not. Often things align well, but sometimes optimizations that help peak performance make interpreted performance worse, and vice versa. 

If we're optimizing for startup the best is obviously to check on some startup benchmark of choice. A recent example (on Linux): `perf stat -r 50 java -jar benchmarks.jar org.openjdk.bench.java.lang.StringConcatStartup` or simply `make test TEST=micro:StringConcatStartup` 

FWIW I use this technique all the time to diagnose what we're doing during startup: https://cl4es.github.io/2018/11/23/Investigating-Startup-Using-Bytestacks.html - it has helped me find numerous candidates for startup optimization. Main reason I'm insisting on adding a main method to startup-centric JMH benchmarks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721077436

From duke at openjdk.org  Mon Aug 19 06:32:25 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <uB2MEYC735AYqYx0HsE18fNDPjkoBmgd8JATW2OS2Nw=.96a52de0-57cd-43e3-aa24-cea12f7edd5e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
 <PJ7I5T2ag7fYDj7gA-LinoCYJrmW0b4fm7f0vuUxTYk=.3690845f-0132-4aad-9d4b-fc33a74e4e60@github.com>
 <uB2MEYC735AYqYx0HsE18fNDPjkoBmgd8JATW2OS2Nw=.96a52de0-57cd-43e3-aa24-cea12f7edd5e@github.com>
Message-ID: <mNWtyoSjRH0CMZctnX24Q-2-8Im9r4JrB12pXphv0LU=.efe345ba-890a-4877-aeb5-04cac4f3196a@github.com>

On Sun, 18 Aug 2024 22:33:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I think it is worthwhile to optimize the bootstrap scenario with less cost for other scenarios.
>
> Right, which is why we need to balance these microbenchmark speed-ups against any added static footprint and other factors. Going through fewer but less specialized methods can reduce runtime footprint and lead to quicker warmup, for example. Also, @liach pointed out elsewhere the we might be able to avoid many of these `ofDescriptor` calls with optimizations elsewhere, so perhaps let's not go overboard here and re-measure with those optimizations in place as it might make this work less impactful.
> 
> On a related note: Running micros with `-Xint` and `-XX:TieredStopAtLevel=1` can help indicate whether some optimization will be helpful during startup or not. Often things align well, but sometimes optimizations that help peak performance make interpreted performance worse, and vice versa. 
> 
> If we're optimizing for startup the best is obviously to check on some startup benchmark of choice. A recent example (on Linux): `perf stat -r 50 java -jar benchmarks.jar org.openjdk.bench.java.lang.StringConcatStartup` or simply `make test TEST=micro:StringConcatStartup` 
> 
> FWIW I use this technique all the time to diagnose what we're doing during startup: https://cl4es.github.io/2018/11/23/Investigating-Startup-Using-Bytestacks.html - it has helped me find numerous candidates for startup optimization. Main reason I'm insisting on adding a main method to startup-centric JMH benchmarks.

All calls to ofDescriptor during the startup process come from here, which cannot be avoided in a simple way.


	at java.base/jdk.internal.constant.MethodTypeDescImpl.ofDescriptor(MethodTypeDescImpl.java:142)
	at java.base/java.lang.constant.MethodTypeDesc.ofDescriptor(MethodTypeDesc.java:60)
	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.methodTypeSymbol(DirectMethodBuilder.java:88)
	at java.base/jdk.internal.classfile.impl.TerminalCodeBuilder.setupTopLocal(TerminalCodeBuilder.java:36)
	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.<init>(DirectCodeBuilder.java:133)
	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.build(DirectCodeBuilder.java:106)
	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:123)
	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:130)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:589)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:567)
	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.run(DirectMethodBuilder.java:144)
	at java.base/jdk.internal.classfile.impl.DirectClassBuilder.withMethod(DirectClassBuilder.java:106)
	at java.base/java.lang.classfile.ClassBuilder.withMethod(ClassBuilder.java:260)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator.methodSetup(InvokerBytecodeGenerator.java:292)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator.addMethod(InvokerBytecodeGenerator.java:567)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:558)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:555)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:282)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:276)
	at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113)
	at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator.classFileSetup(InvokerBytecodeGenerator.java:276)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes(InvokerBytecodeGenerator.java:555)
	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:533)
	at java.base/java.lang.invoke.LambdaForm.compileToBytecode(LambdaForm.java:845)
	at java.base/java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(DirectMethodHandle.java:302)
	at java.base/java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:230)
	at java.base/java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:215)
	at java.base/java.lang.invoke.DirectMethodHandle.preparedLambdaForm(DirectMethodHandle.java:224)
	at java.base/java.lang.invoke.DirectMethodHandle.make(DirectMethodHandle.java:106)
	at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:4109)
	at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(MethodHandles.java:4065)
	at java.base/java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(MethodHandles.java:4314)
	at java.base/java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:4262)
	at java.base/java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:628)
	at java.base/jdk.internal.module.SystemModuleFinders$1.find(SystemModuleFinders.java:216)
	at java.base/jdk.internal.module.ModuleBootstrap.boot2(ModuleBootstrap.java:260)
	at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:173)
	at java.base/java.lang.System.initPhase2(System.java:2312)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721082199

From redestad at openjdk.org  Mon Aug 19 06:32:25 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <mNWtyoSjRH0CMZctnX24Q-2-8Im9r4JrB12pXphv0LU=.efe345ba-890a-4877-aeb5-04cac4f3196a@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
 <PJ7I5T2ag7fYDj7gA-LinoCYJrmW0b4fm7f0vuUxTYk=.3690845f-0132-4aad-9d4b-fc33a74e4e60@github.com>
 <uB2MEYC735AYqYx0HsE18fNDPjkoBmgd8JATW2OS2Nw=.96a52de0-57cd-43e3-aa24-cea12f7edd5e@github.com>
 <mNWtyoSjRH0CMZctnX24Q-2-8Im9r4JrB12pXphv0LU=.efe345ba-890a-4877-aeb5-04cac4f3196a@github.com>
Message-ID: <9Zni_BgwGoJ82697AtAVl49BQ2akapNGYrOB4piNKE4=.246f419a-abf8-4dc9-9fd9-f5595ff18077@github.com>

On Sun, 18 Aug 2024 23:04:33 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Right, which is why we need to balance these microbenchmark speed-ups against any added static footprint and other factors. Going through fewer but less specialized methods can reduce runtime footprint and lead to quicker warmup, for example. Also, @liach pointed out elsewhere the we might be able to avoid many of these `ofDescriptor` calls with optimizations elsewhere, so perhaps let's not go overboard here and re-measure with those optimizations in place as it might make this work less impactful.
>> 
>> On a related note: Running micros with `-Xint` and `-XX:TieredStopAtLevel=1` can help indicate whether some optimization will be helpful during startup or not. Often things align well, but sometimes optimizations that help peak performance make interpreted performance worse, and vice versa. 
>> 
>> If we're optimizing for startup the best is obviously to check on some startup benchmark of choice. A recent example (on Linux): `perf stat -r 50 java -jar benchmarks.jar org.openjdk.bench.java.lang.StringConcatStartup` or simply `make test TEST=micro:StringConcatStartup` 
>> 
>> FWIW I use this technique all the time to diagnose what we're doing during startup: https://cl4es.github.io/2018/11/23/Investigating-Startup-Using-Bytestacks.html - it has helped me find numerous candidates for startup optimization. Main reason I'm insisting on adding a main method to startup-centric JMH benchmarks.
>
> All calls to ofDescriptor during the startup process come from here, which cannot be avoided in a simple way.
> 
> 
> 	at java.base/jdk.internal.constant.MethodTypeDescImpl.ofDescriptor(MethodTypeDescImpl.java:142)
> 	at java.base/java.lang.constant.MethodTypeDesc.ofDescriptor(MethodTypeDesc.java:60)
> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.methodTypeSymbol(DirectMethodBuilder.java:88)
> 	at java.base/jdk.internal.classfile.impl.TerminalCodeBuilder.setupTopLocal(TerminalCodeBuilder.java:36)
> 	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.<init>(DirectCodeBuilder.java:133)
> 	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.build(DirectCodeBuilder.java:106)
> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:123)
> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:130)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:589)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:567)
> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.run(DirectMethodBuilder.java:144)
> 	at java.base/jdk.internal.classfile.impl.DirectClassBuilder.withMethod(DirectClassBuilder.java:106)
> 	at java.base/java.lang.classfile.ClassBuilder.withMethod(ClassBuilder.java:260)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.methodSetup(InvokerBytecodeGenerator.java:292)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.addMethod(InvokerBytecodeGenerator.java:567)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:558)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:555)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:282)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:276)
> 	at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113)
> 	at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.classFileSetup(InvokerBytecodeGenerator.java:276)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes(InvokerBytecodeGenerator.java:555)
> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(InvokerBytecodeGenerator.java:533)
> 	at java.base/java.lang.i...

Hmm, based on your stacktrace I think you are running the exploded image in `build/<arch>/jdk` instead of from a final image, e.g. the one that `make jdk-image` produces in `build/<arch>/images/jdk` - the former will do a lot more stuff during startup, while the latter applies numerous link-time optimizations to reduce lambda and method handle spinning on startup. While speeding up the exploded image is a nice bonus, the runtime images should be the focus of startup optimization work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721090415

From liach at openjdk.org  Mon Aug 19 06:32:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 06:32:25 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <9Zni_BgwGoJ82697AtAVl49BQ2akapNGYrOB4piNKE4=.246f419a-abf8-4dc9-9fd9-f5595ff18077@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
 <PJ7I5T2ag7fYDj7gA-LinoCYJrmW0b4fm7f0vuUxTYk=.3690845f-0132-4aad-9d4b-fc33a74e4e60@github.com>
 <uB2MEYC735AYqYx0HsE18fNDPjkoBmgd8JATW2OS2Nw=.96a52de0-57cd-43e3-aa24-cea12f7edd5e@github.com>
 <mNWtyoSjRH0CMZctnX24Q-2-8Im9r4JrB12pXphv0LU=.efe345ba-890a-4877-aeb5-04cac4f3196a@github.com>
 <9Zni_BgwGoJ82697AtAVl49BQ2akapNGYrOB4piNKE4=.246f419a-abf8-4dc9-9fd9-f5595ff18077@github.com>
Message-ID: <d0Wku38GfYhBzxYeLNr4ICwTo6iGFDTi3brPeFr_lLY=.72d226b9-24a6-4397-b67b-c30e1bf50497@github.com>

On Sun, 18 Aug 2024 23:48:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> All calls to ofDescriptor during the startup process come from here, which cannot be avoided in a simple way.
>> 
>> 
>> 	at java.base/jdk.internal.constant.MethodTypeDescImpl.ofDescriptor(MethodTypeDescImpl.java:142)
>> 	at java.base/java.lang.constant.MethodTypeDesc.ofDescriptor(MethodTypeDesc.java:60)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.methodTypeSymbol(DirectMethodBuilder.java:88)
>> 	at java.base/jdk.internal.classfile.impl.TerminalCodeBuilder.setupTopLocal(TerminalCodeBuilder.java:36)
>> 	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.<init>(DirectCodeBuilder.java:133)
>> 	at java.base/jdk.internal.classfile.impl.DirectCodeBuilder.build(DirectCodeBuilder.java:106)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:123)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.withCode(DirectMethodBuilder.java:130)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:589)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$5.accept(InvokerBytecodeGenerator.java:567)
>> 	at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.run(DirectMethodBuilder.java:144)
>> 	at java.base/jdk.internal.classfile.impl.DirectClassBuilder.withMethod(DirectClassBuilder.java:106)
>> 	at java.base/java.lang.classfile.ClassBuilder.withMethod(ClassBuilder.java:260)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.methodSetup(InvokerBytecodeGenerator.java:292)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.addMethod(InvokerBytecodeGenerator.java:567)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:558)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$4.accept(InvokerBytecodeGenerator.java:555)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:282)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator$2.accept(InvokerBytecodeGenerator.java:276)
>> 	at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:113)
>> 	at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:332)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.classFileSetup(InvokerBytecodeGenerator.java:276)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCodeBytes(InvokerBytecodeGenerator.java:555)
>> 	at java.base/java.lang.invoke.InvokerBytecodeGenerator.generateCustomizedCode(Invoke...
>
> Hmm, based on your stacktrace I think you are running the exploded image in `build/<arch>/jdk` instead of from a final image, e.g. the one that `make jdk-image` produces in `build/<arch>/images/jdk` - the former will do a lot more stuff during startup, while the latter applies numerous link-time optimizations to reduce lambda and method handle spinning on startup. While speeding up the exploded image is a nice bonus, the runtime images should be the focus of startup optimization work.

This trace shows this is exactly the place fixed by https://github.com/liachmodded/jdk/commit/64fd147bddd085fa3caa437a2b25a3dda3bb517a. `withMethod(String, String, int, MethodTypeDesc)` is not caching the MTD, therefore a re-parse happens, which is quite costly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721131585

From duke at openjdk.org  Mon Aug 19 06:32:26 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 19 Aug 2024 06:32:26 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <x9fIVTHebyCo9zu5_aPNk5CMjtbFuoWngfK3WvB9Ea8=.004ea223-02c3-468d-9a4f-2250348d39fc@github.com>

On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 154:

> 152:             if (num >= 0) {
> 153:                 int shift = num << 3;
> 154:                 len = (int) ((lengths & (0xFFL << shift)) >> shift) & 0xFF;

The?`0xFFL?<<?shift`?step is?unnecessary with?the?trailing `&?0xFF`:
Suggestion:

                len = (int) (lengths >>> shift) & 0xFF;

src/java.base/share/classes/jdk/internal/constant/PrimitiveClassDescImpl.java line 68:

> 66: 
> 67:     /** {@link ClassDesc} representing the primitive type {@code void} */
> 68:     public static final PrimitiveClassDescImpl CD_void = new PrimitiveClassDescImpl("V");

Since?all the?`PrimitiveClassDescImpl`?instances are?now?created in?this?class, the?constructor can?probably be?made?`private`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720766760
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721018923

From duke at openjdk.org  Mon Aug 19 06:32:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:26 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <x9fIVTHebyCo9zu5_aPNk5CMjtbFuoWngfK3WvB9Ea8=.004ea223-02c3-468d-9a4f-2250348d39fc@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <x9fIVTHebyCo9zu5_aPNk5CMjtbFuoWngfK3WvB9Ea8=.004ea223-02c3-468d-9a4f-2250348d39fc@github.com>
Message-ID: <uVdr5yfeZvhEeugT4uaKIliAM6gV8O0Pv79Qj0CgEhQ=.14f89d6e-947f-4ae3-ad0e-a353bed63f98@github.com>

On Sat, 17 Aug 2024 12:04:20 GMT, ExE Boss <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 154:
> 
>> 152:             if (num >= 0) {
>> 153:                 int shift = num << 3;
>> 154:                 len = (int) ((lengths & (0xFFL << shift)) >> shift) & 0xFF;
> 
> The?`0xFFL?<<?shift`?step is?unnecessary with?the?trailing `&?0xFF`:
> Suggestion:
> 
>                 len = (int) (lengths >>> shift) & 0xFF;

Under MacBook M1 Pro, the performance of running the scenario `(Ljava/lang/Object;Ljava/lang/String;)I` multiple times is very different. The above code is rollback verification, but it is found that the problem is not solved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720767948

From redestad at openjdk.org  Mon Aug 19 06:32:26 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 19 Aug 2024 06:32:26 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
Message-ID: <D8MeDeZBtwnlj68R43gpGdG7gTLCIiRJQ1GvVaRA9Fc=.90c41328-ebd2-4875-be85-33dccad5e172@github.com>

On Fri, 16 Aug 2024 17:06:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/classfile/MethodTypeDescBench.java line 23:
>> 
>>> 21:  * questions.
>>> 22:  */
>>> 23: package org.openjdk.bench.java.lang.classfile;
>> 
>> Wrong package as the code being tested is in java.lang.constant. Also there is already a related microbenchmark in org.openjdk.bench.java.lang.constant.MethodTypeDescFactories - can you check if that covers your needs?
>
> MethodTypeDescFactories has some illegal MethodTypeDesc, and throwing exceptions will affect the performance comparison of normal scenarios.

Not intentionally - which one is illegal? Or are you thinking about the dots? Those are replaced with the descriptorString of the benchmark class before execution. Just a trick to allow testing really long descriptor strings without making the parameter output humongous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720164037

From duke at openjdk.org  Mon Aug 19 06:32:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:32:26 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <D8MeDeZBtwnlj68R43gpGdG7gTLCIiRJQ1GvVaRA9Fc=.90c41328-ebd2-4875-be85-33dccad5e172@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <TzbCqBqdxoYIMrFCylbz5ljhxhbd4klHLMqgTonq_ZY=.fca9432c-2f6b-4840-883b-9765d05b1e20@github.com>
 <qXlhIYasAOnsTQL6NNKVULPwFlrygNSaxYdpega9J7U=.d6eb1432-2717-4bce-9fe4-ff4e879f59d6@github.com>
 <D8MeDeZBtwnlj68R43gpGdG7gTLCIiRJQ1GvVaRA9Fc=.90c41328-ebd2-4875-be85-33dccad5e172@github.com>
Message-ID: <YFUkg7NWcup6brLIkktcpvkI4NZZ2FY6J31G1Uile00=.ee6252a7-09bd-4a1e-af70-cd5650a22926@github.com>

On Fri, 16 Aug 2024 18:17:15 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> MethodTypeDescFactories has some illegal MethodTypeDesc, and throwing exceptions will affect the performance comparison of normal scenarios.
>
> Not intentionally - which one is illegal? Or are you thinking about the dots? Those are replaced with the descriptorString of the benchmark class before execution. Just a trick to allow testing really long descriptor strings without making the parameter output humongous.

It was my problem. I didn't fully understand the code before and had a wrong view.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1720477864

From syan at openjdk.org  Mon Aug 19 06:35:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 19 Aug 2024 06:35:03 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v4]
In-Reply-To: <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
Message-ID: <4p4NydbH_U9gcM0OsoOmhpLpCJu8ObgPaAd8ZfTyqe8=.64fef573-9f7f-4698-81d1-262b822c560b@github.com>

On Fri, 26 Jul 2024 06:29:05 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.
>> 
>> The rpmbuild mock enviroment is like a sandbox, which created by `chroot` shell command, in the rpmbuild mock enviroment, `df -h` report `cannot read table of mounted file systems`, and java Files.getFileStore also throw `IOException`. We want to build and test the jdk in this `sandbox`, and the default jtreg work directory is `JTWork` in current directory, so this testcase will report fails.
>> 
>> 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 the exception's toString() into SkipException

Thanks for the sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2295768406

From syan at openjdk.org  Mon Aug 19 06:40:52 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 19 Aug 2024 06:40:52 GMT
Subject: RFR: 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild
 mock enviroment [v4]
In-Reply-To: <eP-Nee4Av7yi_UQqFeSPrEC_PH_V-XJHXP8ksAVXjaM=.5276df70-cc50-4bf1-94d4-ee41c8718fd4@github.com>
References: <3N_Qd131aGTjsB9gWQ9T1My3gSZ1KNB1jCn-tJ9LnL4=.11069f77-38e2-4a66-a4bc-bce98f9e905f@github.com>
 <jUX1lQHQrl8Y36CpBgozstm9qvZFtPh-QRjGMCLtOxo=.9e1e97aa-49f2-4710-98d4-0278355321e5@github.com>
 <eP-Nee4Av7yi_UQqFeSPrEC_PH_V-XJHXP8ksAVXjaM=.5276df70-cc50-4bf1-94d4-ee41c8718fd4@github.com>
Message-ID: <7wSMorr_4Y0w_2LaELEEno6jB282KwSPduroFbLLQas=.d4bca4ab-e856-4827-ab49-42622daea056@github.com>

On Mon, 19 Aug 2024 04:43:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> tier1 testing with these changes against latest master branch completed without issues. I'll go ahead and sponsor this.

Thanks for the testing and sponsor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2295775965

From duke at openjdk.org  Mon Aug 19 06:41:52 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 06:41:52 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <nKDMQZ9zbmrqCGhim9NWeLAty4xAXYIIrnQ-VCdu3vk=.02d3e5ef-4aa8-400d-ba0f-8c1c41a37b84@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>
 <qI_HBCpWcm8pYwAwp9Q65mm6Sh3fsA0gHkvhyixwVjI=.6c5b5fb5-fd35-4938-b5aa-6a132d0008dc@github.com>
 <KEfapxZvWVquZu_sbBvh9EDqrF4cku-tZBNBz44ZTXo=.729da33b-3c9c-4ae2-a8c0-b85db2321d62@github.com>
 <nKDMQZ9zbmrqCGhim9NWeLAty4xAXYIIrnQ-VCdu3vk=.02d3e5ef-4aa8-400d-ba0f-8c1c41a37b84@github.com>
Message-ID: <o9yabb20RPrK9Px3bEbiZ_cG6r-mD4pkNGyGsf8t7jk=.e55f1dcc-730c-4edf-8c55-129a111281c6@github.com>

On Mon, 19 Aug 2024 05:06:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> regionMatches uses vectorizedMismatch for comparison. The length of `Ljava/lang/Object;` is 18. In the code without intrinsic, it will exit after two long comparisons. If there is vector128 optimization, it will exit after one comparison, and the overhead is very small.
>
> I think you can add a case where the parameters are all these vulnerable names like `Ljava/lang/Objecq;` and repeat 8 times, and see how big a negative impact these close mismatches have.

The scenario of `Ljava/lang/Objecq` does not exist. I have added the following:

(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
(Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;


In these two scenarios, the length of `Ljava/lang/String;` is the same as that of `Ljava/lang/Object;`, and the length of `Ljava/lang/Integer;` is different from that of `Ljava/lang/Object;`, but the performance is similar. This proves that the performance overhead of regionMatches is very small.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721279267

From jbhateja at openjdk.org  Mon Aug 19 06:47:50 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 19 Aug 2024 06:47:50 GMT
Subject: RFR: 8338023: Support two vector selectFrom API
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <fTqbBQboTTJsCnnnHUIccKS_dQ5NxAPiv3Z3On8yqVw=.9c36a963-6a78-4725-8ece-7cd969cbb3c1@github.com>

On Thu, 8 Aug 2024 06:57:28 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

> _Mailing list message from [John Rose](mailto:john.r.rose at oracle.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at mail.openjdk.org):_
> 
> (Better late than never, although I wish I?d been more explicit about this on panama-dev.)
> 
> I think we should be moving away from throwing exceptions on all reorder/shuffle/permute vector ops, and moving toward wrapping. These ops all operate on vectors (small arrays) of vector lane indexes (small array indexes in a fixed domain, always a power of two). The throwing behavior checks an input for bad indexes and throws a (scalar) exception if there are any at all. The wrapping behavior reduces bad indexes to good ones by an unsigned modulo operation (which is at worst a mask for powers of two).
> 
> If I?m right, then new API points should start out with wrap semantics, not throw semantics. And old API points should be migrated ASAP.
> 
> There?s no loss of functionality in such a move. Instead the defaults are moved around. Before, throwing was the default and wrapping was an explicit operation. After, wrapping would be the default and throwing would be explicit. Both wrapping and throwing checks are available through explicit calls to VectorShuffle methods checkIndexes and wrapIndexes.
> 
> OK, so why is wrapping better than throwing? And first, why did we start with throwing as the default? Well, we chose throwing as the default to make the vector operations more Java-like. Java scalar operations don?t try to reduce bad array indexes into the array domain; they throw. Since a shuffle op is like an array reference, it makes sense to emulate the checks built into Java array references.
> 
> Or it did make sense. I think there is a technical debt here which is turning out to be hard to pay off. The tech debt is to suppress or hoist or strength-reduce the vector instructions that perform the check for invalid indexes (in parallel), then ask ?did any of those checks fail?? (a mask reduction), then do a conditional branch to failure code. I think I was over-confident that our scalar tactics for reducing array range checks would apply to vectors as well. On second thought, vectorizing our key optimization, of loop range splitting (pre/main/post loops) is kind of a nightmare.
> 
> Instead, consider the alternative of wrapping. First, you use vpand or the like to mask the indexes down to the valid range. Then you run the shuffle/permute instruction. That?s it. There is no scalar query or branch. And, there are probably some circumstances where you can omit the vpand operation: Perhaps the hardware already masks the inputs (as with shift instructions). Or, perhaps C2 can do bitwise inference of the vectors and figure out that the vpand is a nop. (I am agitating for bitwise types in C2; this is a use case for them.) In the worst case, the vpand op is fast and pipelines well.
> 
> This is why I think we should switch, ASAP, to masking instead of throwing, on bad indexes.
> 
> I think some of our reports from customers have shown that the extra checks necessary for throwing on bad indexes are giving their code surprising slowdowns, relative to C-based vector code.
> 
> Did I miss a point?
> 
> ? John
> 
> On 14 Aug 2024, at 3:43, Jatin Bhateja wrote:


Hi @rose00,

I agree that wrapping should be the default behaviour if indices are passed through shuffles, idea was to pick exception throwing semantics for out of bounds indexes *only* for selectFrom flavour of APIs which accept indexes through vector interface, this will save redundant partial wrapping and un-wrapping for cross vector permutation API which has a direct mappings in x86 and AARCH64 ISA.

As @PaulSandoz [suggested](https://github.com/openjdk/jdk/pull/20508#pullrequestreview-2234095541) we can also tune existing single 'selectFrom' API to adopt default exception throwing semantics if any of the indices lies beyond valid index range.

While we will continue keeping default wrapping semantics for APIs accepting shuffles, this little deviation of semantics for selectFrom family of APIs will enable generating efficient code and will enable users to chooses between the rearrange and selectFrom APIs based on convenience vs efficient code trade-off.

Since, API interfaces were crafted keeping in view long term flexibility, having multiple permutation interfaces (selectFrom / rearrange) accepting indexes though vector or shuffle enables compiler to emit efficient code.

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2295785781

From jbhateja at openjdk.org  Mon Aug 19 07:19:30 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 19 Aug 2024 07:19:30 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
Message-ID: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
> 
> 
>      . SUADD   : Saturating unsigned addition.
>      . SADD    : Saturating signed addition. 
>      . SUSUB   : Saturating unsigned subtraction.
>      . SSUB    : Saturating signed subtraction.
>      . UMAX    : Unsigned max
>      . UMIN    : Unsigned min.
>      
> 
> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
> 
> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
> 
> Summary of changes:
> - Java side implementation of new vector operators.
> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
> - C2 compiler IR and inline expander changes.
> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
> - Extends existing VectorAPI Jtreg test suite to cover new operations.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20507/files
  - new: https://git.openjdk.org/jdk/pull/20507/files/8c9bfeca..c42b4afa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20507&range=02-03

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20507/head:pull/20507

PR: https://git.openjdk.org/jdk/pull/20507

From jbhateja at openjdk.org  Mon Aug 19 07:36:15 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 19 Aug 2024 07:36:15 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v2]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <xuTY1qMhnMgTyrqVtPX3JoVe6LtzTd-UA5MtLSptwy4=.717829f2-8a3b-4baa-aed3-7a5264f3ef83@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions incorporated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/82c0b0a2..055fb22f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=00-01

  Stats: 31 lines in 31 files changed: 0 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jkratochvil at openjdk.org  Mon Aug 19 08:14:54 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 Aug 2024 08:14:54 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v21]
In-Reply-To: <Laro5HJ5erxe0pETqdeDbZB2PJuI_KXz8HVc6cafyhU=.66ba40c9-ae81-4f23-ab5a-ab2742568462@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <Laro5HJ5erxe0pETqdeDbZB2PJuI_KXz8HVc6cafyhU=.66ba40c9-ae81-4f23-ab5a-ab2742568462@github.com>
Message-ID: <_IdC0c5rLgwyAvaTPhad1GPKAUUiRUiaWoWjREx3AC0=.717536b7-d529-4fc3-aed5-60fcd920e9ef@github.com>

On Sat, 17 Aug 2024 05:29:31 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>> The testcase requires root permissions.
>> 
>> Fix by  Severin Gehwolf.
>> Testcase 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 12 commits:
> 
>  - Functionality fixes after the refactorization
>  - Fix up compilation
>  - Merge remote-tracking branch 'origin/master' into master-cgroup
>  - Merge remote-tracking branch 'origin/master' into master-cgroup
>  - Testcase update upon review by Severin Gehwolf
>  - Testcase update upon review by Severin Gehwolf
>  - Inline adjust_controller() twice
>  - Revert "Unify 4 copies of adjust_controller()"
>    
>    This reverts commit 77a81d07d74c8ae9bf34bfd8df9bcaca451ede9a.
>  - Implement vm.cgroup.tools
>  - Use Metrics.systemMetrics().getProvider()
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/07352c67...f06645f2

As we cannot find an agreement even on the comment in the testcase and this pull request will have soon an anniversary, proposing:
- check-in the fix from a separate pull request as it is whole your fix anyway
- I will just file this testcase into JBS, keep it downstream and close this pull request
- or you can also check it in together with this testcase in any way, shape or form as long as there isn't stated my name

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2295940427

From shade at openjdk.org  Mon Aug 19 08:37:49 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Aug 2024 08:37:49 GMT
Subject: RFR: 8329597: C2: Intrinsify Reference.clear [v3]
In-Reply-To: <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
References: <UUK4x10bUNfUXL5R6t7ljHta6VMbko4xvGIdbTsVkXI=.641dde03-e6fb-4c8f-b6c3-5ad97cf5e9e7@github.com>
 <3YO4hhzlqlR5MkUMVq7mJAsiwz7f45VvGI5uatYRi0I=.881fe998-afb9-4024-bc2f-5ed3b582b0f6@github.com>
Message-ID: <WKokfr49NGgY0fXntckY4Es-FQ8kUfZzGD09lf-DdmY=.844f02c5-83f3-43ff-96e5-91e720c78f55@github.com>

On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native method for `Reference.clear`. The original patch skipped intrinsification of this method, because we thought `Reference.clear` is not on a performance sensitive path. However, it shows up prominently on simple benchmarks that touch e.g. `ThreadLocal` cleanups. See the bug for an example profile with `RRWL` benchmarks.
>> 
>> We need to know the actual oop strongness/weakness before we call into C2 Access API, this work models this after existing code for `refersTo0` intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Amend the test case for guaranteing it works under different compilation regimes

Not now, bot. Still waiting for reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20139#issuecomment-2295989638

From asotona at openjdk.org  Mon Aug 19 08:59:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 Aug 2024 08:59:13 GMT
Subject: RFR: 8338564: Remove obsolete AbstractNamedEntry::equals method
Message-ID: <LCjbTLKeTE_arPHkKquOW9FaLVW0DBkfQV2FMa7E0ps=.05a92c8d-bca3-4bf0-9c72-01c2efb22629@github.com>

Method `jdk.internal.classfile.impl.AbstractPoolEntry.AbstractNamedEntry::equals` implementation is invalid.
Fortunately it is overridden with valid implementation in all its sub types and it can be removed.

This patch removes the obsolete an invalid method implementation.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8338564: Remove obsolete AbstractNamedEntry::equals method

Changes: https://git.openjdk.org/jdk/pull/20622/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20622&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338564
  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20622/head:pull/20622

PR: https://git.openjdk.org/jdk/pull/20622

From duke at openjdk.org  Mon Aug 19 09:06:53 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 09:06:53 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <o9yabb20RPrK9Px3bEbiZ_cG6r-mD4pkNGyGsf8t7jk=.e55f1dcc-730c-4edf-8c55-129a111281c6@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <ckZvuUGhLwYJPmxbhm4zNMcZlTZjBjnD8fJcO2RWzkA=.4d4e8a0d-d805-48c1-9a13-8627f10b0d5a@github.com>
 <ffvmPFJj5CRG7ds2Nf6sfs-28l7eBIRYy6qICBp06Mw=.601576fe-8455-49ba-a49b-97bf25d51f7d@github.com>
 <qI_HBCpWcm8pYwAwp9Q65mm6Sh3fsA0gHkvhyixwVjI=.6c5b5fb5-fd35-4938-b5aa-6a132d0008dc@github.com>
 <KEfapxZvWVquZu_sbBvh9EDqrF4cku-tZBNBz44ZTXo=.729da33b-3c9c-4ae2-a8c0-b85db2321d62@github.com>
 <nKDMQZ9zbmrqCGhim9NWeLAty4xAXYIIrnQ-VCdu3vk=.02d3e5ef-4aa8-400d-ba0f-8c1c41a37b84@github.com>
 <o9yabb20RPrK9Px3bEbiZ_cG6r-mD4pkNGyGsf8t7jk=.e55f1dcc-730c-4edf-8c55-129a111281c6@github.com>
Message-ID: <es1eDcKegUBW1APQxFPeRUHkrpLkJDX6I5JnCDz3F7w=.41d423d1-a39c-4e77-a91c-35ca882ae9f4@github.com>

On Mon, 19 Aug 2024 06:39:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> I think you can add a case where the parameters are all these vulnerable names like `Ljava/lang/Objecq;` and repeat 8 times, and see how big a negative impact these close mismatches have.
>
> The scenario of `Ljava/lang/Objecq` does not exist. I have added the following:
> 
> (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
> (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;
> 
> 
> In these two scenarios, the length of `Ljava/lang/String;` is the same as that of `Ljava/lang/Object;`, and the length of `Ljava/lang/Integer;` is different from that of `Ljava/lang/Object;`, but the performance is similar. This proves that the performance overhead of regionMatches is very small.

Here are the performance numbers running under Aliyun ECS c8i (my MacBook M1 Pro is not available at this time, so the performance test is run on Alibaba Cloud?s ECS)

* CPU Intel?Xeon?Emerald Rapids (Linux x64)

## Benchmark Script


# current
git checkout ee321904e6eee307f27cb38a70ac4ca75a8f446b
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## Benchmark Numbers

Benchmark                                                                            (descString)  Mode  Cnt     Score    Error  Units
MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    73.913 ?  0.708  ns/op
MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     1.729 ?  0.013  ns/op
MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    85.204 ?  0.337  ns/op
MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6   120.307 ?  1.887  ns/op
MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6   120.832 ?  1.904  ns/op
MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    23.709 ?  0.548  ns/op
MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   109.046 ?  1.712  ns/op
MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    30.997 ?  0.556  ns/op
MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   179.165 ?  2.371  ns/op
MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   529.011 ? 12.875  ns/op
MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1690.000 ?  9.597  ns/op


This performance number proves my point above that regionMatches has low overhead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1721452746

From sgehwolf at openjdk.org  Mon Aug 19 09:51:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 19 Aug 2024 09:51:53 GMT
Subject: RFR: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected [v21]
In-Reply-To: <_IdC0c5rLgwyAvaTPhad1GPKAUUiRUiaWoWjREx3AC0=.717536b7-d529-4fc3-aed5-60fcd920e9ef@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
 <Laro5HJ5erxe0pETqdeDbZB2PJuI_KXz8HVc6cafyhU=.66ba40c9-ae81-4f23-ab5a-ab2742568462@github.com>
 <_IdC0c5rLgwyAvaTPhad1GPKAUUiRUiaWoWjREx3AC0=.717536b7-d529-4fc3-aed5-60fcd920e9ef@github.com>
Message-ID: <RlJPcNV0SPAIjPZ0TDzFGXfpfStQ-a3QnyZdu45UCpQ=.3326ffd2-53d9-4c92-9190-9f28802dedbd@github.com>

On Mon, 19 Aug 2024 08:12:25 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> As we cannot find an agreement even on the comment in the testcase and this pull request will have soon an anniversary, proposing:
> 
>     * check-in the fix from a separate pull request as it is whole your fix anyway
>     * I will just file this testcase into JBS, keep it downstream and close this pull request
>     * or you can also check it in together with this testcase in any way, shape or form as long as there isn't stated my name

That sounds fair. Sorry about the trouble, but I believe the result will be better and more maintainable. Please log the test case as a separate JBS and pursue this separately (I won't use it). If you close this PR I'll create a new one and re-assign JDK-8322420 to me. Hopefully we can make some progress then. IMO, testing for the issue in form of https://bugs.openjdk.org/browse/JDK-8333446 should be sufficient.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17198#issuecomment-2296145898

From jkratochvil at openjdk.org  Mon Aug 19 10:00:04 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 19 Aug 2024 10:00:04 GMT
Subject: Withdrawn: 8322420: [Linux] cgroup v2: Limits in parent nested control
 groups are not detected
In-Reply-To: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
References: <c6DtrskKpUb_gpAtfqMTy3HLPdk0TiVZGfU5wcNl4Eo=.52b62a49-421b-4853-ba58-a878b4d312c6@github.com>
Message-ID: <qtwecEaBxBFH5pgLWorbtiPhF8BEHArFn_Kf-6_Rf2k=.b09943e0-c9ed-4dc2-9c7f-95f2c9679cb6@github.com>

On Thu, 28 Dec 2023 12:55:22 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> The testcase requires root permissions.
> 
> Fix by  Severin Gehwolf.
> Testcase by Jan Kratochvil.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/17198

From liach at openjdk.org  Mon Aug 19 11:55:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 11:55:49 GMT
Subject: RFR: 8338564: Remove obsolete AbstractNamedEntry::equals method
In-Reply-To: <LCjbTLKeTE_arPHkKquOW9FaLVW0DBkfQV2FMa7E0ps=.05a92c8d-bca3-4bf0-9c72-01c2efb22629@github.com>
References: <LCjbTLKeTE_arPHkKquOW9FaLVW0DBkfQV2FMa7E0ps=.05a92c8d-bca3-4bf0-9c72-01c2efb22629@github.com>
Message-ID: <Tjggarz6nHvMwTemgfxjrie2Lj8OB3TOXLEB6VQ792M=.495488db-d560-4aba-8527-476c82b45897@github.com>

On Mon, 19 Aug 2024 08:54:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Method `jdk.internal.classfile.impl.AbstractPoolEntry.AbstractNamedEntry::equals` implementation is invalid.
> Fortunately it is overridden with valid implementation in all its sub types and it can be removed.
> 
> This patch removes the obsolete an invalid method implementation.
> 
> Please review.
> 
> Thanks,
> Adam

Noticed this a while ago too :)

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20622#pullrequestreview-2245353870

From asotona at openjdk.org  Mon Aug 19 12:59:53 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 Aug 2024 12:59:53 GMT
Subject: Integrated: 8338564: Remove obsolete AbstractNamedEntry::equals method
In-Reply-To: <LCjbTLKeTE_arPHkKquOW9FaLVW0DBkfQV2FMa7E0ps=.05a92c8d-bca3-4bf0-9c72-01c2efb22629@github.com>
References: <LCjbTLKeTE_arPHkKquOW9FaLVW0DBkfQV2FMa7E0ps=.05a92c8d-bca3-4bf0-9c72-01c2efb22629@github.com>
Message-ID: <bJKIqiFr16jlHuL4Bdc9A1zXIR7j0p-s-Eq1UEaFxVM=.78685ada-7679-464d-8b10-bc8edfda7128@github.com>

On Mon, 19 Aug 2024 08:54:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Method `jdk.internal.classfile.impl.AbstractPoolEntry.AbstractNamedEntry::equals` implementation is invalid.
> Fortunately it is overridden with valid implementation in all its sub types and it can be removed.
> 
> This patch removes the obsolete an invalid method implementation.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: f0fe3138
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0fe31383aec652ad4e3cc4873cd3ff9b918fef7
Stats:     9 lines in 1 file changed: 0 ins; 9 del; 0 mod

8338564: Remove obsolete AbstractNamedEntry::equals method

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20622

From duke at openjdk.org  Mon Aug 19 13:30:57 2024
From: duke at openjdk.org (duke)
Date: Mon, 19 Aug 2024 13:30:57 GMT
Subject: Withdrawn: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <Jr7cUWDjepxdj9H7rWSBEzzzkDeqBFyuIWEXtutjlVY=.91688338-dec9-454f-b541-5883aae27af6@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18915

From duke at openjdk.org  Mon Aug 19 13:35:04 2024
From: duke at openjdk.org (duke)
Date: Mon, 19 Aug 2024 13:35:04 GMT
Subject: Withdrawn: 8329596: Add test for virtual threads invoking synchronized
 native methods
In-Reply-To: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
References: <0WAv0NCYqALX7nfzMStCjcclbxPOFBQ8bvZLLvuyPWM=.5b2959f9-38d1-4d09-b0c6-af231bdde5b3@github.com>
Message-ID: <fdoiZu2niraK_9f2bPPOvTuwZTapjjiJh6UKV_nfAfQ=.b673d6fb-6b05-405d-9fa7-abaa2b895427@github.com>

On Wed, 3 Apr 2024 10:52:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test-only addition to add a test for virtual threads invoking a synchronized native method and invoking a native method that enter/exits a monitor with JNI MonitorEnter/MonitorExit. The test has been in the loom repo for some time, it can move to the main line in advance of changes to the object monitor implementation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18600

From vklang at openjdk.org  Mon Aug 19 13:44:48 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 19 Aug 2024 13:44:48 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
Message-ID: <13z9L0rO1AymUAClyLNjMvrHSYikmBefIvC8-ZnH-4I=.46604c0e-b4c1-4543-8458-9f6edadedf49@github.com>

On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea <dl at openjdk.org> wrote:

> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

OK to merge from my perspective. Waiting for @AlanBateman to weigh in.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20554#issuecomment-2296612092

From liach at openjdk.org  Mon Aug 19 14:46:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 14:46:52 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
Message-ID: <3FKeQ3ZwGbKyh7tfVorMav-IHGG5ZrqHbFLd34DX-g0=.2f5f932e-e832-4505-a190-de75bf307406@github.com>

On Sun, 18 Aug 2024 23:40:24 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> I added two startup process descStrings to the benchmark, and now optimized the parameter type of `Ljava/lang/Object` as follows:
> 
> ## 1. Benchmark script
> 
> git remote add wenshao git at github.com:wenshao/jdk.git
> git fetch wenshao
> 
> # baseline
> git checkout b83e2705662aa444338586713a2a7b2fa7852ba6
> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
> 
> # current
> git checkout 2405e63af284d4074056be40c550918541eead3a
> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
> 
> 
> ## 2. Performance numbers
> 
> ### 2.1 Mac Book M1 Pro
> 
> 
> -# baseline
> -Benchmark                                                                         (descString)  Mode  Cnt     Score     Error  Units
> -MethodTypeDescFactories.ofDescriptor                   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   100.245 ?   3.888  ns/op
> -MethodTypeDescFactories.ofDescriptor                                                       ()V  avgt    6     3.762 ?   0.024  ns/op
> -MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   148.798 ?  21.645  ns/op
> -MethodTypeDescFactories.ofDescriptor                                      ()Ljava/lang/Object;  avgt    6    23.890 ?   0.053  ns/op
> -MethodTypeDescFactories.ofDescriptor                  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   220.012 ?  63.268  ns/op
> -MethodTypeDescFactories.ofDescriptor                                     ()[Ljava/lang/String;  avgt    6    20.612 ?   0.031  ns/op
> -MethodTypeDescFactories.ofDescriptor                                                  (..IIJ)V  avgt    6   167.894 ? 153.553  ns/op
> -MethodTypeDescFactories.ofDescriptor                                         ([III.Z[B..[.[B).  avgt    6   342.610 ?   2.296  ns/op
> -MethodTypeDescFactories.ofDescriptor                                  (.....................).  avgt    6  1115.834 ?   1.067  ns/op
> 
> +# current
> +Benchmark                                                                         (descString)  Mode  Cnt     Score   Error  Units
> +MethodTypeDescFactories.ofDescriptor                   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    48.616 ? 0.440  ns/op
> +MethodTypeDescFactories.ofDescriptor                                                       ()V  avgt    6     1.400 ? 0.004  ns/op
> +MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    56.567 ? 0.101  ns/op
> +MethodTypeDescFactories.ofDescriptor...

@wenshao Can you confirm that this PR is feature frozen, that you won't add new tricks or optimizations here? Reviewers can only start reviewing if you won't bring in other changes that invalidate reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2296754484

From liach at openjdk.org  Mon Aug 19 15:13:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 15:13:18 GMT
Subject: RFR: 8338543: ClassBuilder withMethod builders should cache the method
 type symbol
Message-ID: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>

In #20611 and other investigations, we noted that `MethodTypeDesc.ofDescriptor` is unnecessarily called due to missing caching in ClassBuilder. This patch adds that missing caching functionality.

-------------

Commit messages:
 - 8338543: ClassBuilder withMethod builders should cache the method type symbol

Changes: https://git.openjdk.org/jdk/pull/20627/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20627&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338543
  Stats: 22 lines in 3 files changed: 18 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20627/head:pull/20627

PR: https://git.openjdk.org/jdk/pull/20627

From asotona at openjdk.org  Mon Aug 19 15:27:50 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 19 Aug 2024 15:27:50 GMT
Subject: RFR: 8338543: ClassBuilder withMethod builders should cache the
 method type symbol
In-Reply-To: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
References: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
Message-ID: <noSgIucgeWxnChAmluUCpfit6G_OGLt2J_LBlXcHLcI=.6da4a305-89e2-4d7e-bede-d010e56cc75d@github.com>

On Mon, 19 Aug 2024 15:08:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #20611 and other investigations, we noted that `MethodTypeDesc.ofDescriptor` is unnecessarily called due to missing caching in ClassBuilder. This patch adds that missing caching functionality.

Looks good to me, do you have any benchmark numbers?

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20627#pullrequestreview-2245851016

From liach at openjdk.org  Mon Aug 19 15:32:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 15:32:51 GMT
Subject: RFR: 8338543: ClassBuilder withMethod builders should cache the
 method type symbol
In-Reply-To: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
References: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
Message-ID: <KN967qHvx_iHRAt6-kXP6krEtb__xdzRFZ2_TccLjDk=.7859cd0c-b1b9-4328-a9c8-e510485375e7@github.com>

On Mon, 19 Aug 2024 15:08:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #20611 and other investigations, we noted that `MethodTypeDesc.ofDescriptor` is unnecessarily called due to missing caching in ClassBuilder. This patch adds that missing caching functionality.

I tested by adding a `System.out.println` to `MethodTypeDesc.ofDescriptor` and it printed nothing locally when running this little program including string concat and lambda with `java Ape` (Note that `java Ape.java` will print gibberish once`, didn't diagnose that one yet):

public interface Ape {
    static void main(String... args) {
        Runnable a = () -> {
            System.out.println("asd[" + args[0] + "foo" + args[1]);
        };
        a.run();
    }
}

Before a cache miss call looked like this: https://github.com/openjdk/jdk/pull/20611#discussion_r1721082199

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20627#issuecomment-2296856100

From stefank at openjdk.org  Mon Aug 19 15:43:24 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 19 Aug 2024 15:43:24 GMT
Subject: RFR: 8338139: {ClassLoading,Memory}MXBean::isVerbose methods are
 inconsistent with their setVerbose methods
Message-ID: <R2fILqEZ4ZvhjykNi7lv3vSGYsZpHBqZ6NP2mJP7N9s=.6e9963cf-e50c-4fd7-8099-baa558c3fa44@github.com>

The `ClassLoadingMXBean` and `MemoryMXBean` APIs have `setVerbose` methods to control verbose mode and `isVerbose` methods to query it. Some JCK tests expect `setVerbose(false)` to disable verbose mode and, subsequently, `isVerbose()` to return false. However, if logging to a file is enabled by using -Xlog on the java launcher command line then `isVerbose()` returns true even after calling `setVerbose(false)`.

The proposed patch solves this by introducing two changes:

1) The previous implementation used the `log_is_enabled` functionality to check if logging was enabled for the given tag set. This returns true if logging has been turned on for *any* output. The patch changes this so that `isVerbose` only checks what has been configured for stdout, which is the output that `setVerbose` configures.

2) The previous implementation of `setVerbose` turned on `class+load*` (notice the star) but then `isVerbose` only checked `class+load` (without the star). The patch changes this so that the `isVerbose` in-effect checks `class+load*`. (The `gc` part of the patch did not have this problem)

The main focus on this patch is to fix the JCK failure, with an implementation that follows the API documentation. While looking at this area of the code it is clear that there are other problems that we might want to addressed in the future, but we're intentionally keeping this patch limited in scope so that it can be backported to JDK 23.

A CSR for this change has been created.

Testing:
* The newly implemented tests
* The failing JCK tests with the corresponding -Xlog lines
* Tier1-7 (running)

The patch is co-authored by me and David Holmes

-------------

Commit messages:
 - 8338139: The MXBean isVerbose() is always on when Xlog is enabled

Changes: https://git.openjdk.org/jdk/pull/20628/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338139
  Stats: 195 lines in 6 files changed: 189 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20628/head:pull/20628

PR: https://git.openjdk.org/jdk/pull/20628

From liach at openjdk.org  Mon Aug 19 16:03:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 16:03:28 GMT
Subject: RFR: 8338545: Functional interface implementations for common pre-boot
 ClassFile operations
Message-ID: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>

Some ad-hoc lambdas and classes for functional calls to ClassFile API in early bootstrap can be replaced with a few fixed factories. This allows some methods to be used at early bootstrap with less class loading costs.

Depends on #20627, as this adds another fix to one of the fixes there on `ClassBuilder::withMethodBody(String, MethodTypeDesc, int, Consumer)`.

-------------

Depends on: https://git.openjdk.org/jdk/pull/20627

Commit messages:
 - Sneaky import
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations

Changes: https://git.openjdk.org/jdk/pull/20629/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20629&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338545
  Stats: 139 lines in 11 files changed: 33 ins; 63 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/20629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20629/head:pull/20629

PR: https://git.openjdk.org/jdk/pull/20629

From mli at openjdk.org  Mon Aug 19 16:48:17 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 19 Aug 2024 16:48:17 GMT
Subject: RFR: 8338595: Add more linesize for MIME decoder in macro bench test
 Base64Decode
Message-ID: <w1vKgJuLC3iFknQJX6ybAFVL9xqcub50UXgrtmHIrF8=.2823c887-262a-4c34-8a20-d6635fd172c7@github.com>

Hi,
Can you help to review this simple patch?

Currently, lineSize linesize for MIME case in macro bench test Base64Decode is only "4", but in Base64.Encoder default linesize for MIME encoder is 76.
It's helpful to add more linesize, e.g. 76 and so on.

Thanks!

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20630/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338595
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20630/head:pull/20630

PR: https://git.openjdk.org/jdk/pull/20630

From duke at openjdk.org  Mon Aug 19 17:00:55 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 17:00:55 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <3FKeQ3ZwGbKyh7tfVorMav-IHGG5ZrqHbFLd34DX-g0=.2f5f932e-e832-4505-a190-de75bf307406@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <sAHYdf0LtCkoZhD3i2bvfy2tmrhlPJmLx55HxQ-tF44=.eaa18c7e-ffd3-426a-b313-4d1e4ce6c1dc@github.com>
 <3FKeQ3ZwGbKyh7tfVorMav-IHGG5ZrqHbFLd34DX-g0=.2f5f932e-e832-4505-a190-de75bf307406@github.com>
Message-ID: <OZV71hleb6EpZ5EFCLTuAUFj2107VOzFWtIkA4bpE0A=.736e529c-73cf-49e7-9496-17f435354eb8@github.com>

On Mon, 19 Aug 2024 14:43:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I added two startup process descStrings to the benchmark, and now optimized the parameter type of `Ljava/lang/Object` as follows:
>> 
>> ## 1. Benchmark script
>> 
>> git remote add wenshao git at github.com:wenshao/jdk.git
>> git fetch wenshao
>> 
>> # baseline
>> git checkout b83e2705662aa444338586713a2a7b2fa7852ba6
>> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
>> 
>> # current
>> git checkout 2405e63af284d4074056be40c550918541eead3a
>> make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"
>> 
>> 
>> ## 2. Performance numbers
>> 
>> ### 2.1 Mac Book M1 Pro
>> 
>> 
>> -# baseline
>> -Benchmark                                                                         (descString)  Mode  Cnt     Score     Error  Units
>> -MethodTypeDescFactories.ofDescriptor                   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   100.245 ?   3.888  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                                       ()V  avgt    6     3.762 ?   0.024  ns/op
>> -MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   148.798 ?  21.645  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                      ()Ljava/lang/Object;  avgt    6    23.890 ?   0.053  ns/op
>> -MethodTypeDescFactories.ofDescriptor                  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   220.012 ?  63.268  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                     ()[Ljava/lang/String;  avgt    6    20.612 ?   0.031  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                                  (..IIJ)V  avgt    6   167.894 ? 153.553  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                         ([III.Z[B..[.[B).  avgt    6   342.610 ?   2.296  ns/op
>> -MethodTypeDescFactories.ofDescriptor                                  (.....................).  avgt    6  1115.834 ?   1.067  ns/op
>> 
>> +# current
>> +Benchmark                                                                         (descString)  Mode  Cnt     Score   Error  Units
>> +MethodTypeDescFactories.ofDescriptor                   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    48.616 ? 0.440  ns/op
>> +MethodTypeDescFactories.ofDescriptor                                                       ()V  avgt    6     1.400 ? 0.004  ns/op
>> +MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Objec...
>
> @wenshao Can you confirm that this PR is feature frozen, that you won't add new tricks or optimizations here? Reviewers can only start reviewing if you won't bring in other changes that invalidate reviews.

@liach Yes, I confirm that I don't plan to make any changes, so I set the PR draft to read for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2297022659

From dev at anthonyv.be  Mon Aug 19 18:37:56 2024
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Mon, 19 Aug 2024 18:37:56 +0000
Subject: [External] : Re: Stream Gatherers (JEP 473) feedback
In-Reply-To: <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <ac923193-6324-4fe9-b982-17c7a9e19cd5@anthonyv.be>
 <MW4PR10MB57748484D47BC1FD15603D76FFB72@MW4PR10MB5774.namprd10.prod.outlook.com>
 <bf31768c31a6643bcce058fcfc76fd2bc6a424f7@anthonyv.be>
 <MW4PR10MB5774D038D7F77D94592DC143FFB12@MW4PR10MB5774.namprd10.prod.outlook.com>
 <a19ddf95f62adbf1d6840edfdcb0cad42f0b52b2@anthonyv.be>
 <MW4PR10MB577466273F4CA8CAC947381AFF802@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <8dc8df030286bc44010208dd0c48469ec858ba72@anthonyv.be>

August 15, 2024 at 1:27 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> Hi Anthony,

Hi Viktor

> Thanks for the input?it's much appreciated!
> 
> Introducing yet another, user-facing, type parameter to get slightly improved type inference is unfortunately for me a too high of a price to pay. Ideally, type inference/unification will be improved over time making this issue go away without impacting any signatures.

My arguments would be:
* the type parameter enables using subtypes of Downstream, e.g. `Gatherer::integrator` could return an `Integrator<A, T, R, SpecialDownstream<R>>`
* the type parameter improves type inference
* the type parameter would increase usability. In my experience, nearly all Gatherers are created through the factory methods in Gatherer. And thanks to the improved type inference, I assert that all factory method invocations would work without any type arguments at all. Nowadays type inference is so good that I found it remarkable how often (relatively speaking) I need to provide type arguments with Gatherers, compared to other generic APIs. A substantial amount of Java developers has probably never even had to provide type arguments before, so being able to eliminate their need from the Gatherers API as well seems like a considerable advantage to me
* how realistic is it for type inference to be improved to the point that usage of the Gatherers API wouldn't require type arguments? Both technically and in terms of cost-benefit?

> I'm warming up to the idea of shipping a Gatherers.identity(), and before that happens I would like to see more use-cases where having such a thing would provide a real edge. I can come up with a bunch of synthetic scenarios where it's a win, but it's always better to see app logic numbers.

To summarize previous mails, my arguments are:
* it's a common Gatherer. Gatherers of the form `Gatherer<T, ?, T>` will likely have a degenerate case that is the identity. Some actual factory methods are `append(T... elements)` and `concat(Stream<T> stream)`, `prepend(T... elements)`, and `withInterpolationAt(Set<Instant> instants)`.
* optimization: if a Stream pipeline only contains compositions of `Gatherer.identity()`, the Gatherers can be eliminated entirely from the pipeline and characteristics can be propagated. So for example `list.stream().gather(withInterpolationAt(aSetThatHappensToBeEmpty)).count()` would be optimized to `list.stream().count()` and return instantly. Note that while a homemade implementation could optimize its `andThen` implementation, it wouldn't be able to optimize `Gatherer::andThen` and `Stream::gather`.
* API consistency: there's `Function.identity()`, so why not `Gatherers.identity()` (or `Gatherer.identity()`)? Actually I'd argue this method is more useful for Gatherers, since for Functions, this is often written as `o -> o` instead. For Gatherers there's no alternative like that.

On a final note, in case it hasn't been done yet, I'd like to propose `Gatherers.concat(Stream<T> stream)`. The current `Stream::concat` doesn't allow fluent/readable concatenation of multiple streams.

> Getting rid of the rawtypes in Value could be done, at any point since it isn't exposed to user code. I'll keep this in mind for any upcoming maintenance ?
> 
> Keep the feedback coming ?
> 
> Cheers,
> 
> ?

Kind regards,
Anthony

> **Viktor Klang**
> Software Architect, Java Platform Group
> 
> Oracle
> 
> ????????????????????????????????????????????????????????????????
> 
> **From:** Anthony Vanelverdinghe <dev at anthonyv.be>
> **Sent:** Tuesday, 13 August 2024 18:32
> **To:** Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> **Subject:** [External] : Re: Stream Gatherers (JEP 473) feedback
> ?
> 
> Hi Viktor
> 
> Your previous response inspired me to experiment some more with Gatherers
> 
> As a result I'd like to make a couple propositions:
> 
> * add an additional type parameter.
> 
> ? After doing so, type inference no longer needs any assistance:
> 
> ? `var maxGatherer = Gatherer.ofSequential(State::new, State::integrate, State::finish);`
> 
> * add an identity Gatherer with an optimized `andThen` implementation
> 
> ? as well as an optimization in the default implementation of `Gatherer::andThen`
> 
> * eliminate the use of raw types in `Gatherers.Value`
> 
> Code that implements these propositions is in this gist: https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/37c85eaa86a7833051bc33f6fe88046c__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVct8oxUqg$
> 
> Kind regards,
> 
> Anthony
> 
> July 31, 2024 at 7:58 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> > 
> 
> > Hi Anthony,
> 
> > 
> 
> > >The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> > 
> 
> > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> > 
> 
> > Have you experimented with implementing your own identity Gatherer and implemented its andThen to return the second argument?
> 
> > 
> 
> > >That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> > 
> 
> > Yeah, that or implementing a reorder buffer Gatherer (in case you have unique and continuous sequence numbers).
> 
> > 
> 
> > >This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> > 
> 
> > Yes, there are some limitations to inference, you can see usage examples in the implementation of Gatherers which does need some assistance to inference:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/stream/Gatherers.java__;!!ACWV5N9M2RV99hQ!J9jmL_Q8cHhLAre5Oz5Dq3qafSXAQ2V8f-LrbjNY_tU4qSEx0LDudohXkxCugKiIJpm708DXqVdv0LXetA$
> 
> > 
> 
> > Cheers,
> 
> > 
> 
> > ?
> 
> > 
> 
> > **Viktor Klang**
> 
> > Software Architect, Java Platform Group
> 
> > 
> 
> > Oracle
> 
> > 
> 
> > ????????????????????????????????????????????????????????????????
> 
> > 
> 
> > **From:**?Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > **Sent:**?Tuesday, 30 July 2024 17:20
> 
> > **To:**?Viktor Klang <viktor.klang at oracle.com>; core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > **Subject:**?[External] : Re: Stream Gatherers (JEP 473) feedback
> 
> > ?
> 
> > 
> 
> > July 29, 2024 at 8:08 PM, "Viktor Klang" <viktor.klang at oracle.com> wrote:
> 
> > 
> 
> > >
> 
> > 
> 
> > > Hi Anthony,
> 
> > 
> 
> > Hi Viktor
> 
> > 
> 
> > > Thank you for your patience, and for providing feedback, it is always much appreciated.
> 
> > 
> 
> > >
> 
> > 
> 
> > > >When writing factory methods for Gatherers, there's sometimes a
> 
> > 
> 
> > > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> > 
> 
> > > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> > 
> 
> > > to recognize and eliminate it from the pipeline. One idea is to add
> 
> > 
> 
> > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> > 
> 
> > > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> > 
> 
> > >
> 
> > 
> 
> > > I contemplated adding that but in the end I decided I didn't want to add it for the sake of adding it,
> 
> > 
> 
> > > but rather adding it in case it was deemed necessary.
> 
> > 
> 
> > >
> 
> > 
> 
> > > Do you have a concrete use-case (code) that you could share?
> 
> > 
> 
> > The use case is a time series, which has methods to return a Stream of data points, `record DataPoint(Instant, BigDecimal)`. In DataPoint, there are several Gatherer factory methods, one of which is `Gatherer<DataPoint, ?, DataPoint> withInterpolationAt(NavigableSet<Instant> instants)`. If `instants.isEmpty()`, it returns a no-op Gatherer. In general, I guess most factory methods with a collection parameter (and compatible type arguments for T and R) will have a degenerate case like this when the collection is empty. `<T> Gatherer<T, ?, T> append(T... elements)` would be another example.
> 
> > 
> 
> > `identity()` would also allow an optimized `andThen` implementation, simply returning its argument. And when uncomposed, the Stream library could eliminate the `gather` stage, allowing characteristics to propogate in this case. So `treeSet.stream().gather(identity()).sorted().distinct().toList()` could be optimized to `treeSet.stream().toList()`.
> 
> > 
> 
> > > >Sometimes a factory method returns a Gatherer that only works correctly
> 
> > 
> 
> > > if the upstream has certain characteristics, for example
> 
> > 
> 
> > > Spliterator.SORTED or Spliterator.DISTINCT.
> 
> > 
> 
> > >
> 
> > 
> 
> > > Do you have a concrete use-case (code) that you could share?
> 
> > 
> 
> > All the Streams that are returned from TimeSeries are well-formed: their data points are sorted and distinct. And the Gatherer factory methods in DataPoint assume that their upstreams have these characteristics. However, we can't prevent clients from constructing malformed Streams and invoking the Gatherers on them, which will give erroneous results. Now the Gatherer could keep track of the previous element and verify that the current element is greater than the previous. But the idea was to eliminate this bookkeeping for well-formed Streams, while still preventing erroneous results.
> 
> > 
> 
> > > >One idea is to add methods
> 
> > 
> 
> > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> > 
> 
> > > implementation would be able to recognize and eliminate these from the
> 
> > 
> 
> > > pipeline if the upstream already has these characteristics. That way
> 
> > 
> 
> > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> > 
> 
> > > idea is to provide a Gatherer with a way to inspect the upstream
> 
> > 
> 
> > > characteristics. If the upstream is missing the required
> 
> > 
> 
> > > characteristic(s), it could then throw an IllegalStateException.
> 
> > 
> 
> > I figured the latter idea isn't useful: the upstream might be sorted, even though it doesn't have the sorted characteristic. So it would be harsh for the Gatherer to throw an exception in that case.
> 
> > 
> 
> > > For a rather long time Gatherer had characteristics, however,
> 
> > 
> 
> > > what I noticed is that given composition of Gatherers what ended up happening
> 
> > 
> 
> > > almost always was that the combination of characteristics added overhead and devolved into the empty set
> 
> > 
> 
> > > real fast.
> 
> > 
> 
> > >
> 
> > 
> 
> > > Also, when it comes to things like sorted() and distinct(), they (by necessity) have to get processed in full
> 
> > 
> 
> > > before emitting anything downstream, which creates a lot of extra memory allocation and doesn't lend themselves all that well to any depth-first streaming.
> 
> > 
> 
> > In the given use case, well-formed Streams would already have the sorted and distinct characteristics. So the idea was that the sorted() and distinct() gatherers would be eliminated from the pipeline entirely in those cases. Only malformed Streams would have to pay the cost of sorted() and distinct(), but that'd be an acceptable price for them to pay.
> 
> > 
> 
> > That being said, I hadn't considered cases where an intermediate stage in the pipeline would not propagate the characteristics. And in cases where the intermediate stage doesn't affect the characteristics, it would actually be worse to use something like `Gatherers.sorted().andThen(?)`, instead of just keeping track of the previous element and throwing an IllegalStateException if necessary.
> 
> > 
> 
> > > >The returns clause of Gatherer.Integrator::integrate just states "true
> 
> > 
> 
> > > if subsequent integration is desired, false if not". In particular, it
> 
> > 
> 
> > > doesn't document the behavior I'm observing, that returning false also
> 
> > 
> 
> > > causes downstream to reject any further output elements.
> 
> > 
> 
> > >
> 
> > 
> 
> > > Do you have a test case? (There was a bug fixed in this area after 22 was released, so you may want to test it on a 23-ea)
> 
> > 
> 
> > I've uploaded a test case ( https://urldefense.com/v3/__https://gist.github.com/anthonyvdotbe/17e2285bb4f497ed91502b3c09b9a000__;!!ACWV5N9M2RV99hQ!K6tYLK81tcE53MJoE6Dy5VsdhRBlKjNSIbt2BZ-ymlsPWKXiD1FLu-nWwI8WoOyZWihFugQZw9kXEKupSw$? ), but this is indeed already fixed in JDK 23-ea.
> 
> > 
> 
> > This raises a new question though: on line 27 I'd expect I wouldn't need to specify the type arguments for the `ofSequential` method invocation. Is this hitting inherent limitations of type inference or is it possible that some generic type bounds aren't as generic as they could be, prohibiting type inference in certain cases?
> 
> > 
> 
> > > Cheers,
> 
> > 
> 
> > >
> 
> > 
> 
> > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > **Viktor Klang**
> 
> > 
> 
> > > Software Architect, Java Platform Group
> 
> > 
> 
> > >
> 
> > 
> 
> > > Oracle
> 
> > 
> 
> > Kind regards,
> 
> > 
> 
> > Anthony
> 
> > 
> 
> > > ????????????????????????????????????????????????????????????????
> 
> > 
> 
> > >
> 
> > 
> 
> > > **From:** core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Anthony Vanelverdinghe <dev at anthonyv.be>
> 
> > 
> 
> > > **Sent:** Saturday, 27 July 2024 08:57
> 
> > 
> 
> > > **To:** core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> 
> > 
> 
> > > **Subject:** Stream Gatherers (JEP 473) feedback
> 
> > 
> 
> > > ?
> 
> > 
> 
> > >
> 
> > 
> 
> > > When writing factory methods for Gatherers, there's sometimes a
> 
> > 
> 
> > >
> 
> > 
> 
> > > degenerate case that requires returning a no-op Gatherer. So I'd like a
> 
> > 
> 
> > >
> 
> > 
> 
> > > way to mark a no-op Gatherer as such, allowing the Stream implementation
> 
> > 
> 
> > >
> 
> > 
> 
> > > to recognize and eliminate it from the pipeline. One idea is to add
> 
> > 
> 
> > >
> 
> > 
> 
> > > Gatherer.defaultIntegrator(), analogous to the other default? methods.
> 
> > 
> 
> > >
> 
> > 
> 
> > > Another is to add Gatherers.identity(), analogous to Function.identity().
> 
> > 
> 
> > >
> 
> > 
> 
> > > Sometimes a factory method returns a Gatherer that only works correctly
> 
> > 
> 
> > >
> 
> > 
> 
> > > if the upstream has certain characteristics, for example
> 
> > 
> 
> > >
> 
> > 
> 
> > > Spliterator.SORTED or Spliterator.DISTINCT. One idea is to add methods
> 
> > 
> 
> > >
> 
> > 
> 
> > > like Gatherers.sorted() and Gatherers.distinct(), where the Stream
> 
> > 
> 
> > >
> 
> > 
> 
> > > implementation would be able to recognize and eliminate these from the
> 
> > 
> 
> > >
> 
> > 
> 
> > > pipeline if the upstream already has these characteristics. That way
> 
> > 
> 
> > >
> 
> > 
> 
> > > we'd be able to write `return Gatherers.sorted().andThen(?);`. Another
> 
> > 
> 
> > >
> 
> > 
> 
> > > idea is to provide a Gatherer with a way to inspect the upstream
> 
> > 
> 
> > >
> 
> > 
> 
> > > characteristics. If the upstream is missing the required
> 
> > 
> 
> > >
> 
> > 
> 
> > > characteristic(s), it could then throw an IllegalStateException.
> 
> > 
> 
> > >
> 
> > 
> 
> > > The returns clause of Gatherer.Integrator::integrate just states "true
> 
> > 
> 
> > >
> 
> > 
> 
> > > if subsequent integration is desired, false if not". In particular, it
> 
> > 
> 
> > >
> 
> > 
> 
> > > doesn't document the behavior I'm observing, that returning false also
> 
> > 
> 
> > >
> 
> > 
> 
> > > causes downstream to reject any further output elements.
> 
> > 
> 
> > >
> 
> > 
> 
> > > In the Implementation Requirements section of Gatherer, rephrasing
> 
> > 
> 
> > >
> 
> > 
> 
> > > "Outputs and state later in the input sequence will be discarded if
> 
> > 
> 
> > >
> 
> > 
> 
> > > processing an earlier partition short-circuits." to something like the
> 
> > 
> 
> > >
> 
> > 
> 
> > > following would be clearer to me: "As soon as any partition
> 
> > 
> 
> > >
> 
> > 
> 
> > > short-circuits, the whole Gatherer short-circuits. The state of other
> 
> > 
> 
> > >
> 
> > 
> 
> > > partitions is discarded, i.e. there are no further invocations of the
> 
> > 
> 
> > >
> 
> > 
> 
> > > combiner. The finisher is invoked with the short-circuiting partition's
> 
> > 
> 
> > >
> 
> > 
> 
> > > state." I wouldn't mention discarding of outputs, since that's implied
> 
> > 
> 
> > >
> 
> > 
> 
> > > by the act of short-circuiting.
> 
> > 
> 
> > >
> 
> > 
> 
> > > Anthony
> 
> > 
> 
> > >
> 
> >
>

From mr at openjdk.org  Mon Aug 19 21:24:16 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Mon, 19 Aug 2024 21:24:16 GMT
Subject: RFR: 8338611: java.lang.module specification wording not aligned with
 JEP 261
Message-ID: <sPs6qqjlyaJdPEM0ENuGB5dVf99_lrMYBbCq1jF5Wjw=.b5b206f8-72ee-4992-8832-9ccedd32a255@github.com>

The `java.lang.module` package specification defines the default set of root modules as ?every module that is observable on the upgrade module path or among the system modules, and that exports at least one package without qualification.? There?s no need to use the term ?observable? here, since any module in those two locations is, by definition, observable.

This should be changed to align with the wording in [JEP 261](https://openjdk.org/jeps/261#root-modules): ?every module on the upgrade module path or among the system modules that exports at least one package, without qualification.?

This is not a substantive specification change, so a CSR is not required.

-------------

Commit messages:
 - 8338611: java.lang.module specification wording not aligned with JEP 261

Changes: https://git.openjdk.org/jdk/pull/20632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338611
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20632/head:pull/20632

PR: https://git.openjdk.org/jdk/pull/20632

From liach at openjdk.org  Mon Aug 19 21:42:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 21:42:00 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <na4GyQkMjs-NQ93k6CN7yUMB7xqb_J6sgqXw0RG4pt8=.b9052a6c-12fe-4fed-b513-93110c767016@github.com>

On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 297:

> 295:         String objectDesc = "Ljava/lang/Object;";
> 296:         if (len == objectDesc.length() && descriptor.regionMatches(start, objectDesc, 0, len)) {
> 297:             return ReferenceClassDescImpl.CD_Object;

Is there a reason we cannot use `ConstantDescs.CD_Object` and have to redefine it in `ReferenceClassDescImpl`? I see no dependency in initialization order, and the field in RCDI can be removed.

src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line 129:

> 127:         var returnType = resolveClassDesc(descriptor, rightBracket + 1, retTypeLength);
> 128:         if (length == 3 && returnType == CD_void) {
> 129:             return (MethodTypeDescImpl) java.lang.constant.ConstantDescs.MTD_void;

Please import instead of fully qualify ConstantDescs for this field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1722374908
PR Review Comment: https://git.openjdk.org/jdk/pull/20611#discussion_r1722375904

From liach at openjdk.org  Mon Aug 19 21:56:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 21:56:19 GMT
Subject: RFR: 8336756: Improve ClassFile Annotation writing
Message-ID: <3czx3vwZ558CeCAN_8B6eUsyRvOUIneA8QzZz9cttwk=.b0328d87-9d8c-4d4b-a254-17373c4ce35e@github.com>

Clean up annotation writing in classfile api: remove the redundant `Util.Writable` interfaces.

-------------

Commit messages:
 - 8336756: Improve ClassFile Annotation writing

Changes: https://git.openjdk.org/jdk/pull/20635/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336756
  Stats: 123 lines in 3 files changed: 24 ins; 76 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/20635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20635/head:pull/20635

PR: https://git.openjdk.org/jdk/pull/20635

From sviswanathan at openjdk.org  Mon Aug 19 22:05:52 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 19 Aug 2024 22:05:52 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v2]
In-Reply-To: <xuTY1qMhnMgTyrqVtPX3JoVe6LtzTd-UA5MtLSptwy4=.717829f2-8a3b-4baa-aed3-7a5264f3ef83@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <xuTY1qMhnMgTyrqVtPX3JoVe6LtzTd-UA5MtLSptwy4=.717829f2-8a3b-4baa-aed3-7a5264f3ef83@github.com>
Message-ID: <aA7zVy14z60Ke4NMjkOK_WfJs-VXhhuOzsosfhjAQE0=.5f20253a-8c79-4d54-8f30-97d1f710ac1c@github.com>

On Mon, 19 Aug 2024 07:36:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

@rose00 @PaulSandoz Please see the work in progress (https://github.com/openjdk/jdk/pull/20634) to make wrap indices as default for rearrange and selectFrom apis.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2297535442

From duke at openjdk.org  Mon Aug 19 23:14:06 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 19 Aug 2024 23:14:06 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v2]
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <3Eu8GP9EqOhMkvp85tviRp49hhP1YUIraj33CTxESyE=.f9862974-8661-478c-8c22-99c2de134dee@github.com>

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  less changes with suggestions from @liach

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20611/files
  - new: https://git.openjdk.org/jdk/pull/20611/files/ee321904..1e04f5bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20611&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20611&range=00-01

  Stats: 7 lines in 4 files changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20611/head:pull/20611

PR: https://git.openjdk.org/jdk/pull/20611

From liach at openjdk.org  Mon Aug 19 23:28:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Aug 2024 23:28:52 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v2]
In-Reply-To: <3Eu8GP9EqOhMkvp85tviRp49hhP1YUIraj33CTxESyE=.f9862974-8661-478c-8c22-99c2de134dee@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <3Eu8GP9EqOhMkvp85tviRp49hhP1YUIraj33CTxESyE=.f9862974-8661-478c-8c22-99c2de134dee@github.com>
Message-ID: <ERcbBXD78VJnrAMUeiFHt5OdkzutZHp5lXHZOtHto5Q=.19d32a25-bcae-4e80-b7c9-152bd4dee80a@github.com>

On Mon, 19 Aug 2024 23:14:06 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less changes with suggestions from @liach

Thanks for the cleanup. Looks good to me, but I prefer another engineer to review too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20611#pullrequestreview-2246702272

From darcy at openjdk.org  Tue Aug 20 00:34:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 20 Aug 2024 00:34:49 GMT
Subject: RFR: 8336275: Move common Method and Constructor fields to
 Executable [v2]
In-Reply-To: <Z04ux2yyYVR5W1y8prXM4lYPhycn-DE7aM7elm92C3k=.e9eb01d1-cbc3-4da8-be66-03ad947c20ff@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
 <Z04ux2yyYVR5W1y8prXM4lYPhycn-DE7aM7elm92C3k=.e9eb01d1-cbc3-4da8-be66-03ad947c20ff@github.com>
Message-ID: <ngmGF3wEFXh09CZNvB7Vx7vXeR7gEM9rdnJJXp2D7YU=.48d0b992-2fa3-4e12-b6c7-42807ba39c5e@github.com>

On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
>> 
>> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redundant transient; Update the comments to be more accurate

Catching up on reviews, core libs changes look fine. Since Executable is sealed with Constructor and Executable on its permits lists, moving methods up and down the hierarchy (as long as there are concrete methods on Constructor and Method) is fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20188#pullrequestreview-2246761996

From darcy at openjdk.org  Tue Aug 20 00:44:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 20 Aug 2024 00:44:51 GMT
Subject: RFR: 8162500: Receiver annotations of inner classes of local
 classes not found at runtime
In-Reply-To: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
References: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
Message-ID: <1yM80NogW2OQmTrZxWHw0B2bQ_bpIuzpwQT8Xqmg8ME=.446e5cad-e477-4598-8ac4-d4f1b883bea1@github.com>

On Tue, 16 Jul 2024 18:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here
> 
>     public static Class<?> getLocalsMember() {
>         class Local {
>             class Member {
>                 @Annot(2635) Member(@Annot(2732) Local Local.this) {}
>             }
>         }
>         return Local.Member.class;
>     }
> 
> 
> The `Local` occurrences cannot be qualified with the enclosing class type, even if the local class may be compiled to capture the enclosing class.
> 
> However, core reflection had a bug where it looks for an enclosing class instead of a declaring class; this meant that for said `Local`, core reflection was treating the outer class as the top-level in type annotations, while the top level should be the local class instead. This patch fixes this bug.

Should this behavior change (via a bug fix) have a CSR?

Are there any other combination of nested kinds of classes that should be tested as part of a fix in this area?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20200#issuecomment-2297755209

From liach at openjdk.org  Tue Aug 20 03:02:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 03:02:50 GMT
Subject: RFR: 8162500: Receiver annotations of inner classes of local
 classes not found at runtime
In-Reply-To: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
References: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
Message-ID: <4F8Dm79WsPrJr7GxM2fBBS8_fuiFyYwhsJrzJLvfCtg=.0c2b0cce-fbc8-46a8-a1d4-bed73e153ea7@github.com>

On Tue, 16 Jul 2024 18:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here
> 
>     public static Class<?> getLocalsMember() {
>         class Local {
>             class Member {
>                 @Annot(2635) Member(@Annot(2732) Local Local.this) {}
>             }
>         }
>         return Local.Member.class;
>     }
> 
> 
> The `Local` occurrences cannot be qualified with the enclosing class type, even if the local class may be compiled to capture the enclosing class.
> 
> However, core reflection had a bug where it looks for an enclosing class instead of a declaring class; this meant that for said `Local`, core reflection was treating the outer class as the top-level in type annotations, while the top level should be the local class instead. This patch fixes this bug.

I don't think this behavior change is significant enough to merit a CSR: the old erroneous behavior did not lead to false positives that users could depend on, and this change brings core reflection closer to the language model.

Other kinds of nesting as far as I know are currently fine; local and anonymous class themselves do not have reliable receivers per language specification, and within these classes there can only be local, anonymous (which we ignore) or nested classes (which is fixed by this patch). So this covers all areas we currently care about.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20200#issuecomment-2297870665

From liach at openjdk.org  Tue Aug 20 04:14:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 04:14:49 GMT
Subject: RFR: 8336275: Move common Method and Constructor fields to
 Executable [v2]
In-Reply-To: <Z04ux2yyYVR5W1y8prXM4lYPhycn-DE7aM7elm92C3k=.e9eb01d1-cbc3-4da8-be66-03ad947c20ff@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
 <Z04ux2yyYVR5W1y8prXM4lYPhycn-DE7aM7elm92C3k=.e9eb01d1-cbc3-4da8-be66-03ad947c20ff@github.com>
Message-ID: <uXUhOBsrj7C6ImjvL4pfkIR2mHgPaYroZao1MVO6UKc=.01aeeae5-d6f4-4f4b-a55f-fa6efc81ddca@github.com>

On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
>> 
>> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redundant transient; Update the comments to be more accurate

Can anyone review the associated csr?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2297928223

From liach at openjdk.org  Tue Aug 20 05:40:57 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 05:40:57 GMT
Subject: RFR: 8338623: StackCounter adding extraneous slots for receiver invoke
 instructions
Message-ID: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>

StackCounter was adding return type slots before deducting receiver slot, so code like

int b() { return this.hashCode(); }

will be counted as having a max stack of 2. Avoid this problem by only calling `addStackSlot` once for each instruction.

-------------

Commit messages:
 - 8338623: StackCounter adding extraneous slots for receiver invoke instructions

Changes: https://git.openjdk.org/jdk/pull/20637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338623
  Stats: 34 lines in 2 files changed: 29 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20637/head:pull/20637

PR: https://git.openjdk.org/jdk/pull/20637

From liach at openjdk.org  Tue Aug 20 05:45:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 05:45:51 GMT
Subject: RFR: 8338543: ClassBuilder withMethod builders should cache the
 method type symbol
In-Reply-To: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
References: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
Message-ID: <vlemEChgauMUXORTVfnHxqu8PLecEX6iXMbbtxUw0vw=.91ba47de-4587-414b-8d00-798820071121@github.com>

On Mon, 19 Aug 2024 15:08:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #20611 and other investigations, we noted that `MethodTypeDesc.ofDescriptor` is unnecessarily called due to missing caching in ClassBuilder. This patch adds that missing caching functionality.

Thanks for the review. Integrating to facilitate other startup optimization patches dependent on changes here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20627#issuecomment-2298011578

From liach at openjdk.org  Tue Aug 20 05:45:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 05:45:51 GMT
Subject: Integrated: 8338543: ClassBuilder withMethod builders should cache the
 method type symbol
In-Reply-To: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
References: <jXZDNiFLde_ca96JtVVGpVtyzrV1CR5S3ktBjJJ-SpQ=.c68dae0f-3a7e-40a4-9cc8-d0ec630d4440@github.com>
Message-ID: <MOSxMKalJofU7IbSMK4vm8I911ntS9yJVkCy7H9W-DU=.13ac663a-e358-4199-aead-a51c5b20bd4b@github.com>

On Mon, 19 Aug 2024 15:08:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> In #20611 and other investigations, we noted that `MethodTypeDesc.ofDescriptor` is unnecessarily called due to missing caching in ClassBuilder. This patch adds that missing caching functionality.

This pull request has now been integrated.

Changeset: 68d1f5c3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68d1f5c33bf3f64f44f8a10c2f9e4007cfd07d2b
Stats:     22 lines in 3 files changed: 18 ins; 3 del; 1 mod

8338543: ClassBuilder withMethod builders should cache the method type symbol

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20627

From liach at openjdk.org  Tue Aug 20 05:50:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 05:50:05 GMT
Subject: RFR: 8338545: Functional interface implementations for common
 pre-boot ClassFile operations [v2]
In-Reply-To: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
References: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
Message-ID: <T05xvIslnbXRoAxyHnXdt7LWpCMawBF1NTcSOG0O_XU=.e5d3f3ae-eff8-4b0f-bd63-bea8d0a86877@github.com>

> Some ad-hoc lambdas and classes for functional calls to ClassFile API in early bootstrap can be replaced with a few fixed factories. This allows some methods to be used at early bootstrap with less class loading costs.
> 
> Depends on #20627, as this adds another fix to one of the fixes there on `ClassBuilder::withMethodBody(String, MethodTypeDesc, int, Consumer)`.

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.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20629/files
  - new: https://git.openjdk.org/jdk/pull/20629/files/07b93802..07b93802

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20629&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20629&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20629/head:pull/20629

PR: https://git.openjdk.org/jdk/pull/20629

From prappo at openjdk.org  Tue Aug 20 09:10:56 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 20 Aug 2024 09:10:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:

> 93: 
> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.

I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1722966688

From redestad at openjdk.org  Tue Aug 20 10:05:59 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Aug 2024 10:05:59 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v2]
In-Reply-To: <3Eu8GP9EqOhMkvp85tviRp49hhP1YUIraj33CTxESyE=.f9862974-8661-478c-8c22-99c2de134dee@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <3Eu8GP9EqOhMkvp85tviRp49hhP1YUIraj33CTxESyE=.f9862974-8661-478c-8c22-99c2de134dee@github.com>
Message-ID: <It9i1qPLBq2UmsuouAIf5G0wFMmaVKuI2XehjMWwew8=.55994f1c-5a92-4508-91c1-f1c0ac180aec@github.com>

On Mon, 19 Aug 2024 23:14:06 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less changes with suggestions from @liach

It would seem the specialization for `Ljava/lang/Object;` (via `String::regionMatches`) hurts interpreted performance, putting into doubt whether that optimization is fruitful for startup performance. `-Xint` numbers:

Name                                                        (descString) Cnt       Base      Error        Test       Error  Unit  Change
ofDescriptor                     (Ljava/lang/Object;Ljava/lang/String;)I   6   7734,757 ?  154,894   10463,211 ?    61,369 ns/op   0,74x (p = 0,000*)
ofDescriptor                                                         ()V   6   1346,374 ?   56,956     527,418 ?    54,952 ns/op   2,55x (p = 0,000*)
ofDescriptor    (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;   6   9873,260 ?  118,592   13512,378 ?    44,295 ns/op   0,73x (p = 0,000*)
ofDescriptor    (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;   6   9790,973 ?  196,979   15078,814 ?   154,289 ns/op   0,65x (p = 0,000*)
ofDescriptor (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;   6   9963,069 ?  126,510    9610,144 ?  1952,719 ns/op   1,04x (p = 0,270 )
ofDescriptor                                        ()Ljava/lang/Object;   6   3730,028 ?  757,223    4314,956 ?   460,108 ns/op   0,86x (p = 0,002*)
ofDescriptor                    ([IJLjava/lang/String;Z)Ljava/util/List;   6   8909,754 ?   93,260    9004,239 ?   917,012 ns/op   0,99x (p = 0,512 )
ofDescriptor                                       ()[Ljava/lang/String;   6   3710,475 ?  171,494    3159,694 ?    67,448 ns/op   1,17x (p = 0,000*)
ofDescriptor                                                    (..IIJ)V   6  18670,031 ?  257,048   17178,329 ?   544,327 ns/op   1,09x (p = 0,000*)
ofDescriptor                                           ([III.Z[B..[.[B).   6  45623,579 ? 8342,076   46138,662 ? 13494,653 ns/op   0,99x (p = 0,829 )
ofDescriptor                                    (.....................).   6 166686,442 ? 3550,565  167529,385 ? 11210,813 ns/op   0,99x (p = 0,640 )
  * = significant

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2298473472

From alanb at openjdk.org  Tue Aug 20 11:18:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Aug 2024 11:18:48 GMT
Subject: RFR: 8338611: java.lang.module specification wording not aligned
 with JEP 261
In-Reply-To: <sPs6qqjlyaJdPEM0ENuGB5dVf99_lrMYBbCq1jF5Wjw=.b5b206f8-72ee-4992-8832-9ccedd32a255@github.com>
References: <sPs6qqjlyaJdPEM0ENuGB5dVf99_lrMYBbCq1jF5Wjw=.b5b206f8-72ee-4992-8832-9ccedd32a255@github.com>
Message-ID: <GNhWkbXKwAOov9XZZlkF7A5uXuHkYhW5mu4jGvOMzIk=.253224e7-746e-4281-9cda-0da53d1c9a34@github.com>

On Mon, 19 Aug 2024 21:19:13 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> The `java.lang.module` package specification defines the default set of root modules as ?every module that is observable on the upgrade module path or among the system modules, and that exports at least one package without qualification.? There?s no need to use the term ?observable? here, since any module in those two locations is, by definition, observable.
> 
> This should be changed to align with the wording in [JEP 261](https://openjdk.org/jeps/261#Root-modules): ?every module on the upgrade module path or among the system modules that exports at least one package, without qualification.?
> 
> This is not a substantive specification change, so a CSR is not required.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20632#pullrequestreview-2247709846

From asotona at openjdk.org  Tue Aug 20 11:31:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Aug 2024 11:31:49 GMT
Subject: RFR: 8338623: StackCounter adding extraneous slots for receiver
 invoke instructions
In-Reply-To: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>
References: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>
Message-ID: <dd5Xovm3mo5QN15i0N862iF_JHbn6D8Q6Xo5DM2x9o4=.0e1700dc-b653-41e4-8bcb-cf4616bc4a98@github.com>

On Tue, 20 Aug 2024 04:53:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> StackCounter was adding return type slots before deducting receiver slot, so code like
> 
> int b() { return this.hashCode(); }
> 
> will be counted as having a max stack of 2. Avoid this problem by only calling `addStackSlot` once for each instruction.

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20637#pullrequestreview-2247735326

From asotona at openjdk.org  Tue Aug 20 12:00:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Aug 2024 12:00:48 GMT
Subject: RFR: 8336756: Improve ClassFile Annotation writing
In-Reply-To: <3czx3vwZ558CeCAN_8B6eUsyRvOUIneA8QzZz9cttwk=.b0328d87-9d8c-4d4b-a254-17373c4ce35e@github.com>
References: <3czx3vwZ558CeCAN_8B6eUsyRvOUIneA8QzZz9cttwk=.b0328d87-9d8c-4d4b-a254-17373c4ce35e@github.com>
Message-ID: <SFVur7ytqP_4SXmvc0FYh-urDRdD172pEY9xSM6deJc=.9082f7b1-6922-40b0-9444-153430bb4448@github.com>

On Mon, 19 Aug 2024 21:51:40 GMT, Chen Liang <liach at openjdk.org> wrote:

> Clean up annotation writing in classfile api: remove the redundant `Util.Writable` interfaces.

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20635#pullrequestreview-2247789872

From asotona at openjdk.org  Tue Aug 20 12:06:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Aug 2024 12:06:56 GMT
Subject: RFR: 8338545: Functional interface implementations for common
 pre-boot ClassFile operations [v2]
In-Reply-To: <T05xvIslnbXRoAxyHnXdt7LWpCMawBF1NTcSOG0O_XU=.e5d3f3ae-eff8-4b0f-bd63-bea8d0a86877@github.com>
References: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
 <T05xvIslnbXRoAxyHnXdt7LWpCMawBF1NTcSOG0O_XU=.e5d3f3ae-eff8-4b0f-bd63-bea8d0a86877@github.com>
Message-ID: <V0y-1CVlP6MQDJZM6rFiBX77o30FJ3GYeF4ofM-ohsA=.703ab3a9-8da7-47da-95e3-41f214f3db8c@github.com>

On Tue, 20 Aug 2024 05:50:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Some ad-hoc lambdas and classes for functional calls to ClassFile API in early bootstrap can be replaced with a few fixed factories. This allows some methods to be used at early bootstrap with less class loading costs.
>> 
>> Depends on #20627, as this adds another fix to one of the fixes there on `ClassBuilder::withMethodBody(String, MethodTypeDesc, int, Consumer)`.
>
> 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.

Very nice cleanup safeguarding general use of ClassFile in the JDK bootstrap.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20629#pullrequestreview-2247801735

From duke at openjdk.org  Tue Aug 20 12:39:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 20 Aug 2024 12:39:14 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove specialization for `Ljava/lang/Object;`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20611/files
  - new: https://git.openjdk.org/jdk/pull/20611/files/1e04f5bf..43fbe47b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20611&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20611&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20611/head:pull/20611

PR: https://git.openjdk.org/jdk/pull/20611

From asotona at openjdk.org  Tue Aug 20 13:59:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Aug 2024 13:59:21 GMT
Subject: RFR: 8338661: StackMapTable is invalid if frames appear in dead code
Message-ID: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>

ClassFile API allows to build a class with dead code and provide custom `StackMapTable` attribute with user-specified frames covering the dead code.
`StackCounter` is responsible for calculation of `maxStack` and `maxLocals` in certain situations and it did not include the user-provided `StackMapTable` attribute. Dead code was skipped and `maxStack` or `maxLocals` might became underestimated.

This patch includes frames from user-provided `StackMapTable` attribute into the `StackCounter` calculations.

Please review.

Thanks,
Adam

-------------

Depends on: https://git.openjdk.org/jdk/pull/20637

Commit messages:
 - 8338661: StackMapTable is invalid if frames appear in dead code

Changes: https://git.openjdk.org/jdk/pull/20644/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20644&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338661
  Stats: 70 lines in 4 files changed: 61 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20644/head:pull/20644

PR: https://git.openjdk.org/jdk/pull/20644

From bkilambi at openjdk.org  Tue Aug 20 14:26:50 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 20 Aug 2024 14:26:50 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <_AcGpxU2tXImdvN3I65WLEFa5bDnLe6sdlHACNyxRUI=.7a79c223-254e-474a-bc40-fa861b9c1520@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/share/opto/addnode.hpp line 404:

> 402: //------------------------------UMaxINode---------------------------------------
> 403: // Maximum of 2 unsigned integers.
> 404: class UMaxINode : public Node {

Would it be better to define `max_opcode()` and `min_opcode()` for `UMaxINode` and `UMinINode`? These are used to find commutative patterns in `AddNode::Ideal()` and `MulNode::Ideal()` and optimize them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1723414044

From liach at openjdk.org  Tue Aug 20 14:44:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 14:44:50 GMT
Subject: RFR: 8338661: StackMapTable is invalid if frames appear in dead
 code
In-Reply-To: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
References: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
Message-ID: <Szb99PzEt99GVK-UhpV4IFAOfpEjrUNBI6FUusjP-pg=.d278d5cb-1c72-4a3a-b0bd-1524dfaa3069@github.com>

On Tue, 20 Aug 2024 13:54:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API allows to build a class with dead code and provide custom `StackMapTable` attribute with user-specified frames covering the dead code.
> `StackCounter` is responsible for calculation of `maxStack` and `maxLocals` in certain situations and it did not include the user-provided `StackMapTable` attribute. Dead code was skipped and `maxStack` or `maxLocals` might became underestimated.
> 
> This patch includes frames from user-provided `StackMapTable` attribute into the `StackCounter` calculations.
> 
> Please review.
> 
> Thanks,
> Adam

Looks good to me.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20644#pullrequestreview-2248220830

From liach at openjdk.org  Tue Aug 20 14:46:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 14:46:54 GMT
Subject: RFR: 8338623: StackCounter adding extraneous slots for receiver
 invoke instructions
In-Reply-To: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>
References: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>
Message-ID: <yg4VRl2W6dwBYYwtCxI03hvEv2bhSsnscN5vjr5JEIY=.696139eb-ba48-4c79-99b5-1f71300f973c@github.com>

On Tue, 20 Aug 2024 04:53:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> StackCounter was adding return type slots before deducting receiver slot, so code like
> 
> int b() { return this.hashCode(); }
> 
> will be counted as having a max stack of 2. Avoid this problem by only calling `addStackSlot` once for each instruction.

Integrating as this is more serious and affects subsequent fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20637#issuecomment-2299035354

From liach at openjdk.org  Tue Aug 20 14:46:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 14:46:54 GMT
Subject: Integrated: 8338623: StackCounter adding extraneous slots for receiver
 invoke instructions
In-Reply-To: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>
References: <oVSM1Jjz0yDMQ39mlHllYp21g1oCjeOwIp7eGx6re74=.8a3cf5ce-58ea-4f51-a486-8c09343f49e5@github.com>
Message-ID: <S2l9smAzCqUxohbdQMwb2c6TH_rlug34PnX2bQKX5cA=.1d224b55-47ca-444b-afd2-2ac0ea5b0b0a@github.com>

On Tue, 20 Aug 2024 04:53:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> StackCounter was adding return type slots before deducting receiver slot, so code like
> 
> int b() { return this.hashCode(); }
> 
> will be counted as having a max stack of 2. Avoid this problem by only calling `addStackSlot` once for each instruction.

This pull request has now been integrated.

Changeset: b4420030
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b442003048559fc35cafddb62885d3ba75b70838
Stats:     34 lines in 2 files changed: 29 ins; 1 del; 4 mod

8338623: StackCounter adding extraneous slots for receiver invoke instructions

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20637

From asotona at openjdk.org  Tue Aug 20 14:50:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Aug 2024 14:50:22 GMT
Subject: RFR: 8338661: StackMapTable is invalid if frames appear in dead
 code [v2]
In-Reply-To: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
References: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
Message-ID: <ZuwrZuEs9wT_qeRCiG0rHjtnyr-IImG1zqcEizUf2f8=.ae63558b-fc40-48ff-8bcf-9ae88e91757f@github.com>

> ClassFile API allows to build a class with dead code and provide custom `StackMapTable` attribute with user-specified frames covering the dead code.
> `StackCounter` is responsible for calculation of `maxStack` and `maxLocals` in certain situations and it did not include the user-provided `StackMapTable` attribute. Dead code was skipped and `maxStack` or `maxLocals` might became underestimated.
> 
> This patch includes frames from user-provided `StackMapTable` attribute into the `StackCounter` calculations.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20644/files
  - new: https://git.openjdk.org/jdk/pull/20644/files/a5989c97..a5989c97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20644&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20644&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20644/head:pull/20644

PR: https://git.openjdk.org/jdk/pull/20644

From bkilambi at openjdk.org  Tue Aug 20 14:55:52 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 20 Aug 2024 14:55:52 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <rUOHqcoeNiKiQWvjNxpVdSmjN0daVonun95FFkGKOTE=.3f44c95e-0b0b-4a38-a99e-50d737f7293d@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/share/opto/vectornode.hpp line 150:

> 148: class SaturatingVectorNode : public VectorNode {
> 149:  private:
> 150:   bool _is_unsigned;

Would it be better to make it a `const bool`?

src/hotspot/share/opto/vectornode.hpp line 172:

> 170: class SaturatingAddVBNode : public SaturatingVectorNode {
> 171:  public:
> 172:   SaturatingAddVBNode(Node* in1, Node* in2, const TypeVect* vt, bool is_unsigned) : SaturatingVectorNode(in1,in2,vt,is_unsigned) {}

Style: spaces after the commas in `SaturatingVectorNode(in1,in2,vt,is_unsigned)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1723459735
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1723463554

From asotona at openjdk.org  Tue Aug 20 15:08:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 20 Aug 2024 15:08:23 GMT
Subject: RFR: 8338661: StackMapTable is invalid if frames appear in dead
 code [v3]
In-Reply-To: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
References: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
Message-ID: <81jM5CeYOmb77oVE1DURVNLkhd0WvsjI5bR9Mp9Fgag=.c37e55a3-8b04-4f39-9cab-ef8abaafc6a8@github.com>

> ClassFile API allows to build a class with dead code and provide custom `StackMapTable` attribute with user-specified frames covering the dead code.
> `StackCounter` is responsible for calculation of `maxStack` and `maxLocals` in certain situations and it did not include the user-provided `StackMapTable` attribute. Dead code was skipped and `maxStack` or `maxLocals` might became underestimated.
> 
> This patch includes frames from user-provided `StackMapTable` attribute into the `StackCounter` calculations.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8338661-stack-counter
   
   # Conflicts:
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - 8338661: StackMapTable is invalid if frames appear in dead code
 - 8338623: StackCounter adding extraneous slots for receiver invoke instructions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20644/files
  - new: https://git.openjdk.org/jdk/pull/20644/files/a5989c97..22c00b99

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20644&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20644&range=01-02

  Stats: 679 lines in 35 files changed: 516 ins; 16 del; 147 mod
  Patch: https://git.openjdk.org/jdk/pull/20644.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20644/head:pull/20644

PR: https://git.openjdk.org/jdk/pull/20644

From liach at openjdk.org  Tue Aug 20 15:19:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 15:19:51 GMT
Subject: RFR: 8338661: StackMapTable is invalid if frames appear in dead
 code [v3]
In-Reply-To: <81jM5CeYOmb77oVE1DURVNLkhd0WvsjI5bR9Mp9Fgag=.c37e55a3-8b04-4f39-9cab-ef8abaafc6a8@github.com>
References: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
 <81jM5CeYOmb77oVE1DURVNLkhd0WvsjI5bR9Mp9Fgag=.c37e55a3-8b04-4f39-9cab-ef8abaafc6a8@github.com>
Message-ID: <VmkQtznvCv72OBUx7a91QOKAR7Y7h08_p4VDwWDPBr4=.1d9cce33-a6b4-4a68-9d2c-9318660ddac5@github.com>

On Tue, 20 Aug 2024 15:08:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ClassFile API allows to build a class with dead code and provide custom `StackMapTable` attribute with user-specified frames covering the dead code.
>> `StackCounter` is responsible for calculation of `maxStack` and `maxLocals` in certain situations and it did not include the user-provided `StackMapTable` attribute. Dead code was skipped and `maxStack` or `maxLocals` might became underestimated.
>> 
>> This patch includes frames from user-provided `StackMapTable` attribute into the `StackCounter` calculations.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8338661-stack-counter
>    
>    # Conflicts:
>    #	test/jdk/jdk/classfile/StackMapsTest.java
>  - 8338661: StackMapTable is invalid if frames appear in dead code
>  - 8338623: StackCounter adding extraneous slots for receiver invoke instructions

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20644#pullrequestreview-2248315940

From naoto at openjdk.org  Tue Aug 20 15:30:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 Aug 2024 15:30:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <MXhh7BptkSt56mS9c00G6g5ZxmSuhoMR0Lc9TVuQGp0=.34251420-7215-4987-917b-39151f50fad1@github.com>
Message-ID: <9wZvcGjRkpfRm02paHISi86ynU0aYrW9WoinmyIb-RM=.9795a780-b857-4de3-bca6-075305fbd9f7@github.com>

On Tue, 20 Aug 2024 09:07:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace InputStreamReader with BufferedReader
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_pt_BR.properties line 95:
> 
>> 93: 
>> 94: main.usage.summary=Uso: jar [OPTION...] [ [--release VERSION] [-C dir] files] ...
>> 95: main.usage.summary.try=Tente `jar --ajuda' para obter mais informa??es.
> 
> I was looking for something unrelated in properties files, and found this. It is surprising to see an option name being localised; it must be a bug.

Good catch, Pavel. It is indeed a bug. This type of overtranslation l10n bug happens all the time, and hard to catch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1723520963

From alanb at openjdk.org  Tue Aug 20 16:07:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Aug 2024 16:07:53 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <13z9L0rO1AymUAClyLNjMvrHSYikmBefIvC8-ZnH-4I=.46604c0e-b4c1-4543-8458-9f6edadedf49@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
 <13z9L0rO1AymUAClyLNjMvrHSYikmBefIvC8-ZnH-4I=.46604c0e-b4c1-4543-8458-9f6edadedf49@github.com>
Message-ID: <7Ccy9NhQ_zmaQaS7w7RI6WGgL0f0feuD5x_dOLBE6xo=.f389e6a4-6118-4ef2-8af1-453e88303128@github.com>

On Mon, 19 Aug 2024 13:42:30 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> OK to merge from my perspective. Waiting for @AlanBateman to weigh in.

Looks quite good, I'm just wondering if we should add some tests that exercise Exchanger with virtual threads (and a mix of virtual + platform threads).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20554#issuecomment-2299216143

From duke at openjdk.org  Tue Aug 20 16:17:56 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 20 Aug 2024 16:17:56 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
Message-ID: <0YMgzshkiOoXhC3RFr46HsfY_uyiX5aqmiuAcYCIJOc=.4b8dcc6e-ade2-48e2-8a84-a017812c0d72@github.com>

On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove specialization for `Ljava/lang/Object;`

Can we use record to simplify ReferenceClassDescImpl?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2299239766

From alanb at openjdk.org  Tue Aug 20 16:19:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Aug 2024 16:19:52 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
Message-ID: <F5VDQ0JwellkyiaNQpFYIEKQJkNX-GmKUAIY0vWcim8=.2f40f3f0-cb90-4789-999c-8efbb5e418a7@github.com>

On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
>> 
>> 
>> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
>> 
>> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
>> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
>> 3. Some parts of the code are written in C others in C++.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix missing code

src/java.base/windows/native/libjava/java_props_md.c line 327:

> 325: typedef DWORD (WINAPI *GetTempPath2WFnPtr)(DWORD, LPWSTR);
> 326: static GetTempPath2WFnPtr _GetTempPath2W = NULL;
> 327: static BOOL _GetTempPath2WInitialized = FALSE;

GetJavaProperties should only be used once so I don't think you need to cache it.

Also I'm wondering if we can link to the function rather than using GetProcAddress. It looks like GetTempPath2 was added in Windows 8 + Windows Server 2012. I wonder if there is anyone building main line to older SDKs or Windows releases where linking to GetTempPath2 would fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1723600551

From duke at openjdk.org  Tue Aug 20 16:49:00 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 20 Aug 2024 16:49:00 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
Message-ID: <VQtiEfH9HHSjfpQx320D4vkHYvjelyFvuUK3KN6vGTk=.5ff44ad1-e5a5-41b2-8919-da0b5349f664@github.com>

On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove specialization for `Ljava/lang/Object;`

After removing the specialization for `Ljava/lang/Object;`, the performance numbers on multiple platforms are as follows.

In scenarios where the number of parameters is greater than 9, the performance is slightly degraded. In most other scenarios, the performance is significantly improved.

## Benchmark Script

# baseline
git checkout c4697ac165d1b50834e2a653a9f5d025ea4cdaa2
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"

# current
git checkout 43fbe47bec0ecd813ce82bedfd69e0ec7b16dd49
make test TEST="micro:java.lang.constant.MethodTypeDescFactories.ofDescriptor"


## Benchmark Numbers

### 2.1 MacBook M1 Pro

-# baseline
-Benchmark                                                                            (descString)  Mode  Cnt     Score    Error  Units
-MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    99.955 ?  1.148  ns/op
-MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     3.852 ?  0.046  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   138.085 ?  1.482  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6   142.119 ? 12.164  ns/op
-MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6   146.175 ? 19.254  ns/op
-MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    23.943 ?  0.104  ns/op
-MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   235.947 ? 55.958  ns/op
-MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    20.620 ?  0.033  ns/op
-MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   256.069 ? 52.580  ns/op
-MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   339.915 ?  2.157  ns/op
-MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1116.437 ?  5.817  ns/op

+# current
+Benchmark                                                                            (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    94.979 ? 11.222  ns/op
+MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     1.402 ?  0.012  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   123.435 ?  6.001  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6   106.590 ?  5.809  ns/op
+MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6   126.491 ? 10.543  ns/op
+MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    20.053 ?  0.154  ns/op
+MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    64.872 ?  1.508  ns/op
+MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    20.943 ?  0.038  ns/op
+MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   118.211 ?  1.680  ns/op
+MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   335.239 ?  2.006  ns/op
+MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1151.183 ? 18.441  ns/op


| pattern | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 99.955 | 94.979 | 5.24% |
| ()V | 3.852 | 1.402 | 174.75% |
| (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; | 138.085 | 123.435 | 11.87% |
| (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; | 142.119 | 106.590 | 33.33% |
| (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer; | 146.175 | 126.491 | 15.56% |
| ()Ljava/lang/Object; | 23.943 | 20.053 | 19.40% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 235.947 | 64.872 | 263.71% |
| ()[Ljava/lang/String; | 20.620 | 20.943 | -1.54% |
| (..IIJ)V | 256.069 | 118.211 | 116.62% |
| ([III.Z[B..[.[B). | 339.915 | 335.239 | 1.39% |
| (.....................). | 1116.437 | 1151.183 | -3.02% |

### 2.2 Aliyun ECS c8a
* AMD CPU (Linux x64)

# baseline
-Benchmark                                                                            (descString)  Mode  Cnt     Score    Error  Units
-MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    69.519 ?  0.085  ns/op
-MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6    10.187 ?  0.027  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    82.484 ?  0.133  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6    82.436 ?  0.325  ns/op
-MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6    84.290 ?  0.427  ns/op
-MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    20.850 ?  0.067  ns/op
-MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    98.031 ?  0.233  ns/op
-MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    26.571 ?  0.117  ns/op
-MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   143.015 ?  0.635  ns/op
-MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   359.922 ?  1.115  ns/op
-MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1138.662 ? 15.073  ns/op

+# current
+Benchmark                                                                            (descString)  Mode  Cnt     Score   Error  Units
+MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    52.467 ? 0.093  ns/op
+MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     1.373 ? 0.005  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    74.534 ? 0.234  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6    75.800 ? 0.542  ns/op
+MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6    77.573 ? 0.632  ns/op
+MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    20.396 ? 0.058  ns/op
+MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    78.385 ? 1.060  ns/op
+MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    21.528 ? 0.047  ns/op
+MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   130.432 ? 0.393  ns/op
+MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   368.812 ? 0.791  ns/op
+MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1165.988 ? 7.120  ns/op


| pattern | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 69.519 | 52.467 | 32.50% |
| ()V | 10.187 | 1.373 | 641.95% |
| (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; | 82.484 | 74.534 | 10.67% |
| (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; | 82.436 | 75.800 | 8.75% |
| (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer; | 84.290 | 77.573 | 8.66% |
| ()Ljava/lang/Object; | 20.850 | 20.396 | 2.23% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 98.031 | 78.385 | 25.06% |
| ()[Ljava/lang/String; | 26.571 | 21.528 | 23.43% |
| (..IIJ)V | 143.015 | 130.432 | 9.65% |
| ([III.Z[B..[.[B). | 359.922 | 368.812 | -2.41% |
| (.....................). | 1138.662 | 1165.988 | -2.34% |

###  2.3 Aliyun ECS c8i
* Intel CPU (x64)


-# baseline
-Benchmark                                                                            (descString)  Mode  Cnt     Score   Error  Units
-MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    72.201 ? 0.681  ns/op
-MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6    13.187 ? 0.098  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    85.283 ? 0.842  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6    85.462 ? 0.697  ns/op
-MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6    86.912 ? 0.836  ns/op
-MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    21.551 ? 0.162  ns/op
-MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    90.938 ? 0.299  ns/op
-MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    22.450 ? 0.288  ns/op
-MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   152.704 ? 2.675  ns/op
-MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   385.490 ? 1.188  ns/op
-MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1213.829 ? 6.822  ns/op

+# current
+Benchmark                                                                            (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    53.754 ?  0.634  ns/op
+MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     1.576 ?  0.002  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6    74.727 ?  0.364  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6    75.601 ?  0.407  ns/op
+MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6    77.970 ?  0.534  ns/op
+MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    20.358 ?  0.154  ns/op
+MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6    76.490 ?  0.469  ns/op
+MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    21.699 ?  0.089  ns/op
+MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   151.431 ?  2.457  ns/op
+MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   404.335 ?  7.515  ns/op
+MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1249.459 ? 14.023  ns/op


| pattern | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 72.201 | 53.754 | 34.32% |
| ()V | 13.187 | 1.576 | 736.74% |
| (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; | 85.283 | 74.727 | 14.13% |
| (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; | 85.462 | 75.601 | 13.04% |
| (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer; | 86.912 | 77.970 | 11.47% |
| ()Ljava/lang/Object; | 21.551 | 20.358 | 5.86% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 90.938 | 76.490 | 18.89% |
| ()[Ljava/lang/String; | 22.450 | 21.699 | 3.46% |
| (..IIJ)V | 152.704 | 151.431 | 0.84% |
| ([III.Z[B..[.[B). | 385.490 | 404.335 | -4.66% |
| (.....................). | 1213.829 | 1249.459 | -2.85% |


###  2.4 Aliyun ECS c8y
* Aliyun Yitian710 CPU (Linxu aarch64)


-# baseline
-Benchmark                                                                            (descString)  Mode  Cnt     Score   Error  Units
-MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    97.690 ? 0.388  ns/op
-MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     5.866 ? 0.046  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   119.637 ? 0.626  ns/op
-MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6   122.579 ? 1.465  ns/op
-MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6   119.111 ? 0.819  ns/op
-MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    37.169 ? 1.096  ns/op
-MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   126.633 ? 2.096  ns/op
-MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    31.170 ? 0.244  ns/op
-MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   197.251 ? 3.018  ns/op
-MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   572.934 ? 2.635  ns/op
-MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1751.494 ? 7.532  ns/op

+# current
+Benchmark                                                                            (descString)  Mode  Cnt     Score    Error  Units
+MethodTypeDescFactories.ofDescriptor                      (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    73.081 ?  1.390  ns/op
+MethodTypeDescFactories.ofDescriptor                                                          ()V  avgt    6     1.729 ?  0.019  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;  avgt    6   104.971 ?  0.846  ns/op
+MethodTypeDescFactories.ofDescriptor     (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;  avgt    6   105.693 ?  0.963  ns/op
+MethodTypeDescFactories.ofDescriptor  (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer;  avgt    6   108.848 ?  1.048  ns/op
+MethodTypeDescFactories.ofDescriptor                                         ()Ljava/lang/Object;  avgt    6    30.309 ?  0.181  ns/op
+MethodTypeDescFactories.ofDescriptor                     ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   108.834 ?  0.875  ns/op
+MethodTypeDescFactories.ofDescriptor                                        ()[Ljava/lang/String;  avgt    6    30.475 ?  0.531  ns/op
+MethodTypeDescFactories.ofDescriptor                                                     (..IIJ)V  avgt    6   182.938 ?  2.459  ns/op
+MethodTypeDescFactories.ofDescriptor                                            ([III.Z[B..[.[B).  avgt    6   526.788 ?  7.156  ns/op
+MethodTypeDescFactories.ofDescriptor                                     (.....................).  avgt    6  1732.646 ? 10.851  ns/op


| pattern | baseline  | current | delta |
| --- | --- | --- | --- |
| (Ljava/lang/Object;Ljava/lang/String;)I | 97.690 | 73.081 | 33.67% |
| ()V | 5.866 | 1.729 | 239.27% |
| (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; | 119.637 | 104.971 | 13.97% |
| (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; | 122.579 | 105.693 | 15.98% |
| (Ljava/lang/Integer;Ljava/lang/Integer;)Ljava/lang/Integer; | 119.111 | 108.848 | 9.43% |
| ()Ljava/lang/Object; | 37.169 | 30.309 | 22.63% |
| ([IJLjava/lang/String;Z)Ljava/util/List; | 126.633 | 108.834 | 16.35% |
| ()[Ljava/lang/String; | 31.170 | 30.475 | 2.28% |
| (..IIJ)V | 197.251 | 182.938 | 7.82% |
| ([III.Z[B..[.[B). | 572.934 | 526.788 | 8.76% |
| (.....................). | 1751.494 | 1732.646 | 1.09% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2299302549

From liach at openjdk.org  Tue Aug 20 17:02:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 17:02:12 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <0YMgzshkiOoXhC3RFr46HsfY_uyiX5aqmiuAcYCIJOc=.4b8dcc6e-ade2-48e2-8a84-a017812c0d72@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
 <0YMgzshkiOoXhC3RFr46HsfY_uyiX5aqmiuAcYCIJOc=.4b8dcc6e-ade2-48e2-8a84-a017812c0d72@github.com>
Message-ID: <SzSuAUmgLQEcZJBT7bXrNRmBFGY6eZeONP45mjgSNFU=.7b9714ec-48ea-49c2-a45a-700add7b717e@github.com>

On Tue, 20 Aug 2024 16:14:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Can we use record to simplify ReferenceClassDescImpl?

I would say to hold on a bit; I have another WIP patch to create dedicated class desc for arrays, which may conflict with your cleanup, because arrays and components are frequently used in stack map generation. See https://github.com/liachmodded/jdk/tree/feature/array-cd

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2299329142

From liach at openjdk.org  Tue Aug 20 17:06:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 17:06:15 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
Message-ID: <_CUM8ltyFwfmS3cKeAE0XUn9sop15jA2mGvpwM0ctsw=.d68ce8ba-2f45-43a1-b681-67d9ad0d75c2@github.com>

On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove specialization for `Ljava/lang/Object;`

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20611#pullrequestreview-2248575779

From liach at openjdk.org  Tue Aug 20 17:10:56 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 17:10:56 GMT
Subject: RFR: 8338545: Functional interface implementations for common
 pre-boot ClassFile operations [v3]
In-Reply-To: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
References: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
Message-ID: <BO4BJcEoQcMe8DCqVPD3lehkOkTGEvIYPJMUvHJ50v4=.4a9df77c-4b9d-4e9d-a315-0705a5f0e01e@github.com>

> Some ad-hoc lambdas and classes for functional calls to ClassFile API in early bootstrap can be replaced with a few fixed factories. This allows some methods to be used at early bootstrap with less class loading costs.
> 
> Depends on #20627, as this adds another fix to one of the fixes there on `ClassBuilder::withMethodBody(String, MethodTypeDesc, int, Consumer)`.

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 four additional commits since the last revision:

 - Merge branch 'master' into feature/cf-shared-lambdas
 - Sneaky import
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations
 - 8338543: ClassBuilder withMethod builders should cache the method type symbol

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20629/files
  - new: https://git.openjdk.org/jdk/pull/20629/files/07b93802..97a3eed7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20629&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20629&range=01-02

  Stats: 928 lines in 45 files changed: 698 ins; 56 del; 174 mod
  Patch: https://git.openjdk.org/jdk/pull/20629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20629/head:pull/20629

PR: https://git.openjdk.org/jdk/pull/20629

From redestad at openjdk.org  Tue Aug 20 17:31:13 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 20 Aug 2024 17:31:13 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
Message-ID: <0NpdqX3NLE_MuwHPm5GyED2EIRMzBi6ifb3db-qbt-k=.601ef35e-500c-453d-b369-ac95bc2e66c6@github.com>

On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove specialization for `Ljava/lang/Object;`

Thanks for the update.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20611#pullrequestreview-2248625829

From sgehwolf at openjdk.org  Tue Aug 20 17:34:46 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 20 Aug 2024 17:34:46 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@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 eight additional commits since the last revision:

 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Add Whitebox check for host cpu
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - 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/139a9069..eda249b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=03-04

  Stats: 54052 lines in 1621 files changed: 30101 ins; 16055 del; 7896 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 mcimadamore at openjdk.org  Tue Aug 20 18:16:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Aug 2024 18:16:13 GMT
Subject: RFR: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains
Message-ID: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>

This PR reduces the amount of lambda forms (LFs) which are created when generating var handles for simple struct field accessors. This contributes to the startup regression seen in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505).

There are essentially three sources of excessive var handle adaptation:

1. `LayoutPath::dereferenceHandle` has to do some very complex adaptation (including a permute) in order to inject alignment and size checks (against the enclosing layout) on the generated var handle.
2. Even in simple cases (e.g. when there's no dynamic coordinate), the offset of the accessed field is added to the var handle via an expensive collect adapter.
3. When we adapt a `long` var handle to work on `MemorySegment` using an `AddressLayout`, we make no distinction on whether the address layout has a target layout or not. In the latter case (common!) we can adapt more simply.

The meat of this PR is to address (1) by changing the shape of the generated helpers in the `X-VarHandleSegmentView.java.template` class. That is, the method for doing a plain get will now have the following shape:


T get(MemorySegment segment, MemoryLayout enclosing, long base, long offset)


Where:
* `segment` is the segment being accessed
* `enclosing` is the enclosing layout (the root of the selected layout path) against which to check size and alignment
* `base` is the public-facing offset passed by the user when calling `get` on the var handle
* `offset` is the offset at which the selected layout element can be found from the root (this can be replaced with an expression that takes several dynamic indices and turn them into a single offset)

With this organization, it is easy to see how, in order to create a memory access var handle for a struct field `S.f` we only need to:
* inject the enclosing layout `S` into the var handle (into the `enclosing` coordinate)
* inject the offset of `S.f` into the var handle (into the `offset` coordinate)

This way, we get our plain old memory access var handle featuring only two coordinates: a segment and an offset. Note how, to get there, we only needed very simple adaptations (e.g. `MethodHandles::insertCoordinates`).

#### Evaluation

I did some tests using the benchmark in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505) to assess the impact of this change on startup. To evaluate startup, I ran the benchmark 50 times and then took some stats. Here's what the numbers look before this change (AVG = average, MED = median):


AVG        0.196ms
MED        0.198ms
MAX        0.201ms
MIN        0.186ms


And here's after this change:


AVG        0.179ms
MED        0.180ms
MAX        0.183ms
MIN        0.174ms


This is a good 10% speedup. The number of generated LFs for this test went from 99 to 67 (we're at the point where most LFs are from static initializers in the `LayoutPath` and `Utils` classes).

I also run all the memory benhmarks starting with `LoopOver` before and after the change, and verified no unwanted change in peak performance.

#### Future work

There's more work to do here. One possible option is to tweak the template further to also generate variants for `MemorySegment` and `boolean`, so that no adaptation is required in those cases. Some preliminary examples seem to show another 10ms gain with this approach.

Another option would be to add some FFM code to the `HelloClasslist` class, so that some of the generated classes can be optimized at link-time. This also seems to yield another 10ms gain (I have not tried to see if this adds up with the gain in the previously described approach, but I would say probably not - at least not fully).

Many thanks to @cl4es for the invaluable help and moral support :-)

-------------

Commit messages:
 - Fix code breakage after refatcor
 - Consoldiate and share code
 - Improve adaptation of address handles
 - Simplify address adaptation
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/20647/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20647&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338677
  Stats: 181 lines in 3 files changed: 31 ins; 11 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/20647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20647/head:pull/20647

PR: https://git.openjdk.org/jdk/pull/20647

From mr at openjdk.org  Tue Aug 20 18:53:12 2024
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 20 Aug 2024 18:53:12 GMT
Subject: Integrated: 8338611: java.lang.module specification wording not
 aligned with JEP 261
In-Reply-To: <sPs6qqjlyaJdPEM0ENuGB5dVf99_lrMYBbCq1jF5Wjw=.b5b206f8-72ee-4992-8832-9ccedd32a255@github.com>
References: <sPs6qqjlyaJdPEM0ENuGB5dVf99_lrMYBbCq1jF5Wjw=.b5b206f8-72ee-4992-8832-9ccedd32a255@github.com>
Message-ID: <Up17ePRBI2CEDQ0PCojEhxsI5WV7BEL6jNIuU30Ijec=.bba2626e-4ae2-4a5d-89c8-11bafc6b6831@github.com>

On Mon, 19 Aug 2024 21:19:13 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> The `java.lang.module` package specification defines the default set of root modules as ?every module that is observable on the upgrade module path or among the system modules, and that exports at least one package without qualification.? There?s no need to use the term ?observable? here, since any module in those two locations is, by definition, observable.
> 
> This should be changed to align with the wording in [JEP 261](https://openjdk.org/jeps/261#Root-modules): ?every module on the upgrade module path or among the system modules that exports at least one package, without qualification.?
> 
> This is not a substantive specification change, so a CSR is not required.

This pull request has now been integrated.

Changeset: 0267284c
Author:    Mark Reinhold <mr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0267284c52a450afaec78a542910381f5bff58fb
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8338611: java.lang.module specification wording not aligned with JEP 261

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20632

From sgehwolf at openjdk.org  Tue Aug 20 19:04:47 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 20 Aug 2024 19:04:47 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v34]
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: <talFCAYOb2_aiCjAKkxq4i74T421fF6Wp08wA3zN5S0=.945756ad-5255-4f31-b30f-080c4dd9a772@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 139 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - 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
 - ... and 129 more: https://git.openjdk.org/jdk/compare/686eb233...7e2bc4e1

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=33
  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 liach at openjdk.org  Tue Aug 20 19:05:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 19:05:17 GMT
Subject: Integrated: 8336756: Improve ClassFile Annotation writing
In-Reply-To: <3czx3vwZ558CeCAN_8B6eUsyRvOUIneA8QzZz9cttwk=.b0328d87-9d8c-4d4b-a254-17373c4ce35e@github.com>
References: <3czx3vwZ558CeCAN_8B6eUsyRvOUIneA8QzZz9cttwk=.b0328d87-9d8c-4d4b-a254-17373c4ce35e@github.com>
Message-ID: <AwL5ZXQa1wFqDcra_nnBywQpbx3kkP5aJFq9esIq0Fw=.4630d2d7-e5e9-40a7-b4a3-e01716316033@github.com>

On Mon, 19 Aug 2024 21:51:40 GMT, Chen Liang <liach at openjdk.org> wrote:

> Clean up annotation writing in classfile api: remove the redundant `Util.Writable` interfaces.

This pull request has now been integrated.

Changeset: 1ebf2cf6
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ebf2cf639300728ffc024784f5dc1704317b0b3
Stats:     123 lines in 3 files changed: 24 ins; 76 del; 23 mod

8336756: Improve ClassFile Annotation writing

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20635

From dl at openjdk.org  Tue Aug 20 19:31:05 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 20 Aug 2024 19:31:05 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
Message-ID: <zz6Bfd0xE0n6k3ndWX4TcWTL9RirlxEYtsd63KZG-0g=.0ef197f3-af94-4e8f-b409-c307be88b01d@github.com>

On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea <dl at openjdk.org> wrote:

> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

The only applicable tests here are performance tests. I have several ad-hoc ones, but I'm not sure how useful they would be to place in openjdk repo. However, it occurred to me that sometime soon, a version of the whole j.u.c tck suite should be created to use virtual threads. Which would not be  easy, but might uncover something surprising?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20554#issuecomment-2299609454

From liach at openjdk.org  Tue Aug 20 20:38:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 20:38:03 GMT
Subject: RFR: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains
In-Reply-To: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
References: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
Message-ID: <1rU-Tamf1DXrHt0gApE2vqGxWXtQ8YpmwVcn6CaYyJo=.45ddda30-c0d8-4446-a612-2b9726f327ba@github.com>

On Tue, 20 Aug 2024 15:05:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR reduces the amount of lambda forms (LFs) which are created when generating var handles for simple struct field accessors. This contributes to the startup regression seen in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505).
> 
> There are essentially three sources of excessive var handle adaptation:
> 
> 1. `LayoutPath::dereferenceHandle` has to do some very complex adaptation (including a permute) in order to inject alignment and size checks (against the enclosing layout) on the generated var handle.
> 2. Even in simple cases (e.g. when there's no dynamic coordinate), the offset of the accessed field is added to the var handle via an expensive collect adapter.
> 3. When we adapt a `long` var handle to work on `MemorySegment` using an `AddressLayout`, we make no distinction on whether the address layout has a target layout or not. In the latter case (common!) we can adapt more simply.
> 
> The meat of this PR is to address (1) by changing the shape of the generated helpers in the `X-VarHandleSegmentView.java.template` class. That is, the method for doing a plain get will now have the following shape:
> 
> 
> T get(MemorySegment segment, MemoryLayout enclosing, long base, long offset)
> 
> 
> Where:
> * `segment` is the segment being accessed
> * `enclosing` is the enclosing layout (the root of the selected layout path) against which to check size and alignment
> * `base` is the public-facing offset passed by the user when calling `get` on the var handle
> * `offset` is the offset at which the selected layout element can be found from the root (this can be replaced with an expression that takes several dynamic indices and turn them into a single offset)
> 
> With this organization, it is easy to see how, in order to create a memory access var handle for a struct field `S.f` we only need to:
> * inject the enclosing layout `S` into the var handle (into the `enclosing` coordinate)
> * inject the offset of `S.f` into the var handle (into the `offset` coordinate)
> 
> This way, we get our plain old memory access var handle featuring only two coordinates: a segment and an offset. Note how, to get there, we only needed very simple adaptations (e.g. `MethodHandles::insertCoordinates`).
> 
> #### Evaluation
> 
> I did some tests using the benchmark in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505) to assess the impact of this change on startup. To evaluate startup, I ran the benchmark 50 times and then took some stats. Here's what the numbers look before this change (AVG = average, MED = med...

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 245:

> 243: 
> 244:     @ForceInline
> 245:     public static void checkEnclosingLayout(MemorySegment segment, long offset, MemoryLayout enclosing, boolean readOnly) {

Can't the first argument be `AbstractMemorySegmentImpl`? The new call site already has an `AbstractMemorySegmentImpl` and the private static method site can do the cast instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20647#discussion_r1723770255

From alanb at openjdk.org  Tue Aug 20 20:50:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Aug 2024 20:50:03 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <zz6Bfd0xE0n6k3ndWX4TcWTL9RirlxEYtsd63KZG-0g=.0ef197f3-af94-4e8f-b409-c307be88b01d@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
 <zz6Bfd0xE0n6k3ndWX4TcWTL9RirlxEYtsd63KZG-0g=.0ef197f3-af94-4e8f-b409-c307be88b01d@github.com>
Message-ID: <jE0biFBueVS_4lXndko2yA26XTB8WeOd1aL5ddl3r4k=.228552e4-4ead-4423-b83e-7414ac94d523@github.com>

On Tue, 20 Aug 2024 19:28:15 GMT, Doug Lea <dl at openjdk.org> wrote:

>  However, it occurred to me that sometime soon, a version of the whole j.u.c tck suite should be created to use virtual threads. Which would not be easy, but might uncover something surprising?

The j.u.c tests are run with JTREG_TEST_THREAD_FACTORY=Virtual in one of higher tiers so they are at least run with the "main thread" as a virtual thread. We have more tests in java/lang/Thread/virtual that exercise some of the j.u.c APIs including SQ and LTQ so some coverage. It might be that we have to build up more tests over time or have the existing tests driven by thread factories that can be configured.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20554#issuecomment-2299737399

From dhanalla at openjdk.org  Tue Aug 20 21:08:04 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Tue, 20 Aug 2024 21:08:04 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <F5VDQ0JwellkyiaNQpFYIEKQJkNX-GmKUAIY0vWcim8=.2f40f3f0-cb90-4789-999c-8efbb5e418a7@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <F5VDQ0JwellkyiaNQpFYIEKQJkNX-GmKUAIY0vWcim8=.2f40f3f0-cb90-4789-999c-8efbb5e418a7@github.com>
Message-ID: <NJig0Om-3oXnfv742n0bDgKMQMlEVOEinxOOz6xtmDk=.0b9c831b-238a-42ac-8ff1-973a5e5e3308@github.com>

On Tue, 20 Aug 2024 16:17:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix missing code
>
> src/java.base/windows/native/libjava/java_props_md.c line 327:
> 
>> 325: typedef DWORD (WINAPI *GetTempPath2WFnPtr)(DWORD, LPWSTR);
>> 326: static GetTempPath2WFnPtr _GetTempPath2W = NULL;
>> 327: static BOOL _GetTempPath2WInitialized = FALSE;
> 
> GetJavaProperties should only be used once so I don't think you need to cache it.
> 
> Also I'm wondering if we can link to the function rather than using GetProcAddress. It looks like GetTempPath2 was added in Windows 8 + Windows Server 2012. I wonder if there is anyone building main line to older SDKs or Windows releases where linking to GetTempPath2 would fail.

Thanks @AlanBateman for reviewing this PR.
GetTempPath2 is available in Windows10 Build 20348 and above as per https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppath2w#requirements

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20600#discussion_r1723963431

From mcimadamore at openjdk.org  Tue Aug 20 21:16:03 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Aug 2024 21:16:03 GMT
Subject: RFR: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains
In-Reply-To: <1rU-Tamf1DXrHt0gApE2vqGxWXtQ8YpmwVcn6CaYyJo=.45ddda30-c0d8-4446-a612-2b9726f327ba@github.com>
References: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
 <1rU-Tamf1DXrHt0gApE2vqGxWXtQ8YpmwVcn6CaYyJo=.45ddda30-c0d8-4446-a612-2b9726f327ba@github.com>
Message-ID: <1-Rs_k6pWd64FI1At4u8EmlJokDn5b6qnZ5jbMr_E1Y=.39f3c1e3-3ca6-404e-95c4-6107065f0727@github.com>

On Tue, 20 Aug 2024 18:31:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This PR reduces the amount of lambda forms (LFs) which are created when generating var handles for simple struct field accessors. This contributes to the startup regression seen in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505).
>> 
>> There are essentially three sources of excessive var handle adaptation:
>> 
>> 1. `LayoutPath::dereferenceHandle` has to do some very complex adaptation (including a permute) in order to inject alignment and size checks (against the enclosing layout) on the generated var handle.
>> 2. Even in simple cases (e.g. when there's no dynamic coordinate), the offset of the accessed field is added to the var handle via an expensive collect adapter.
>> 3. When we adapt a `long` var handle to work on `MemorySegment` using an `AddressLayout`, we make no distinction on whether the address layout has a target layout or not. In the latter case (common!) we can adapt more simply.
>> 
>> The meat of this PR is to address (1) by changing the shape of the generated helpers in the `X-VarHandleSegmentView.java.template` class. That is, the method for doing a plain get will now have the following shape:
>> 
>> 
>> T get(MemorySegment segment, MemoryLayout enclosing, long base, long offset)
>> 
>> 
>> Where:
>> * `segment` is the segment being accessed
>> * `enclosing` is the enclosing layout (the root of the selected layout path) against which to check size and alignment
>> * `base` is the public-facing offset passed by the user when calling `get` on the var handle
>> * `offset` is the offset at which the selected layout element can be found from the root (this can be replaced with an expression that takes several dynamic indices and turn them into a single offset)
>> 
>> With this organization, it is easy to see how, in order to create a memory access var handle for a struct field `S.f` we only need to:
>> * inject the enclosing layout `S` into the var handle (into the `enclosing` coordinate)
>> * inject the offset of `S.f` into the var handle (into the `offset` coordinate)
>> 
>> This way, we get our plain old memory access var handle featuring only two coordinates: a segment and an offset. Note how, to get there, we only needed very simple adaptations (e.g. `MethodHandles::insertCoordinates`).
>> 
>> #### Evaluation
>> 
>> I did some tests using the benchmark in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505) to assess the impact of this change on startup. To evaluate startup, I ran the benchmark 50 times and then took some stats. Here's what the...
>
> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 245:
> 
>> 243: 
>> 244:     @ForceInline
>> 245:     public static void checkEnclosingLayout(MemorySegment segment, long offset, MemoryLayout enclosing, boolean readOnly) {
> 
> Can't the first argument be `AbstractMemorySegmentImpl`? The new call site already has an `AbstractMemorySegmentImpl` and the private static method site can do the cast instead.

I suppose it could yes - any reason as to why moving the cast around is better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20647#discussion_r1723984684

From liach at openjdk.org  Tue Aug 20 21:37:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 20 Aug 2024 21:37:03 GMT
Subject: RFR: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains
In-Reply-To: <1-Rs_k6pWd64FI1At4u8EmlJokDn5b6qnZ5jbMr_E1Y=.39f3c1e3-3ca6-404e-95c4-6107065f0727@github.com>
References: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
 <1rU-Tamf1DXrHt0gApE2vqGxWXtQ8YpmwVcn6CaYyJo=.45ddda30-c0d8-4446-a612-2b9726f327ba@github.com>
 <1-Rs_k6pWd64FI1At4u8EmlJokDn5b6qnZ5jbMr_E1Y=.39f3c1e3-3ca6-404e-95c4-6107065f0727@github.com>
Message-ID: <pwcUgz7Ol1GOY-IBd1fahknT1y5P1MZroQQ_mDEc2NI=.ded218e6-ea90-444c-a507-c38a5df1f4cb@github.com>

On Tue, 20 Aug 2024 21:13:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 245:
>> 
>>> 243: 
>>> 244:     @ForceInline
>>> 245:     public static void checkEnclosingLayout(MemorySegment segment, long offset, MemoryLayout enclosing, boolean readOnly) {
>> 
>> Can't the first argument be `AbstractMemorySegmentImpl`? The new call site already has an `AbstractMemorySegmentImpl` and the private static method site can do the cast instead.
>
> I suppose it could yes - any reason as to why moving the cast around is better?

Just stylistic - you cast `segment` to `AbstractMemorySegmentImpl` twice here, and if you count here https://github.com/openjdk/jdk/pull/20647/files#diff-e483572155b915ded5f6290c0e91fcf3feeaadf117865ea744920b9b9bbbec45R103 you have already casted 3 times in var handles. You can change the type here and add one new cast here: https://github.com/openjdk/jdk/pull/20647/files#diff-8b4feba9593ad63edaad23970fff28004f916bfa2bf45970f63fad83fb46cd92R289

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20647#discussion_r1724002020

From darcy at openjdk.org  Wed Aug 21 00:11:12 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Aug 2024 00:11:12 GMT
Subject: RFR: 8336934: Clean up JavaLangReflectAccess [v2]
In-Reply-To: <h8CV3_W0xIL41eSWB_SR1sUDWKduvQ9UPveNOkY3KP0=.444cb51d-62fd-43d4-b783-fd0a08d4a539@github.com>
References: <lUD2Sx-dan7g7qYCHY6UY2L9hvEhPkf_vwn9PrQZJgk=.3e1d4347-adf3-42f6-8888-cf6bb02d41d4@github.com>
 <h8CV3_W0xIL41eSWB_SR1sUDWKduvQ9UPveNOkY3KP0=.444cb51d-62fd-43d4-b783-fd0a08d4a539@github.com>
Message-ID: <BpeLNVl5AYt7oOZDUeDIh5IpE96y7oDbP8gM05vehZk=.7bd58418-83d3-4cbb-8493-ebddbf929d12@github.com>

On Thu, 25 Jul 2024 22:33:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`.
>> 
>> The cleanup in `JavaLangReflectAccess` is:
>> - Converted `newConstructor` taking parameters to taking another constructor and a new accessor. The old existing API essentially does a copy and sets an accessor.
>> - Removed lots of constructor getters, unused after `newConstructor` cleanup.
>> - Removed accessor getter/setters, unused after `newConstructor` cleanup.
>> - Removed `leafCopyMethod`. We can already use `getRoot` plus `copyMethod` to achieve the same effect.
>
> 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 three additional commits since the last revision:
> 
>  - Remove editor folds, improve comments
>  - Merge branch 'm5' into cleanup/reflect-access
>  - 8336934: Clean up JavaLangReflectAccess

Looks fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20290#pullrequestreview-2249316504

From liach at openjdk.org  Wed Aug 21 01:08:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 01:08:08 GMT
Subject: RFR: 8336934: Clean up JavaLangReflectAccess [v2]
In-Reply-To: <h8CV3_W0xIL41eSWB_SR1sUDWKduvQ9UPveNOkY3KP0=.444cb51d-62fd-43d4-b783-fd0a08d4a539@github.com>
References: <lUD2Sx-dan7g7qYCHY6UY2L9hvEhPkf_vwn9PrQZJgk=.3e1d4347-adf3-42f6-8888-cf6bb02d41d4@github.com>
 <h8CV3_W0xIL41eSWB_SR1sUDWKduvQ9UPveNOkY3KP0=.444cb51d-62fd-43d4-b783-fd0a08d4a539@github.com>
Message-ID: <csH_vdGViHPUrAcFHkCfBK4EWKoyOsV7YIOdEKMybOA=.217240e0-fc4c-4ce9-9cd8-9f049b73d14f@github.com>

On Thu, 25 Jul 2024 22:33:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`.
>> 
>> The cleanup in `JavaLangReflectAccess` is:
>> - Converted `newConstructor` taking parameters to taking another constructor and a new accessor. The old existing API essentially does a copy and sets an accessor.
>> - Removed lots of constructor getters, unused after `newConstructor` cleanup.
>> - Removed accessor getter/setters, unused after `newConstructor` cleanup.
>> - Removed `leafCopyMethod`. We can already use `getRoot` plus `copyMethod` to achieve the same effect.
>
> 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 three additional commits since the last revision:
> 
>  - Remove editor folds, improve comments
>  - Merge branch 'm5' into cleanup/reflect-access
>  - 8336934: Clean up JavaLangReflectAccess

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20290#issuecomment-2300014330

From liach at openjdk.org  Wed Aug 21 01:08:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 01:08:08 GMT
Subject: Integrated: 8336934: Clean up JavaLangReflectAccess
In-Reply-To: <lUD2Sx-dan7g7qYCHY6UY2L9hvEhPkf_vwn9PrQZJgk=.3e1d4347-adf3-42f6-8888-cf6bb02d41d4@github.com>
References: <lUD2Sx-dan7g7qYCHY6UY2L9hvEhPkf_vwn9PrQZJgk=.3e1d4347-adf3-42f6-8888-cf6bb02d41d4@github.com>
Message-ID: <G2O2rHU4U9DWPEfcx8xa5jCMHkmEj_ITNXDsfrCrMWM=.4f78cc81-daf0-4fd2-92e7-f56ef3deae9c@github.com>

On Tue, 23 Jul 2024 04:10:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Removed redundant APIs in `JavaLangReflectAccess` and added general warning against using `SharedSecrets`.
> 
> The cleanup in `JavaLangReflectAccess` is:
> - Converted `newConstructor` taking parameters to taking another constructor and a new accessor. The old existing API essentially does a copy and sets an accessor.
> - Removed lots of constructor getters, unused after `newConstructor` cleanup.
> - Removed accessor getter/setters, unused after `newConstructor` cleanup.
> - Removed `leafCopyMethod`. We can already use `getRoot` plus `copyMethod` to achieve the same effect.

This pull request has now been integrated.

Changeset: 88ccbb60
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88ccbb60919e4523064b0da17184eedcd9efa087
Stats:     186 lines in 6 files changed: 18 ins; 151 del; 17 mod

8336934: Clean up JavaLangReflectAccess

Reviewed-by: rriggs, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/20290

From syan at openjdk.org  Wed Aug 21 03:50:47 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Aug 2024 03:50:47 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
Message-ID: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>

Hi,
On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
Change has been verified, test fix only, the risk is low.

-------------

Commit messages:
 - 8338630: Test java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout

Changes: https://git.openjdk.org/jdk/pull/20658/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338630
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20658/head:pull/20658

PR: https://git.openjdk.org/jdk/pull/20658

From asotona at openjdk.org  Wed Aug 21 08:22:13 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Aug 2024 08:22:13 GMT
Subject: Integrated: 8338661: StackMapTable is invalid if frames appear in dead
 code
In-Reply-To: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
References: <OQPM71ZTjgStLo_u0VfgyH-7ZfRnY4UuzprbAvlteUw=.506e6a22-f33b-42b0-9cbf-2f51f46d62dc@github.com>
Message-ID: <hgXaeAXiI57jAX9fv_4u4OIVBPhZeMItOlY5E5BI4d0=.57e58ea5-803b-4bb3-868b-ec0b54fe52ff@github.com>

On Tue, 20 Aug 2024 13:54:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ClassFile API allows to build a class with dead code and provide custom `StackMapTable` attribute with user-specified frames covering the dead code.
> `StackCounter` is responsible for calculation of `maxStack` and `maxLocals` in certain situations and it did not include the user-provided `StackMapTable` attribute. Dead code was skipped and `maxStack` or `maxLocals` might became underestimated.
> 
> This patch includes frames from user-provided `StackMapTable` attribute into the `StackCounter` calculations.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: e88a3b05
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e88a3b0574c0a6c6acb5faf7b67674d5b7f0797c
Stats:     70 lines in 4 files changed: 61 ins; 7 del; 2 mod

8338661: StackMapTable is invalid if frames appear in dead code

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20644

From asotona at openjdk.org  Wed Aug 21 08:22:14 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Aug 2024 08:22:14 GMT
Subject: RFR: 8338545: Functional interface implementations for common
 pre-boot ClassFile operations [v3]
In-Reply-To: <BO4BJcEoQcMe8DCqVPD3lehkOkTGEvIYPJMUvHJ50v4=.4a9df77c-4b9d-4e9d-a315-0705a5f0e01e@github.com>
References: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
 <BO4BJcEoQcMe8DCqVPD3lehkOkTGEvIYPJMUvHJ50v4=.4a9df77c-4b9d-4e9d-a315-0705a5f0e01e@github.com>
Message-ID: <tFQHpKL_8bEu6E-cPyfuZuZWmZdmoi1qSSDeIWnhlNM=.02e2453c-2266-45f1-a5bc-86f6c871346b@github.com>

On Tue, 20 Aug 2024 17:10:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Some ad-hoc lambdas and classes for functional calls to ClassFile API in early bootstrap can be replaced with a few fixed factories. This allows some methods to be used at early bootstrap with less class loading costs.
>> 
>> Depends on #20627, as this adds another fix to one of the fixes there on `ClassBuilder::withMethodBody(String, MethodTypeDesc, int, Consumer)`.
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into feature/cf-shared-lambdas
>  - Sneaky import
>  - 8338545: Functional interface implementations for common pre-boot ClassFile operations
>  - 8338543: ClassBuilder withMethod builders should cache the method type symbol

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20629#pullrequestreview-2250122477

From sgehwolf at openjdk.org  Wed Aug 21 08:56:07 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 08:56:07 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
Message-ID: <2WWkA0hsiI5IEhVfh67kj3650YjI5n5PYmg1wakBFzI=.3e3c50b9-81a8-49ca-a032-a33fe36adf45@github.com>

On Tue, 20 Aug 2024 17:34:46 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

GHA failure on maxos-aarch64 is unrelated: [runtime/cds/DeterministicDump](https://github.com/jerboaa/jdk/actions/runs/10476366525#user-content-runtime_cds_deterministicdump)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2301519742

From kevinw at openjdk.org  Wed Aug 21 09:10:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Aug 2024 09:10:03 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
Message-ID: <gmsFUzbuvV3NXS-4uG4eC3LRixJfcQVjwSpZyQJKV58=.8620392a-5401-47bb-b292-be0aec2623ec@github.com>

On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
>> 
>> 
>> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
>> 
>> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
>> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
>> 3. Some parts of the code are written in C others in C++.
>
> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix missing code

Hi,

>From the linked doc:
"When calling this function from a process running as SYSTEM it will return the path C:\Windows\SystemTemp, which is inaccessible to non-SYSTEM processes. For non-SYSTEM processes, GetTempPath2 will behave the same as GetTempPath."

If SYSTEM and regular user processes have a different temp path, and we change temp as it's known to the attach api, they will have a different hsperfdata_username locations.

Then does the attach api only find processes that are of the same category (SYSTEM vs non-SYSTEM)?  e.g. "jps" for a user does not show SYSTEM processes?

SYSTEM is not the "Administrator" user, so it's not going to be a very common problem, but if a Java process run as a SYSTEM then it could be an issue (is that possible?).

And if Java can't be run as a SYSTEM task, then the doc states GetTempPath2 will behave the same as GetTempPath.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20600#pullrequestreview-2250236104

From mcimadamore at openjdk.org  Wed Aug 21 09:38:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Aug 2024 09:38:42 GMT
Subject: RFR: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains [v2]
In-Reply-To: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
References: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
Message-ID: <wvK9Uol_pA8RkOPwcLdlfJV-14x2I5UkA9ElHGOdDfQ=.b16cd09d-d357-42db-98c6-b653c8975867@github.com>

> This PR reduces the amount of lambda forms (LFs) which are created when generating var handles for simple struct field accessors. This contributes to the startup regression seen in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505).
> 
> There are essentially three sources of excessive var handle adaptation:
> 
> 1. `LayoutPath::dereferenceHandle` has to do some very complex adaptation (including a permute) in order to inject alignment and size checks (against the enclosing layout) on the generated var handle.
> 2. Even in simple cases (e.g. when there's no dynamic coordinate), the offset of the accessed field is added to the var handle via an expensive collect adapter.
> 3. When we adapt a `long` var handle to work on `MemorySegment` using an `AddressLayout`, we make no distinction on whether the address layout has a target layout or not. In the latter case (common!) we can adapt more simply.
> 
> The meat of this PR is to address (1) by changing the shape of the generated helpers in the `X-VarHandleSegmentView.java.template` class. That is, the method for doing a plain get will now have the following shape:
> 
> 
> T get(MemorySegment segment, MemoryLayout enclosing, long base, long offset)
> 
> 
> Where:
> * `segment` is the segment being accessed
> * `enclosing` is the enclosing layout (the root of the selected layout path) against which to check size and alignment
> * `base` is the public-facing offset passed by the user when calling `get` on the var handle
> * `offset` is the offset at which the selected layout element can be found from the root (this can be replaced with an expression that takes several dynamic indices and turn them into a single offset)
> 
> With this organization, it is easy to see how, in order to create a memory access var handle for a struct field `S.f` we only need to:
> * inject the enclosing layout `S` into the var handle (into the `enclosing` coordinate)
> * inject the offset of `S.f` into the var handle (into the `offset` coordinate)
> 
> This way, we get our plain old memory access var handle featuring only two coordinates: a segment and an offset. Note how, to get there, we only needed very simple adaptations (e.g. `MethodHandles::insertCoordinates`).
> 
> #### Evaluation
> 
> I did some tests using the benchmark in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505) to assess the impact of this change on startup. To evaluate startup, I ran the benchmark 50 times and then took some stats. Here's what the numbers look before this change (AVG = average, MED = med...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment
  Clarify code comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20647/files
  - new: https://git.openjdk.org/jdk/pull/20647/files/a3018b26..b6c7cf1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20647&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20647&range=00-01

  Stats: 25 lines in 4 files changed: 10 ins; 12 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20647/head:pull/20647

PR: https://git.openjdk.org/jdk/pull/20647

From mcimadamore at openjdk.org  Wed Aug 21 09:46:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Aug 2024 09:46:34 GMT
Subject: RFR: 8338728: Misc issues in memory layout javadoc
Message-ID: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>

This PR fixes two minor issues in the `MemoryLayout` javadoc:
* the section describing dereference path talks about `P` and `P'` but then only uses `P` in the code;
* the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is wrong, as the division returns a negative number for F < 0, which is incorrect

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/20659/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20659&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338728
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20659.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20659/head:pull/20659

PR: https://git.openjdk.org/jdk/pull/20659

From rehn at openjdk.org  Wed Aug 21 10:07:04 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 21 Aug 2024 10:07:04 GMT
Subject: RFR: 8338595: Add more linesize for MIME decoder in macro bench
 test Base64Decode
In-Reply-To: <w1vKgJuLC3iFknQJX6ybAFVL9xqcub50UXgrtmHIrF8=.2823c887-262a-4c34-8a20-d6635fd172c7@github.com>
References: <w1vKgJuLC3iFknQJX6ybAFVL9xqcub50UXgrtmHIrF8=.2823c887-262a-4c34-8a20-d6635fd172c7@github.com>
Message-ID: <hoO1TdMnJWBnxlsAxMaDSd2BuBYq1WauIIf8BXWMM-M=.c4d440a9-f34c-460c-be78-7b304eadbb3a@github.com>

On Mon, 19 Aug 2024 16:43:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple patch?
> 
> Currently, lineSize linesize for MIME case in macro bench test Base64Decode is only "4", but in Base64.Encoder default linesize for MIME encoder is 76.
> It's helpful to add more linesize, e.g. 76 and so on.
> 
> Thanks!

Seems reasonable to me.

-------------

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20630#pullrequestreview-2250364141

From redestad at openjdk.org  Wed Aug 21 10:15:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Aug 2024 10:15:04 GMT
Subject: RFR: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains [v2]
In-Reply-To: <wvK9Uol_pA8RkOPwcLdlfJV-14x2I5UkA9ElHGOdDfQ=.b16cd09d-d357-42db-98c6-b653c8975867@github.com>
References: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
 <wvK9Uol_pA8RkOPwcLdlfJV-14x2I5UkA9ElHGOdDfQ=.b16cd09d-d357-42db-98c6-b653c8975867@github.com>
Message-ID: <JADlGx7snjO5nVWn5VhggZSSa4P7p6kDGm5juApA11g=.a3a47279-b6ee-4369-b48a-00257da2ec33@github.com>

On Wed, 21 Aug 2024 09:38:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR reduces the amount of lambda forms (LFs) which are created when generating var handles for simple struct field accessors. This contributes to the startup regression seen in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505).
>> 
>> There are essentially three sources of excessive var handle adaptation:
>> 
>> 1. `LayoutPath::dereferenceHandle` has to do some very complex adaptation (including a permute) in order to inject alignment and size checks (against the enclosing layout) on the generated var handle.
>> 2. Even in simple cases (e.g. when there's no dynamic coordinate), the offset of the accessed field is added to the var handle via an expensive collect adapter.
>> 3. When we adapt a `long` var handle to work on `MemorySegment` using an `AddressLayout`, we make no distinction on whether the address layout has a target layout or not. In the latter case (common!) we can adapt more simply.
>> 
>> The meat of this PR is to address (1) by changing the shape of the generated helpers in the `X-VarHandleSegmentView.java.template` class. That is, the method for doing a plain get will now have the following shape:
>> 
>> 
>> T get(MemorySegment segment, MemoryLayout enclosing, long base, long offset)
>> 
>> 
>> Where:
>> * `segment` is the segment being accessed
>> * `enclosing` is the enclosing layout (the root of the selected layout path) against which to check size and alignment
>> * `base` is the public-facing offset passed by the user when calling `get` on the var handle
>> * `offset` is the offset at which the selected layout element can be found from the root (this can be replaced with an expression that takes several dynamic indices and turn them into a single offset)
>> 
>> With this organization, it is easy to see how, in order to create a memory access var handle for a struct field `S.f` we only need to:
>> * inject the enclosing layout `S` into the var handle (into the `enclosing` coordinate)
>> * inject the offset of `S.f` into the var handle (into the `offset` coordinate)
>> 
>> This way, we get our plain old memory access var handle featuring only two coordinates: a segment and an offset. Note how, to get there, we only needed very simple adaptations (e.g. `MethodHandles::insertCoordinates`).
>> 
>> #### Evaluation
>> 
>> I did some tests using the benchmark in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505) to assess the impact of this change on startup. To evaluate startup, I ran the benchmark 50 times and then took some stats. Here's what the...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment
>   Clarify code comment

LGTM. 

Some of the new and pre-existing static MHs in `Utils` and other places look like they are used conditionally and are likely candidates to be `StableValue`s once available.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20647#pullrequestreview-2250385822

From mli at openjdk.org  Wed Aug 21 10:20:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 21 Aug 2024 10:20:06 GMT
Subject: Integrated: 8338595: Add more linesize for MIME decoder in macro bench
 test Base64Decode
In-Reply-To: <w1vKgJuLC3iFknQJX6ybAFVL9xqcub50UXgrtmHIrF8=.2823c887-262a-4c34-8a20-d6635fd172c7@github.com>
References: <w1vKgJuLC3iFknQJX6ybAFVL9xqcub50UXgrtmHIrF8=.2823c887-262a-4c34-8a20-d6635fd172c7@github.com>
Message-ID: <dO3ggJNUxYouOfY7NG0Brilz4WG7qtQdi8At0-hDOuE=.725d0fc7-6f6d-4dd2-be25-54fceb78eb6b@github.com>

On Mon, 19 Aug 2024 16:43:02 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple patch?
> 
> Currently, lineSize linesize for MIME case in macro bench test Base64Decode is only "4", but in Base64.Encoder default linesize for MIME encoder is 76.
> It's helpful to add more linesize, e.g. 76 and so on.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 7458952d
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7458952dedc0a34b5c7f3e9e228f9b18e08f19e3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8338595: Add more linesize for MIME decoder in macro bench test Base64Decode

Reviewed-by: rehn

-------------

PR: https://git.openjdk.org/jdk/pull/20630

From mli at openjdk.org  Wed Aug 21 10:20:06 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 21 Aug 2024 10:20:06 GMT
Subject: RFR: 8338595: Add more linesize for MIME decoder in macro bench
 test Base64Decode
In-Reply-To: <hoO1TdMnJWBnxlsAxMaDSd2BuBYq1WauIIf8BXWMM-M=.c4d440a9-f34c-460c-be78-7b304eadbb3a@github.com>
References: <w1vKgJuLC3iFknQJX6ybAFVL9xqcub50UXgrtmHIrF8=.2823c887-262a-4c34-8a20-d6635fd172c7@github.com>
 <hoO1TdMnJWBnxlsAxMaDSd2BuBYq1WauIIf8BXWMM-M=.c4d440a9-f34c-460c-be78-7b304eadbb3a@github.com>
Message-ID: <P6CyUdwRGuW2xWWQO9YtlYauo721mma06URWIkRg_KM=.df027d54-e5c4-4b8a-a1ff-6a05a731468b@github.com>

On Wed, 21 Aug 2024 10:03:57 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi,
>> Can you help to review this simple patch?
>> 
>> Currently, lineSize linesize for MIME case in macro bench test Base64Decode is only "4", but in Base64.Encoder default linesize for MIME encoder is 76.
>> It's helpful to add more linesize, e.g. 76 and so on.
>> 
>> Thanks!
>
> Seems reasonable to me.

Thanks @robehn for reviewing.

I think this is trivial and it's just adding more test cases. So I will push with one reviewer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20630#issuecomment-2301687281

From liach at openjdk.org  Wed Aug 21 12:01:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 12:01:12 GMT
Subject: Integrated: 8338545: Functional interface implementations for common
 pre-boot ClassFile operations
In-Reply-To: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
References: <4hCJANOeSs1UraPZJMs2b5imSGibl2hTjfcISMSk53c=.4931be79-fdb3-48a0-8606-51576756f57e@github.com>
Message-ID: <MRMJHY5DuDQLXSI5z0CaayVfV3wU9DEbd4zlVbs7Ghk=.24fdae1c-2444-4629-ae62-8db59c784357@github.com>

On Mon, 19 Aug 2024 15:57:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> Some ad-hoc lambdas and classes for functional calls to ClassFile API in early bootstrap can be replaced with a few fixed factories. This allows some methods to be used at early bootstrap with less class loading costs.
> 
> Depends on #20627, as this adds another fix to one of the fixes there on `ClassBuilder::withMethodBody(String, MethodTypeDesc, int, Consumer)`.

This pull request has now been integrated.

Changeset: 80adea8e
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80adea8e0ab3753c3623267c6a2bd3eaed69ad29
Stats:     139 lines in 11 files changed: 33 ins; 63 del; 43 mod

8338545: Functional interface implementations for common pre-boot ClassFile operations

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20629

From mcimadamore at openjdk.org  Wed Aug 21 13:24:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Aug 2024 13:24:15 GMT
Subject: RFR: 8338728: Misc issues in memory layout javadoc [v2]
In-Reply-To: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>
References: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>
Message-ID: <CqqWAiXYveYtkmMYnoqD5ux-oUHni7bhLlI_fCl6eLY=.65a0d4e1-abc3-4c06-9c86-4e686d6ff85b@github.com>

> This PR fixes two minor issues in the `MemoryLayout` javadoc:
> * the section describing dereference path talks about `P` and `P'` but then only uses `P` in the code;
> * the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is wrong, as the division returns a negative number for F < 0, which is incorrect

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Clarify javadoc for var handles with dereference path elements
  * Add test where dereference path element is last element in path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20659/files
  - new: https://git.openjdk.org/jdk/pull/20659/files/8a8b0c7b..8079981b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20659&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20659&range=00-01

  Stats: 29 lines in 2 files changed: 25 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20659.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20659/head:pull/20659

PR: https://git.openjdk.org/jdk/pull/20659

From mcimadamore at openjdk.org  Wed Aug 21 13:31:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Aug 2024 13:31:31 GMT
Subject: RFR: 8338731: MemoryLayout::offsetHandle can return a negative offset
Message-ID: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>

When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.

In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.

The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/20662/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338731
  Stats: 23 lines in 3 files changed: 14 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20662/head:pull/20662

PR: https://git.openjdk.org/jdk/pull/20662

From dl at openjdk.org  Wed Aug 21 14:06:39 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 21 Aug 2024 14:06:39 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
 [v2]
In-Reply-To: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
Message-ID: <I55E7Y43mo8GNJAcLxsxkWSDQOkm4UH62fbILeZQTfY=.478c23ae-7e85-4408-b1c1-b82b8741a875@github.com>

> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8338146
 - Merge branch 'openjdk:master' into JDK-8338146
 - Copyedit
 - Address review suggestions
 - Initial re-implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20554/files
  - new: https://git.openjdk.org/jdk/pull/20554/files/a25520bb..18ddba40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20554&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20554&range=00-01

  Stats: 16217 lines in 511 files changed: 10366 ins; 3587 del; 2264 mod
  Patch: https://git.openjdk.org/jdk/pull/20554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20554/head:pull/20554

PR: https://git.openjdk.org/jdk/pull/20554

From dl at openjdk.org  Wed Aug 21 14:09:05 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 21 Aug 2024 14:09:05 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
Message-ID: <dRDFBCcJy3P7kPcDcsjb8YUCgs3BIunkd78g7SbbeKk=.543b0ca8-b2d5-4c60-a2db-1d620796e610@github.com>

On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea <dl at openjdk.org> wrote:

> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

I had forgotten that there was already a stripped-down jtreg version of an Exchanger test in test/jdk/java/util/concurrent/Exchanger. So I updated it to include virtual, platform and mixes. (Also including enough iterations and stages to reduce noisiness. Here's a sample run:
Warmup...
Threads: 2 PLATFORM	:       195 ns per transfer
Threads: 3 PLATFORM	:       226 ns per transfer
Threads: 4 PLATFORM	:       172 ns per transfer
Threads: 5 PLATFORM	:       148 ns per transfer
Threads: 6 PLATFORM	:       123 ns per transfer
Threads: 7 PLATFORM	:       100 ns per transfer
Threads: 8 PLATFORM	:        96 ns per transfer
Threads: 9 PLATFORM	:        78 ns per transfer
Threads: 2 VIRTUAL	:       185 ns per transfer
Threads: 3 VIRTUAL	:       223 ns per transfer
Threads: 4 VIRTUAL	:       194 ns per transfer
Threads: 5 VIRTUAL	:       139 ns per transfer
Threads: 6 VIRTUAL	:       121 ns per transfer
Threads: 7 VIRTUAL	:       118 ns per transfer
Threads: 8 VIRTUAL	:       190 ns per transfer
Threads: 9 VIRTUAL	:        79 ns per transfer
Threads: 2 MIXED	:       161 ns per transfer
Threads: 3 MIXED	:       196 ns per transfer
Threads: 4 MIXED	:       164 ns per transfer
Threads: 5 MIXED	:       146 ns per transfer
Threads: 6 MIXED	:       123 ns per transfer
Threads: 7 MIXED	:       106 ns per transfer
Threads: 8 MIXED	:       102 ns per transfer
Threads: 9 MIXED	:        87 ns per transfer

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20554#issuecomment-2302143653

From rgiulietti at openjdk.org  Wed Aug 21 14:13:15 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 21 Aug 2024 14:13:15 GMT
Subject: RFR: 8316662: Remove one allocation per conversion in
 Double.toString(double) and Float.toString(float) [v4]
In-Reply-To: <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>
References: <ktZDmC-1cjJNkiYuIvbPzNWNSoffSbGAVtTFYLhBCbI=.9e41dd82-3dd7-4bfd-943c-35b1fae10a47@github.com>
 <dBIjji1datjdEFJqOoMhrAn6uytM5P1NtegTelf2H_o=.4839e626-0dbf-46c7-b6b6-ce1a1a005383@github.com>
Message-ID: <7T6JurRloG0mEAqJG0sILpynCWUFAWyjrupkNyyuAEU=.2b078b38-539c-4c6a-aa5e-c371a95b8652@github.com>

On Tue, 30 Apr 2024 08:44:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> By correctly sizing an intermediate `byte[]` and making use of the internal `newStringNoRepl()` method, one allocation per conversion can be avoided when the runtime uses compact strings.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8316662
>  - Merge branch 'master' into 8316662
>  - Uppercase JLA.
>  - 8316662: Remove one allocation per conversion in Double.toString(double) and Float.toString(float)

Will continue on this in the more encompassing context of ongoing work in String concatenation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15861#issuecomment-2302152348

From alan.bateman at oracle.com  Wed Aug 21 14:19:50 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 21 Aug 2024 15:19:50 +0100
Subject: concurrency-discuss mailing list
Message-ID: <ae3c1a69-53d9-4c4c-87e4-82415ac7d204@oracle.com>


For many years, concurrency-interest was the mailing list to discuss 
j.u.concurrent and related topics. The mailing list was hosted on a 
server maintained by Prof. Doug Lea. Sadly, the mailing list didn't 
survive an OS upgrade and has been unavailable for some time.

A new mailing list concurrency-discuss at openjdk.org [1] has been created 
to replace the old list.? It's a completely new list, the archives and 
subscribers from the previous mailing list have not carried over. As the 
name suggests, the mailing list is for discussion of the j.u.concurrent 
API/implementation and related topics. It's not the place for support 
questions.

-Alan

[1] https://mail.openjdk.org/mailman/listinfo/concurrency-discuss

From mgronlun at openjdk.org  Wed Aug 21 14:31:03 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 Aug 2024 14:31:03 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v3]
In-Reply-To: <rZAAk5to5rc1xBmZONFr02MtB_Pq-VU8A5j8XywU-F0=.94a7d53f-df74-4f4c-afce-f00d516cd504@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>
 <zAW8mAquOAoa1B9hs-tcOCiL20LMQU5Tl_mbT6yxB1E=.d5cf093c-871f-4838-b5a0-ee5ec737b166@github.com>
 <0INfIrm9TACgn075XGV2jWKju2Pfk5-yvbSOM3s_54Y=.43e8ef44-ef35-49ab-b2ba-38d023f7b465@github.com>
 <rZAAk5to5rc1xBmZONFr02MtB_Pq-VU8A5j8XywU-F0=.94a7d53f-df74-4f4c-afce-f00d516cd504@github.com>
Message-ID: <BuLvgtEoTEudWUMjiU6ATaiZz7pR_fQebXESvIm3FFM=.edaf13e5-96dd-4908-ba94-3e2709051cf7@github.com>

On Thu, 15 Aug 2024 14:32:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Would it be possible to create a boolean in the EventWriter that indicates if it is associated with a carrier thread or a normal thread (which can never be virtual) and then have two methods.
>> 
>>     long l = this.carrierThread ? StringPool.addPinnedString(s) : StringPool.addString(s);
>
> Thread.currentThread() has an intrinsic, and isVirtual is just a type check. ContinuationSupport.isSupported reads a static final so will disappear once compiled. The pattern we are using in other areas is for the pin to return a boolean (like David suggested).

I looked into this in more detail. The current suggestion:

mov    r10,QWORD PTR [r15+0x388]  ; _vthread OopHandle
mov    r10,QWORD PTR [r10]              ; dereference OopHandle <<-- Thread.currentThread() intrinsic gives 2 instructions
mov    r11d,DWORD PTR [r10+0x8]    ; InstanceKlass to r11 <-- isVirtual()
mov    r10d,r11d                                 ; InstanceKlass to r10
mov    r8,QWORD PTR [r10+0x40]      ; Load slot in InstanceKlass primary supers array to r8
movabs r10,0x2d0481a8                     ; InstanceKlass for {metadata('java/lang/BaseVirtualThread')} to r10
cmp    r8,r10                                       ; compare if superklass is java/lang/BaseVirtualThread
jne    0x0000018571e0baf9                ; 6 instructions for isVirtual() type check, 8 instructions in total

This gives a prologue of eight instructions.

For JFR, we already have much of this information resolved when loading up the EventWriter instance using the existing intrinsic getEventWriter(). Hence, we could extend that to mark the event writer with a field to say if pinning should be performed. This results in only a two instruction prologue:

test   r8d,r8d                         ; pinVirtualThread? 
je     0x0000012580a0f6c9    ; 2 instructions for test

This is an x4 speedup, although slightly less because of an additional store instruction for loading the event writer.

Further, I looked into the Continuation.pin() and Continuation.unpin() methods. They are currently not intrinsics, but lend themselves well to intrinsification. I have created such intrinsics, and the results are quite good.

Continuation.pin() or Continuation.unpin() without intrinsics = 112 instructions each
Continuation.pin() or Continuation.unpin() with intrinsics = 8 instructions each

This is an x14 speedup for virtual threads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1725145256

From mgronlun at openjdk.org  Wed Aug 21 14:31:03 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 Aug 2024 14:31:03 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v3]
In-Reply-To: <BuLvgtEoTEudWUMjiU6ATaiZz7pR_fQebXESvIm3FFM=.edaf13e5-96dd-4908-ba94-3e2709051cf7@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <T7IP8zHJFwPlF2yFkXjWuCtayHrgQEWlR-pNgG-IDoo=.6680160f-1879-4ee1-93ac-9cdb01e8de5e@github.com>
 <zAW8mAquOAoa1B9hs-tcOCiL20LMQU5Tl_mbT6yxB1E=.d5cf093c-871f-4838-b5a0-ee5ec737b166@github.com>
 <0INfIrm9TACgn075XGV2jWKju2Pfk5-yvbSOM3s_54Y=.43e8ef44-ef35-49ab-b2ba-38d023f7b465@github.com>
 <rZAAk5to5rc1xBmZONFr02MtB_Pq-VU8A5j8XywU-F0=.94a7d53f-df74-4f4c-afce-f00d516cd504@github.com>
 <BuLvgtEoTEudWUMjiU6ATaiZz7pR_fQebXESvIm3FFM=.edaf13e5-96dd-4908-ba94-3e2709051cf7@github.com>
Message-ID: <SBRo2oIYU6TBOTlxjIUVUDbN_PfHiapKOe_AekG9IjE=.1d106973-9818-4ed2-935e-fb2276b40b2d@github.com>

On Wed, 21 Aug 2024 14:21:39 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Thread.currentThread() has an intrinsic, and isVirtual is just a type check. ContinuationSupport.isSupported reads a static final so will disappear once compiled. The pattern we are using in other areas is for the pin to return a boolean (like David suggested).
>
> I looked into this in more detail. The current suggestion:
> 
> mov    r10,QWORD PTR [r15+0x388]  ; _vthread OopHandle
> mov    r10,QWORD PTR [r10]              ; dereference OopHandle <<-- Thread.currentThread() intrinsic gives 2 instructions
> mov    r11d,DWORD PTR [r10+0x8]    ; InstanceKlass to r11 <-- isVirtual()
> mov    r10d,r11d                                 ; InstanceKlass to r10
> mov    r8,QWORD PTR [r10+0x40]      ; Load slot in InstanceKlass primary supers array to r8
> movabs r10,0x2d0481a8                     ; InstanceKlass for {metadata('java/lang/BaseVirtualThread')} to r10
> cmp    r8,r10                                       ; compare if superklass is java/lang/BaseVirtualThread
> jne    0x0000018571e0baf9                ; 6 instructions for isVirtual() type check, 8 instructions in total
> 
> This gives a prologue of eight instructions.
> 
> For JFR, we already have much of this information resolved when loading up the EventWriter instance using the existing intrinsic getEventWriter(). Hence, we could extend that to mark the event writer with a field to say if pinning should be performed. This results in only a two instruction prologue:
> 
> test   r8d,r8d                         ; pinVirtualThread? 
> je     0x0000012580a0f6c9    ; 2 instructions for test
> 
> This is an x4 speedup, although slightly less because of an additional store instruction for loading the event writer.
> 
> Further, I looked into the Continuation.pin() and Continuation.unpin() methods. They are currently not intrinsics, but lend themselves well to intrinsification. I have created such intrinsics, and the results are quite good.
> 
> Continuation.pin() or Continuation.unpin() without intrinsics = 112 instructions each
> Continuation.pin() or Continuation.unpin() with intrinsics = 8 instructions each
> 
> This is an x14 speedup for virtual threads.

I plan to fix the event writer under this PR (to be updated) and file a separate tracking enhancement for the intrinsification of Continuation.pin() and Continuation.unpin().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20588#discussion_r1725150866

From duke at openjdk.org  Wed Aug 21 14:44:11 2024
From: duke at openjdk.org (duke)
Date: Wed, 21 Aug 2024 14:44:11 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
Message-ID: <RVCbDXUaMQq1cOQqMyAHeJdjE9wcjYPb0CplXtWgikM=.c4ab8ad4-f024-4cd5-b8f5-a19f5a7ba78c@github.com>

On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove specialization for `Ljava/lang/Object;`

@wenshao 
Your change (at version 43fbe47bec0ecd813ce82bedfd69e0ec7b16dd49) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2302220625

From liach at openjdk.org  Wed Aug 21 14:59:12 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 14:59:12 GMT
Subject: RFR: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor [v3]
In-Reply-To: <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
 <Uwi7m86_52WCvUNzuDIkJtEgjVEt82bwVt1o6HmWzrQ=.2187ba4d-2e75-4172-9c6f-4824a88dc56e@github.com>
Message-ID: <SwvgwGAjLF9ySlz4tIOC1Y76r6FrkwH93CeRvWMg_w8=.55dd9b2c-5084-442f-a92b-b8a79295a3ba@github.com>

On Tue, 20 Aug 2024 12:39:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
>> 
>> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove specialization for `Ljava/lang/Object;`

Thanks for your performance improvement without too much impact on the long descriptor cases!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20611#issuecomment-2302258488

From duke at openjdk.org  Wed Aug 21 14:59:12 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 21 Aug 2024 14:59:12 GMT
Subject: Integrated: 8338532: Speed up the ClassFile API
 MethodTypeDesc#ofDescriptor
In-Reply-To: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
References: <e8OR4mFx_uFo7McwHQ1NpBCiSjEHVZMWxtcLytR80Ek=.f50fcbfd-470c-438c-9ede-bbc18f1ca29c@github.com>
Message-ID: <RFjy9HOC2RXimPPwYCsx0ujFawtP8PMDNfQ5kj5rKbg=.df311534-ffa1-4aa6-b734-e838b681cb03@github.com>

On Fri, 16 Aug 2024 08:53:38 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> The current implementation of ofDescriptor puts return type and parameter types together in an ArrayList, and then splits them into return type and array of parameter types. This ArrayList creation is unnecessary, considering most descriptors only have few parameter types.
> 
> By splitting return type and parameter types separately and scanning the descriptor first to get the number of parameters, we can just allocate an exact, trusted array for the resulting MethodTypeDesc without copy.

This pull request has now been integrated.

Changeset: 3aeb6733
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3aeb6733f958bc2b0132494b8ac51a4cfa6b98de
Stats:     263 lines in 11 files changed: 152 ins; 61 del; 50 mod

8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor

Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20611

From mcimadamore at openjdk.org  Wed Aug 21 15:14:08 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Aug 2024 15:14:08 GMT
Subject: Integrated: 8338677: Improve startup of memory access var handles by
 simplifying combinator chains
In-Reply-To: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
References: <SHt6b9jxLTO75oiGn7pCSkq5z35ev0mtQix98qsaDn4=.60a89a7f-7419-4ec1-b0fa-2f2b0ed47f77@github.com>
Message-ID: <ZE2BDYfWpdL9Ev0_lZ2MsjQUPbvPuFDTy-n4lSXTjPU=.05b6d26a-fe85-458c-b90f-d15551711a13@github.com>

On Tue, 20 Aug 2024 15:05:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR reduces the amount of lambda forms (LFs) which are created when generating var handles for simple struct field accessors. This contributes to the startup regression seen in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505).
> 
> There are essentially three sources of excessive var handle adaptation:
> 
> 1. `LayoutPath::dereferenceHandle` has to do some very complex adaptation (including a permute) in order to inject alignment and size checks (against the enclosing layout) on the generated var handle.
> 2. Even in simple cases (e.g. when there's no dynamic coordinate), the offset of the accessed field is added to the var handle via an expensive collect adapter.
> 3. When we adapt a `long` var handle to work on `MemorySegment` using an `AddressLayout`, we make no distinction on whether the address layout has a target layout or not. In the latter case (common!) we can adapt more simply.
> 
> The meat of this PR is to address (1) by changing the shape of the generated helpers in the `X-VarHandleSegmentView.java.template` class. That is, the method for doing a plain get will now have the following shape:
> 
> 
> T get(MemorySegment segment, MemoryLayout enclosing, long base, long offset)
> 
> 
> Where:
> * `segment` is the segment being accessed
> * `enclosing` is the enclosing layout (the root of the selected layout path) against which to check size and alignment
> * `base` is the public-facing offset passed by the user when calling `get` on the var handle
> * `offset` is the offset at which the selected layout element can be found from the root (this can be replaced with an expression that takes several dynamic indices and turn them into a single offset)
> 
> With this organization, it is easy to see how, in order to create a memory access var handle for a struct field `S.f` we only need to:
> * inject the enclosing layout `S` into the var handle (into the `enclosing` coordinate)
> * inject the offset of `S.f` into the var handle (into the `offset` coordinate)
> 
> This way, we get our plain old memory access var handle featuring only two coordinates: a segment and an offset. Note how, to get there, we only needed very simple adaptations (e.g. `MethodHandles::insertCoordinates`).
> 
> #### Evaluation
> 
> I did some tests using the benchmark in [JDK-8337505](https://bugs.openjdk.org/browse/JDK-8337505) to assess the impact of this change on startup. To evaluate startup, I ran the benchmark 50 times and then took some stats. Here's what the numbers look before this change (AVG = average, MED = med...

This pull request has now been integrated.

Changeset: 0e8fe355
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e8fe3550b628c6617ac7593d7e17ef7d9bc0869
Stats:     179 lines in 4 files changed: 29 ins; 11 del; 139 mod

8338677: Improve startup of memory access var handles by simplifying combinator chains

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20647

From liach at openjdk.org  Wed Aug 21 15:42:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 15:42:18 GMT
Subject: RFR: 8336275: Move common Method and Constructor fields to
 Executable [v3]
In-Reply-To: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
Message-ID: <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>

> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
> 
> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Fix after merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
 - Redundant transient; Update the comments to be more accurate
 - Inline some common ctor + method fields to executable

-------------

Changes: https://git.openjdk.org/jdk/pull/20188/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20188&range=02
  Stats: 448 lines in 11 files changed: 77 ins; 238 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/20188.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20188/head:pull/20188

PR: https://git.openjdk.org/jdk/pull/20188

From liach at openjdk.org  Wed Aug 21 16:03:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 16:03:15 GMT
Subject: RFR: 8336267: Method and Constructor signature parsing can be
 shared on the root object [v2]
In-Reply-To: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
References: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
Message-ID: <anYcT-cn6iiIpY_-MjtbBjQrDdK9G7zC5hhHYNpF17Y=.132cea80-07b0-4c2b-8c1a-c6d724fecace@github.com>

> A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/member-sig-share
 - 8336267: Method and Constructor signature parsing can be shared on the root object

-------------

Changes: https://git.openjdk.org/jdk/pull/20179/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20179&range=01
  Stats: 30 lines in 3 files changed: 19 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20179/head:pull/20179

PR: https://git.openjdk.org/jdk/pull/20179

From sgehwolf at openjdk.org  Wed Aug 21 16:24:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 16:24:35 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v3]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <nNPB0RoI4lDKKUF4qQVrSP2wYfVoSjZm0TO3pePG0QA=.9090dfbe-21a6-4e0d-b12a-2addee089952@github.com>

> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
> 
> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
> 
> This patch addresses this issue by:
> 
> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
> 
> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
> 
> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
> 
> Thoughts?
> 
> Testing:
> 
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8336881: [Linux] Support for hierarchical limits for Metrics

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=02
  Stats: 1511 lines in 24 files changed: 1260 ins; 152 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280

PR: https://git.openjdk.org/jdk/pull/20280

From sgehwolf at openjdk.org  Wed Aug 21 16:24:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 16:24:36 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v2]
In-Reply-To: <T6lxwKGTSUFi2Z0YRBuIFa-zjObgFgwrjxNpJ3Qh2SE=.3ccbe801-4df3-4410-b9a7-b25d5750f63a@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <T6lxwKGTSUFi2Z0YRBuIFa-zjObgFgwrjxNpJ3Qh2SE=.3ccbe801-4df3-4410-b9a7-b25d5750f63a@github.com>
Message-ID: <OzFNP9fiTAUAy4LBKgISlfKdp5TCIScoSwbHQC8Cl7Y=.32bddc01-5a16-4743-8a45-414ea1898490@github.com>

On Mon, 29 Jul 2024 14:18:24 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - 8336881: [Linux] Support for hierarchical limits for Metrics
>  - Unify 4 copies of adjust_controller()
>  - Fix a needless whitespace change

Moving to draft. Needs the hotspot fix which gets a reboot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2296180545

From coleenp at openjdk.org  Wed Aug 21 16:38:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Aug 2024 16:38:16 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
Message-ID: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>

This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.

Tested with tier1-8.

-------------

Commit messages:
 - 8338526: Don't store abstract and interface Klasses in class metaspace

Changes: https://git.openjdk.org/jdk/pull/19157/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338526
  Stats: 71 lines in 17 files changed: 31 ins; 6 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/19157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19157/head:pull/19157

PR: https://git.openjdk.org/jdk/pull/19157

From sgehwolf at openjdk.org  Wed Aug 21 16:40:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 16:40:09 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
Message-ID: <njnevx4sIxqFmlgHIptS0Zdh2GsD7DXhgnRTeGCZvE4=.10a29950-ebf6-4ad5-8f75-0011ec2cd38c@github.com>

On Tue, 20 Aug 2024 17:34:46 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

@dholmes-ora @iklam @MBaesken Could somebody of you help review this, please? Increases test coverage in the container detection area. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2302519288

From jbhateja at openjdk.org  Wed Aug 21 16:42:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 21 Aug 2024 16:42:44 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Pass explicit wrap argument to selectFrom API with default value set to true.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/055fb22f..e24632cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=01-02

  Stats: 491 lines in 40 files changed: 430 ins; 1 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From coleenp at openjdk.org  Wed Aug 21 16:44:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Aug 2024 16:44:08 GMT
Subject: RFR: 8336275: Move common Method and Constructor fields to
 Executable [v3]
In-Reply-To: <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
 <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>
Message-ID: <lekZIxoiaez-c0J8e5CRPYxJCt5krkfktbrpZN-OP_o=.a7676312-eabd-45f5-9e90-8a6a810c6ae6@github.com>

On Wed, 21 Aug 2024 15:42:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
>> 
>> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
>  - Redundant transient; Update the comments to be more accurate
>  - Inline some common ctor + method fields to executable

src/hotspot/share/classfile/javaClasses.cpp line 3308:

> 3306:   macro(_name_offset,           k, vmSymbols::name_name(),           string_signature,      false); \
> 3307:   macro(_returnType_offset,     k, vmSymbols::returnType_name(),     class_signature,       false); \
> 3308:   macro(_annotation_default_offset,    k, vmSymbols::annotation_default_name(),    byte_array_signature, false);

Can you re-align these since you modified them?

src/hotspot/share/classfile/javaClasses.cpp line 3323:

> 3321: Handle java_lang_reflect_Method::create(TRAPS) {
> 3322:   assert(Universe::is_fully_initialized(), "Need to find another solution to the reflection problem");
> 3323:   Klass* klass = vmClasses::reflect_Method_klass();

This also does not need a cast, vmClasses::reflect_Method_klass() returns an InstanceKlass.

src/hotspot/share/classfile/javaClasses.cpp line 3351:

> 3349:   assert(Universe::is_fully_initialized(), "Need to find another solution to the reflection problem");
> 3350:   Klass* k = vmClasses::reflect_Constructor_klass();
> 3351:   InstanceKlass* ik = InstanceKlass::cast(k);

This doesn't need a cast because vmClasses returns InstanceKlass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1725402105
PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1725403135
PR Review Comment: https://git.openjdk.org/jdk/pull/20188#discussion_r1725399269

From coleenp at openjdk.org  Wed Aug 21 16:47:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Aug 2024 16:47:05 GMT
Subject: RFR: 8336275: Move common Method and Constructor fields to
 Executable [v3]
In-Reply-To: <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>
References: <nYtWyeRXdAr_zmzpxdugyZNRUzhfHJUKX1K2ilpSs8A=.cb1c31be-a7e0-49b5-ab9b-18a3abd122a9@github.com>
 <YeTi7UqS3alQLoe3h122TL8A_BLGWYbiyuzFJzS-qA4=.158d3b64-bf1c-43ca-b184-9368f4fac14a@github.com>
Message-ID: <PzUPS_cQYVP8n9XOOC_P-h9bpfjHcUa3S3n0wU0ly7s=.fef0c828-f94c-48ee-9e5c-3411d8567db1@github.com>

On Wed, 21 Aug 2024 15:42:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Move fields common to Method and Field to executable, which simplifies implementation. Removed useless transient modifiers as Method and Field were never serializable.
>> 
>> Note to core-libs reviewers: Please review the associated CSR on trivial removal of `abstract` modifier as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Fix after merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/executable-inline
>  - Redundant transient; Update the comments to be more accurate
>  - Inline some common ctor + method fields to executable

The hotspot code looks okay, but I have a couple of small cleanup requests in the changes.

-------------

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20188#pullrequestreview-2251378680

From jbhateja at openjdk.org  Wed Aug 21 16:52:06 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 21 Aug 2024 16:52:06 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
Message-ID: <WviQePGItPdywf_OoxyKv7e27BjSBgj4j6RW56Uk3ro=.19b96c49-b24b-4bc9-adc7-312f3d22e54a@github.com>

On Wed, 21 Aug 2024 16:42:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass explicit wrap argument to selectFrom API with default value set to true.

Hi @rose00 , @sviswa7 , @PaulSandoz , 
As suggested, now passing explicit 'wrap' argument to new selectFrom API.

Following are the performance number of modified JMH micro included with the patch.



Baseline:-
Benchmark                                      (size)   Mode  Cnt     Score   Error   Units
SelectFromBenchmark.rearrangeFromByteVector     4096  thrpt    2  5849.771          ops/ms
SelectFromBenchmark.rearrangeFromDoubleVector   4096  thrpt    2   430.712          ops/ms
SelectFromBenchmark.rearrangeFromFloatVector    4096  thrpt    2   942.737          ops/ms
SelectFromBenchmark.rearrangeFromIntVector      4096  thrpt    2  1057.695          ops/ms
SelectFromBenchmark.rearrangeFromLongVector     4096  thrpt    2   616.360          ops/ms
SelectFromBenchmark.rearrangeFromShortVector    4096  thrpt    2  2146.465          ops/ms

With Patch:-
Benchmark                                   (size)   Mode  Cnt     Score   Error   Units
SelectFromBenchmark.selectFromByteVector        4096  thrpt    2  9543.775          ops/ms
SelectFromBenchmark.selectFromDoubleVector      4096  thrpt    2   558.195          ops/ms
SelectFromBenchmark.selectFromFloatVector       4096  thrpt    2  1325.059          ops/ms
SelectFromBenchmark.selectFromIntVector         4096  thrpt    2  1418.748          ops/ms
SelectFromBenchmark.selectFromLongVector        4096  thrpt    2   687.231          ops/ms
SelectFromBenchmark.selectFromShortVector       4096  thrpt    2  4782.395          ops/ms


With WIP wrap index acceleration PR#20634:
Benchmark                                      (size)   Mode  Cnt     Score   Error   Units
SelectFromBenchmark.rearrangeFromByteVector     4096  thrpt    2  7602.645          ops/ms
SelectFromBenchmark.rearrangeFromDoubleVector   4096  thrpt    2   441.684          ops/ms
SelectFromBenchmark.rearrangeFromFloatVector    4096  thrpt    2   926.112          ops/ms
SelectFromBenchmark.rearrangeFromIntVector      4096  thrpt    2  1061.695          ops/ms
SelectFromBenchmark.rearrangeFromLongVector     4096  thrpt    2   644.058          ops/ms
SelectFromBenchmark.rearrangeFromShortVector    4096  thrpt    2  2777.735          ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2302541724

From liach at openjdk.org  Wed Aug 21 17:34:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 17:34:02 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <wBJF_MJ6Q93cPNG7DeePLM9cjxCzZWPxcxF3WIlLTA0=.9149697b-c043-42f4-a10b-19e8433703f4@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

java.lang.invoke changes look good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2251483857

From alanb at openjdk.org  Wed Aug 21 17:48:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Aug 2024 17:48:09 GMT
Subject: RFR: 8338146: Improve Exchanger performance with VirtualThreads
 [v2]
In-Reply-To: <I55E7Y43mo8GNJAcLxsxkWSDQOkm4UH62fbILeZQTfY=.478c23ae-7e85-4408-b1c1-b82b8741a875@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
 <I55E7Y43mo8GNJAcLxsxkWSDQOkm4UH62fbILeZQTfY=.478c23ae-7e85-4408-b1c1-b82b8741a875@github.com>
Message-ID: <np3Qd2xD_pzYkJ9Gq3ZnVik_cPk3oI1qAbmqujAMzKk=.129b8bca-5f95-459c-a9f5-4b24441df337@github.com>

On Wed, 21 Aug 2024 14:06:39 GMT, Doug Lea <dl at openjdk.org> wrote:

>> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8338146
>  - Merge branch 'openjdk:master' into JDK-8338146
>  - Copyedit
>  - Address review suggestions
>  - Initial re-implementation

Tests aside, the update to Exchanger makes sense.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20554#pullrequestreview-2251509992

From sviswanathan at openjdk.org  Wed Aug 21 17:51:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Aug 2024 17:51:06 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <WviQePGItPdywf_OoxyKv7e27BjSBgj4j6RW56Uk3ro=.19b96c49-b24b-4bc9-adc7-312f3d22e54a@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
 <WviQePGItPdywf_OoxyKv7e27BjSBgj4j6RW56Uk3ro=.19b96c49-b24b-4bc9-adc7-312f3d22e54a@github.com>
Message-ID: <Htk1HZnSMlec_YJO3PtIwqSNR6-JPNo4MZo5rKa8adg=.f87fc739-5534-4dfa-bc9f-c100614cd2d1@github.com>

On Wed, 21 Aug 2024 16:49:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass explicit wrap argument to selectFrom API with default value set to true.
>
> Hi @rose00 , @sviswa7 , @PaulSandoz , 
> As suggested, now passing explicit 'wrap' argument to new selectFrom API.
> 
> Following are the performance number of modified JMH micro included with the patch.
> 
> 
> 
> Baseline:-
> Benchmark                                      (size)   Mode  Cnt     Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     4096  thrpt    2  5849.771          ops/ms
> SelectFromBenchmark.rearrangeFromDoubleVector   4096  thrpt    2   430.712          ops/ms
> SelectFromBenchmark.rearrangeFromFloatVector    4096  thrpt    2   942.737          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      4096  thrpt    2  1057.695          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     4096  thrpt    2   616.360          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    4096  thrpt    2  2146.465          ops/ms
> 
> With Patch:-
> Benchmark                                   (size)   Mode  Cnt     Score   Error   Units
> SelectFromBenchmark.selectFromByteVector        4096  thrpt    2  9543.775          ops/ms
> SelectFromBenchmark.selectFromDoubleVector      4096  thrpt    2   558.195          ops/ms
> SelectFromBenchmark.selectFromFloatVector       4096  thrpt    2  1325.059          ops/ms
> SelectFromBenchmark.selectFromIntVector         4096  thrpt    2  1418.748          ops/ms
> SelectFromBenchmark.selectFromLongVector        4096  thrpt    2   687.231          ops/ms
> SelectFromBenchmark.selectFromShortVector       4096  thrpt    2  4782.395          ops/ms
> 
> 
> With WIP wrap index acceleration PR#20634:
> Benchmark                                      (size)   Mode  Cnt     Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     4096  thrpt    2  7602.645          ops/ms
> SelectFromBenchmark.rearrangeFromDoubleVector   4096  thrpt    2   441.684          ops/ms
> SelectFromBenchmark.rearrangeFromFloatVector    4096  thrpt    2   926.112          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      4096  thrpt    2  1061.695          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     4096  thrpt    2   644.058          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    4096  thrpt    2  2777.735          ops/ms

@jatin-bhateja Thanks, the PR ((https://github.com/openjdk/jdk/pull/20634) is still work in progress and can be simplified much further. The changes I am currently working on are do wrap by default for rearrange and selectFrom as suggested by John and Paul, no additional api with boolean wrap as parameter, and no changes to shuffle constructors.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2302641840

From mgronlun at openjdk.org  Wed Aug 21 18:21:26 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 Aug 2024 18:21:26 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v4]
In-Reply-To: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
Message-ID: <bXNtLsENEK8EA-6V7iFpXzARa9gdB86Ef7DjE3l2uR0=.39ef7228-a98f-47e3-a790-5a877b6a8bc4@github.com>

> Greetings,
> 
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
> 
> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
> 
> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
> 
> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8338417
 - update test comment
 - hoist pinVirtualThread
 - 8338417

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20588/files
  - new: https://git.openjdk.org/jdk/pull/20588/files/b96b411f..2cf0c2cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20588&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20588&range=02-03

  Stats: 13476 lines in 362 files changed: 8560 ins; 3146 del; 1770 mod
  Patch: https://git.openjdk.org/jdk/pull/20588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20588/head:pull/20588

PR: https://git.openjdk.org/jdk/pull/20588

From dl at openjdk.org  Wed Aug 21 18:25:07 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 21 Aug 2024 18:25:07 GMT
Subject: Integrated: 8338146: Improve Exchanger performance with VirtualThreads
In-Reply-To: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
References: <qi6LMfx6cCREzDeQHUikMFLZ5pbjljeQ2ZAle6_XvMw=.e41caf0a-8828-41ce-9858-a97327237b23@github.com>
Message-ID: <PGsgSZAX97ER06ueM0KM6T0D1kbdPK3uB-NXvX4JFH8=.a0bd5da0-f553-4e9a-a29f-c03fffebb194@github.com>

On Mon, 12 Aug 2024 17:07:42 GMT, Doug Lea <dl at openjdk.org> wrote:

> The Exchanger class uses spin-waits that are hostile to some uses of VirtualThreads. Improving this requires a means of estimating whether there are many VirtualThreads with few carriers, which can be supported by adding a method in class ForkJoinWorkerThread. This enables a reworking of the exchange method, and can also be used to deal with similar issues in LinkedTransferQueue and possibly elsewhere. We leave for now open whether this method (hasKnownQueuedWork) should be public, which would allow users to use it in similar contexts, at the possible expense of revealing too much about current VT implementation

This pull request has now been integrated.

Changeset: ab8071d2
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab8071d28027ecbf5e8984c30b35fa1c2d934de7
Stats:     423 lines in 3 files changed: 94 ins; 172 del; 157 mod

8338146: Improve Exchanger performance with VirtualThreads

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20554

From mgronlun at openjdk.org  Wed Aug 21 18:26:20 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 Aug 2024 18:26:20 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v5]
In-Reply-To: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
Message-ID: <nT9FzW3e3iSRf8ViNqKxnpgNr3y68fh7NNbmUXGHAw8=.f9a5c6c3-ae25-4d61-90a2-6c287be83a19@github.com>

> Greetings,
> 
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
> 
> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
> 
> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
> 
> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with five additional commits since the last revision:

 - pin state conditional delivered using event writer object
 - Merge branch '8338417' of github.com:mgronlun/jdk into 8338417
 - update test comment
 - hoist pinVirtualThread
 - 8338417

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20588/files
  - new: https://git.openjdk.org/jdk/pull/20588/files/2cf0c2cb..fc2a1b6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20588&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20588&range=03-04

  Stats: 78 lines in 4 files changed: 48 ins; 11 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20588.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20588/head:pull/20588

PR: https://git.openjdk.org/jdk/pull/20588

From psandoz at openjdk.org  Wed Aug 21 18:30:06 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 21 Aug 2024 18:30:06 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
Message-ID: <MQmuxAUgxOEE8FpTGmGnS2eq0tlSguDlhcBmC8eIBxs=.1ef9b86b-1311-4e4d-a1c2-355e3d15ff70@github.com>

On Wed, 21 Aug 2024 16:42:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass explicit wrap argument to selectFrom API with default value set to true.

Is it possible for the intrinsic to be responsible for wrapping, if needed? If was looking at [`vpermi2b`](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=vpermi2b&ig_expand=4917,4982,5004,5010,5014&techs=AVX_512) and AFAICT it implicitly wraps, operating on the lower N bits. Is that correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2302707611

From john.r.rose at oracle.com  Wed Aug 21 18:40:15 2024
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 21 Aug 2024 11:40:15 -0700
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <Htk1HZnSMlec_YJO3PtIwqSNR6-JPNo4MZo5rKa8adg=.f87fc739-5534-4dfa-bc9f-c100614cd2d1@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
 <WviQePGItPdywf_OoxyKv7e27BjSBgj4j6RW56Uk3ro=.19b96c49-b24b-4bc9-adc7-312f3d22e54a@github.com>
 <Htk1HZnSMlec_YJO3PtIwqSNR6-JPNo4MZo5rKa8adg=.f87fc739-5534-4dfa-bc9f-c100614cd2d1@github.com>
Message-ID: <ACD9DC9E-1B58-463B-8B9E-FCDEBCA2534E@oracle.com>

On 21 Aug 2024, at 10:51, Sandhya Viswanathan wrote:

> @jatin-bhateja Thanks, the PR ((https://github.com/openjdk/jdk/pull/20634) is still work in progress and can be simplified much further. The changes I am currently working on are do wrap by default for rearrange and selectFrom as suggested by John and Paul, no additional api with boolean wrap as parameter, and no changes to shuffle constructors.

Yes, thank you Sandhya; this is the destination I hope to arrive at.
Not necessarily 100% in this PR, but this PR should be consistent with it.

?To review:  Shuffles store their indexes ?partially wrapped? so as
to preserve information about which indexes were out of bounds, but
they also preserve all index values mod VLEN.  It?s always an option,
though not a requirement, to fully wrap, removing the OOB info and
reducing every index down to 0..VLEN-1.  When using a vector instead
of a shuffle for steering, we think of this as creating a temp shuffle
first, then doing the appropriate operation(s).  But for best instruction
selection, we have found that it?s fastest to force everything down to
0..VLEN-1 immediately, at least in the vector case, and to a doubled
dynamic range, mod 2VLEN, for the two-input case.  There?s always an
equivalent expression which uses an explicit shuffle to carry either
VLEN (fully wrapped) or 2VLEN (partially wrapped) indexes.  For the
vector-steered version we implement only the most favorable pattern
of shuffle usage, one which never throws.  And of course we don?t
build a temp shuffle either.

From john.r.rose at oracle.com  Wed Aug 21 18:51:25 2024
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 21 Aug 2024 11:51:25 -0700
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <MQmuxAUgxOEE8FpTGmGnS2eq0tlSguDlhcBmC8eIBxs=.1ef9b86b-1311-4e4d-a1c2-355e3d15ff70@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
 <MQmuxAUgxOEE8FpTGmGnS2eq0tlSguDlhcBmC8eIBxs=.1ef9b86b-1311-4e4d-a1c2-355e3d15ff70@github.com>
Message-ID: <F2E0200B-2C9C-431C-91C6-86CC499DF858@oracle.com>

On 21 Aug 2024, at 11:30, Paul Sandoz wrote:

> Is it possible for the intrinsic to be responsible for wrapping, if needed? If was looking at [`vpermi2b`](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=vpermi2b&ig_expand=4917,4982,5004,5010,5014&techs=AVX_512) and AFAICT it implicitly wraps, operating on the lower N bits. Is that correct?

That?s not a bad idea.  But it is also possible (and routine) for the
JIT to take an expression like (i >> (j&31)) down to (i >> j) if the
hardware takes care of the (j&31) inside its >> operation.  I think
that some hardware permutation operations do something similar to >>
in that they simply ignore irrelevant bits in the steering indexes.
(Other operations do exotic things with irrelevant bits, such as
interpreting the sign bit as a command to ?force this one to zero?.)

If the wrapping operation for steering indexes is just a vpand against
a simple constant, then maybe (maybe!) the JIT can easily drop that
vpand, when the input is passed to a friendly auto-masking instruction,
just like with (i >> (j&31)).

On the other hand, Paul?s idea might be more robust.  It would require
that the permutation intrinsics would apply vpand at the right places,
and omit vpand when possible.

On the other other hand (the first hand) the classic way of doing it
doesn?t introduce vpand inside of intrinsics, which has a routine
advantage:  The vpands introduced outside of the intrinsic can be
user-introduced or framework-introduced or both.  In all cases, the
JIT treats them uniformly and can collapse them together.  Putting
magic fixup instructions inside of intrinsic expansion risks making
them invisible to the routine optimizations of the JIT.  So,
assuming the vpand gets good optimization, putting it outside of
the intrinsic is the most robust option, as long as ?good optimization?
includes the >>(j&31) trick for auto-masking instructions.  So the
intrinsic should look for a vpand in its steering input, and pop off
the IR node if the hardware masking is found to produce the same result.

From duke at openjdk.org  Wed Aug 21 19:00:10 2024
From: duke at openjdk.org (duke)
Date: Wed, 21 Aug 2024 19:00:10 GMT
Subject: Withdrawn: 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: <TBzaM0DNXG3QMBnMTDyFb31vSLs21nWz6lbLvRmIuEA=.756a2b81-e2e2-4678-ab2f-10dd598bf18f@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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19477

From acobbs at openjdk.org  Wed Aug 21 19:28:05 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 21 Aug 2024 19:28:05 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v8]
In-Reply-To: <nNq3TPZUnDm7cwv4eGdrpVo9ZySuW49POQdSzKC516g=.80105d2b-a8b5-4d61-a3b4-a9af41d3d0fd@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
 <KPJekWWCuR9cWpHdErYNr-IL9hQta8oytuvcolh6N-Q=.734dd820-0edf-462b-ac8a-d203b068a134@github.com>
 <nNq3TPZUnDm7cwv4eGdrpVo9ZySuW49POQdSzKC516g=.80105d2b-a8b5-4d61-a3b4-a9af41d3d0fd@github.com>
Message-ID: <qpDYk-kIuB0DySASqeetdhCWDS27D1bImXEP8uLPOcc=.a7c63bdb-06de-4601-85e2-0f6a15bbb02c@github.com>

On Wed, 31 Jul 2024 15:51:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration.
>> 
>> Then basically all we would be changing is no longer suppressing `IOException`'s.
>> 
>> And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage.
>> 
>> (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.)
>
>> Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration.
>> 
>> Then basically all we would be changing is no longer suppressing `IOException`'s.
>> 
>> And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage.
>> 
>> (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.)
> 
> We don't want to change this long standing behavior as it has the potential of breaking existing applications and it is consistent with gzip and also winzip.
> 
> So through this PR, we should clarify the javadoc as to what  current GZIPInputStream implementation  does  and add additional tests to  expand the coverage
> 
> A separate discussion can take place to discuss the merits of whether there is perceived value in throwing an IOException when trailing garbage is encountered as well as any benefit of not supporting concatenated gzip files.  It will also allow time for further review of other tools/apis that support gzip to see what they may or may not do.

@LanceAndersen & @jaikiran,

When you get a chance please review the [CSR](https://bugs.openjdk.org/browse/JDK-8330195) and let me know if you think the new wording is appropriate.

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2302856157

From lancea at openjdk.org  Wed Aug 21 19:32:09 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 21 Aug 2024 19:32:09 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v8]
In-Reply-To: <nNq3TPZUnDm7cwv4eGdrpVo9ZySuW49POQdSzKC516g=.80105d2b-a8b5-4d61-a3b4-a9af41d3d0fd@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <oCn3NvGM8kpVX9y6idPxOSIXdz7PIE7XajCUjjpb5Tg=.42e57274-d28e-4c99-95ce-0eb47c29fd33@github.com>
 <KPJekWWCuR9cWpHdErYNr-IL9hQta8oytuvcolh6N-Q=.734dd820-0edf-462b-ac8a-d203b068a134@github.com>
 <nNq3TPZUnDm7cwv4eGdrpVo9ZySuW49POQdSzKC516g=.80105d2b-a8b5-4d61-a3b4-a9af41d3d0fd@github.com>
Message-ID: <Fz8zh9ohVOU5G_k6yB5nM-Lw5RwXK-MPnMUGl1rdSsc=.d167c848-737c-44da-858d-ecc48cf4ba7f@github.com>

On Wed, 31 Jul 2024 15:51:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration.
>> 
>> Then basically all we would be changing is no longer suppressing `IOException`'s.
>> 
>> And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage.
>> 
>> (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.)
>
>> Another (more conservative) possibility is to preserve both 1 ("Trailing garbage is ignored") and 3 ("Concatenated streams are automatically decoded") in the default configuration.
>> 
>> Then basically all we would be changing is no longer suppressing `IOException`'s.
>> 
>> And then - as a separate remaining question - if we wanted to also provide more control there could be new constructor(s) to control concatenation and/or tolerance for trailing garbage.
>> 
>> (In all cases, I think using `mark()`/`reset()` (when available) to make trailing garbage detection precise is a good idea.)
> 
> We don't want to change this long standing behavior as it has the potential of breaking existing applications and it is consistent with gzip and also winzip.
> 
> So through this PR, we should clarify the javadoc as to what  current GZIPInputStream implementation  does  and add additional tests to  expand the coverage
> 
> A separate discussion can take place to discuss the merits of whether there is perceived value in throwing an IOException when trailing garbage is encountered as well as any benefit of not supporting concatenated gzip files.  It will also allow time for further review of other tools/apis that support gzip to see what they may or may not do.

> @LanceAndersen & @jaikiran,
> 
> When you get a chance please review the [CSR](https://bugs.openjdk.org/browse/JDK-8330195) and let me know if you think the new wording is appropriate.
> 
> Thanks.

It's on my list and I hope to get to it this week if not early next.  apologies for the delay, it has been a busy time with trying to wrap up some high priority items

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2302862254

From sviswanathan at openjdk.org  Wed Aug 21 19:34:06 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 21 Aug 2024 19:34:06 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <MQmuxAUgxOEE8FpTGmGnS2eq0tlSguDlhcBmC8eIBxs=.1ef9b86b-1311-4e4d-a1c2-355e3d15ff70@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
 <MQmuxAUgxOEE8FpTGmGnS2eq0tlSguDlhcBmC8eIBxs=.1ef9b86b-1311-4e4d-a1c2-355e3d15ff70@github.com>
Message-ID: <mIC5CL6tvUZGpWqTsJos3WeEqzEBH8D8cbsxQ3FvAjA=.85f9e8b5-f046-45c9-82e0-db8c4196cffb@github.com>

On Wed, 21 Aug 2024 18:27:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Is it possible for the intrinsic to be responsible for wrapping, if needed? If was looking at [`vpermi2b`](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=vpermi2b&ig_expand=4917,4982,5004,5010,5014&techs=AVX_512) and AFAICT it implicitly wraps, operating on the lower N bits. Is that correct?

It is good to keep wrapping separate. Two reasons: 1) Not all permute instructions do wrapping e.g. pshufb has a different behavior if MSB is set. 2) By keeping wrapping separate it can move out of the loop if shuffle is loop invariant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2302865908

From mgronlun at openjdk.org  Wed Aug 21 20:15:13 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 21 Aug 2024 20:15:13 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and Continuation.unpin()
Message-ID: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>

Greetings,

Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().

This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for VirtualThreads in a relatively performance-sensitive path.

Testing: jdk_jfr, loom testing

Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.

Thanks
Markus

-------------

Commit messages:
 - 8338745

Changes: https://git.openjdk.org/jdk/pull/20664/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338745
  Stats: 117 lines in 8 files changed: 113 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20664/head:pull/20664

PR: https://git.openjdk.org/jdk/pull/20664

From dlong at openjdk.org  Wed Aug 21 20:34:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 21 Aug 2024 20:34:03 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <0UeIWfhsJRNahI3I8r8wKfGlvWuY-0crKHqGxbPXk5o=.6b9ff3f1-f297-40f0-9c81-99507c2b2880@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 279:

> 277:         clb.withMethod(invokerName, invokerDesc, ACC_STATIC, config);
> 278:     }
> 279: 

There's probably not much value in using ACC_FINAL here anyway.  We are only using these classes to create static methods, right?  I think ACC_INTERFACE would work here too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1725721069

From liach at openjdk.org  Wed Aug 21 21:05:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 21:05:04 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <0UeIWfhsJRNahI3I8r8wKfGlvWuY-0crKHqGxbPXk5o=.6b9ff3f1-f297-40f0-9c81-99507c2b2880@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <0UeIWfhsJRNahI3I8r8wKfGlvWuY-0crKHqGxbPXk5o=.6b9ff3f1-f297-40f0-9c81-99507c2b2880@github.com>
Message-ID: <77NWcTx23rX8UnhRcnOqS36y4Y-7-zDEf3hyYD1bcbw=.6f02be24-3cd2-44d8-8483-934295aab9fd@github.com>

On Wed, 21 Aug 2024 20:31:09 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 279:
> 
>> 277:         clb.withMethod(invokerName, invokerDesc, ACC_STATIC, config);
>> 278:     }
>> 279: 
> 
> There's probably not much value in using ACC_FINAL here anyway.  We are only using these classes to create static methods, right?  I think ACC_INTERFACE would work here too.

Note that JVMS 4.1 requires `ACC_ABSTRACT` to be also set when `ACC_INTERFACE` is set. Also note that some classes capture class data to refer to hidden classes and method handles or lambda forms, so those fields' generation need to add `ACC_PUBLIC` flag to be usable in interfaces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1725751901

From coleenp at openjdk.org  Wed Aug 21 21:20:06 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 21 Aug 2024 21:20:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <77NWcTx23rX8UnhRcnOqS36y4Y-7-zDEf3hyYD1bcbw=.6f02be24-3cd2-44d8-8483-934295aab9fd@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <0UeIWfhsJRNahI3I8r8wKfGlvWuY-0crKHqGxbPXk5o=.6b9ff3f1-f297-40f0-9c81-99507c2b2880@github.com>
 <77NWcTx23rX8UnhRcnOqS36y4Y-7-zDEf3hyYD1bcbw=.6f02be24-3cd2-44d8-8483-934295aab9fd@github.com>
Message-ID: <MZftBPrG2vDEMDK7LDuyyvNTnxi42GdCtP9UtwOijjc=.40ccfb67-a338-47f7-b310-28546b4100be@github.com>

On Wed, 21 Aug 2024 21:02:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 279:
>> 
>>> 277:         clb.withMethod(invokerName, invokerDesc, ACC_STATIC, config);
>>> 278:     }
>>> 279: 
>> 
>> There's probably not much value in using ACC_FINAL here anyway.  We are only using these classes to create static methods, right?  I think ACC_INTERFACE would work here too.
>
> Note that JVMS 4.1 requires `ACC_ABSTRACT` to be also set when `ACC_INTERFACE` is set. Also note that some classes capture class data to refer to hidden classes and method handles or lambda forms, so those fields' generation need to add `ACC_PUBLIC` flag to be usable in interfaces.

I feel like making it ACC_INTERFACE might cause some error if there are no public nonstatic methods, which is the case with this class. I don't know what @liach your comment means, but this code got more complicated than it was with the first version of this change.  When I talked to @rose00 he thought ACC_ABSTRACT would be okay for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1725764671

From kvn at openjdk.org  Wed Aug 21 21:22:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 21 Aug 2024 21:22:02 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
Message-ID: <bf3z58eg9GfbpZ-wvLIMaAk7r6Y59GTWVneAC1hytxs=.09b4748c-7a7e-4ca4-8c3d-aec68ec5e986@github.com>

On Wed, 21 Aug 2024 20:11:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
> 
> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
> 
> Testing: jdk_jfr, loom testing
> 
> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
> 
> Thanks
> Markus

src/hotspot/share/opto/library_call.cpp line 3815:

> 3813: bool LibraryCallKit::inline_native_Continuation_unpin() {
> 3814:   return inline_native_Continuation_pinning_shared_impl(true);
> 3815: }

I don't see the need these 2 methods. You can directly call inline_native_Continuation_pinning_shared_impl() in switch in try_to_inline() and pass true or false there.
You may also rename it to `inline_native_Continuation_pinning()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1725766345

From liach at openjdk.org  Wed Aug 21 21:35:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 21:35:04 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <MZftBPrG2vDEMDK7LDuyyvNTnxi42GdCtP9UtwOijjc=.40ccfb67-a338-47f7-b310-28546b4100be@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <0UeIWfhsJRNahI3I8r8wKfGlvWuY-0crKHqGxbPXk5o=.6b9ff3f1-f297-40f0-9c81-99507c2b2880@github.com>
 <77NWcTx23rX8UnhRcnOqS36y4Y-7-zDEf3hyYD1bcbw=.6f02be24-3cd2-44d8-8483-934295aab9fd@github.com>
 <MZftBPrG2vDEMDK7LDuyyvNTnxi42GdCtP9UtwOijjc=.40ccfb67-a338-47f7-b310-28546b4100be@github.com>
Message-ID: <cm-SjRLYbstqXVvYQL4uEK_H4DI5z5oVetZGTMZqMsY=.8697b89b-8e16-40fc-9d82-809538abb436@github.com>

On Wed, 21 Aug 2024 21:17:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Note that JVMS 4.1 requires `ACC_ABSTRACT` to be also set when `ACC_INTERFACE` is set. Also note that some classes capture class data to refer to hidden classes and method handles or lambda forms, so those fields' generation need to add `ACC_PUBLIC` flag to be usable in interfaces.
>
> I feel like making it ACC_INTERFACE might cause some error if there are no public nonstatic methods, which is the case with this class. I don't know what @liach your comment means, but this code got more complicated than it was with the first version of this change.  When I talked to @rose00 he thought ACC_ABSTRACT would be okay for this.

Yes, you are right that we currently don't add ACC_PUBLIC flags on methods, which will fail if we add ACC_INTERFACE. Same for the fields; these LambdaForm classes use fields to store class data that's usually stored as condy, because LambdaForm is the infrastructure that condy uses (like LambdaMetafacotry cannot use lambdas). Those fields are my concerns for the interface migration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1725777710

From liach at openjdk.org  Wed Aug 21 21:49:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 21:49:09 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps [v3]
In-Reply-To: <lhiQUmYq6imU1q1CjJJMmojf-p7c_yg06P2HrPaDpvk=.15fb2878-b456-4424-ba35-9d1b1c9024cb@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
 <OVmK9shSdckDHbxyLjdQADmRADEXp5eR-B_r9L-zZic=.ed696fcb-f490-466c-85a1-295d4e55376f@github.com>
 <lhiQUmYq6imU1q1CjJJMmojf-p7c_yg06P2HrPaDpvk=.15fb2878-b456-4424-ba35-9d1b1c9024cb@github.com>
Message-ID: <zVO43LEZD2JUxpBwsQCZ93IpTuzGTtUWtzV2yKxjMIE=.45d2e666-b5b6-4e73-8708-6d55ad71b4ef@github.com>

On Wed, 24 Jul 2024 14:24:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes
>
> test/micro/org/openjdk/bench/java/util/stream/ops/ref/FindAny.java line 63:
> 
>> 61:     }
>> 62: 
>> 63:     public static void main(String... args) {
> 
> Is this driver necessary?

@cl4es Just wonder what your use case is for this addition. If this is accidentally committed, please remove it and I am glad with all other changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1725789087

From ihse at openjdk.org  Wed Aug 21 21:58:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 21:58:34 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
Message-ID: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>

As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.

This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 

This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.

-------------

Commit messages:
 - 8338768: Introduce runtime lookup to check for static builds

Changes: https://git.openjdk.org/jdk/pull/20666/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20666&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338768
  Stats: 203 lines in 11 files changed: 109 ins; 21 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/20666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20666/head:pull/20666

PR: https://git.openjdk.org/jdk/pull/20666

From redestad at openjdk.org  Wed Aug 21 22:07:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Aug 2024 22:07:06 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps [v3]
In-Reply-To: <zVO43LEZD2JUxpBwsQCZ93IpTuzGTtUWtzV2yKxjMIE=.45d2e666-b5b6-4e73-8708-6d55ad71b4ef@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
 <OVmK9shSdckDHbxyLjdQADmRADEXp5eR-B_r9L-zZic=.ed696fcb-f490-466c-85a1-295d4e55376f@github.com>
 <lhiQUmYq6imU1q1CjJJMmojf-p7c_yg06P2HrPaDpvk=.15fb2878-b456-4424-ba35-9d1b1c9024cb@github.com>
 <zVO43LEZD2JUxpBwsQCZ93IpTuzGTtUWtzV2yKxjMIE=.45d2e666-b5b6-4e73-8708-6d55ad71b4ef@github.com>
Message-ID: <Sli2BU-AG6YaqIAjNT6LiF1DCRkkshV_uFAjIGvcWmM=.c0dce308-ec92-4ed8-9057-7175fe7a38b6@github.com>

On Wed, 21 Aug 2024 21:46:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/stream/ops/ref/FindAny.java line 63:
>> 
>>> 61:     }
>>> 62: 
>>> 63:     public static void main(String... args) {
>> 
>> Is this driver necessary?
>
> @cl4es Just wonder what your use case is for this addition. If this is accidentally committed, please remove it and I am glad with all other changes.

Adding a `main` method in micros like these allow me to easily multi-purpose them as relatively clean, diagnostic startup microbenchmarks. It's something I've started adding to all micros I author. I guess I should do a write-up about it some time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1725802115

From liach at openjdk.org  Wed Aug 21 22:13:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 22:13:08 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: <2txMJNkaPnHrHKo74x0ojAUXOai2K2YPJdjoQOUXp34=.832f01f2-d01d-40bf-a827-13d1f4d1e196@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

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19477#pullrequestreview-2252023120

From liach at openjdk.org  Wed Aug 21 22:13:09 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 22:13:09 GMT
Subject: RFR: 8333265: De-duplicate method references in
 java.util.stream.FindOps [v3]
In-Reply-To: <Sli2BU-AG6YaqIAjNT6LiF1DCRkkshV_uFAjIGvcWmM=.c0dce308-ec92-4ed8-9057-7175fe7a38b6@github.com>
References: <1oIB6hqDegMWORETDlXfVgb_xM405KYmoM1DCACMolk=.e2a1e506-77a0-403a-aeec-8d2edf2d73e2@github.com>
 <OVmK9shSdckDHbxyLjdQADmRADEXp5eR-B_r9L-zZic=.ed696fcb-f490-466c-85a1-295d4e55376f@github.com>
 <lhiQUmYq6imU1q1CjJJMmojf-p7c_yg06P2HrPaDpvk=.15fb2878-b456-4424-ba35-9d1b1c9024cb@github.com>
 <zVO43LEZD2JUxpBwsQCZ93IpTuzGTtUWtzV2yKxjMIE=.45d2e666-b5b6-4e73-8708-6d55ad71b4ef@github.com>
 <Sli2BU-AG6YaqIAjNT6LiF1DCRkkshV_uFAjIGvcWmM=.c0dce308-ec92-4ed8-9057-7175fe7a38b6@github.com>
Message-ID: <HJnVywcQ5w7IV62WJ_g2BTceeZp4fSbEs1gJ-S-hRMs=.47526f1a-fa30-4ecd-b10b-008d1d17d13d@github.com>

On Wed, 21 Aug 2024 22:04:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es Just wonder what your use case is for this addition. If this is accidentally committed, please remove it and I am glad with all other changes.
>
> Adding a `main` method in micros like these allow me to easily multi-purpose them as relatively clean, diagnostic startup microbenchmarks. It's something I've started adding to all micros I author. I guess I should do a write-up about it some time.

Thanks for the explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19477#discussion_r1725805702

From redestad at openjdk.org  Wed Aug 21 22:13:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 21 Aug 2024 22:13:09 GMT
Subject: Integrated: 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: <E3MNWmaON7YrqggJhZZs0tYREKicFI17mv1ijpkkIdE=.b1f0cdc9-b451-49f9-94d8-fc828c652c4a@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.

This pull request has now been integrated.

Changeset: 47c8a6a8
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47c8a6a8db979fe862be876008feb76cdc9dccfd
Stats:     46 lines in 2 files changed: 21 ins; 0 del; 25 mod

8333265: De-duplicate method references in java.util.stream.FindOps

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/19477

From ihse at openjdk.org  Wed Aug 21 22:14:40 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 21 Aug 2024 22:14:40 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
Message-ID: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>

> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
> 
> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
> 
> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update build to link properly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20666/files
  - new: https://git.openjdk.org/jdk/pull/20666/files/e917f6a2..072a910d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20666&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20666&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20666/head:pull/20666

PR: https://git.openjdk.org/jdk/pull/20666

From liach at openjdk.org  Wed Aug 21 23:25:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Aug 2024 23:25:34 GMT
Subject: RFR: 8338700: AttributeMapper type parameter should be bounded by
 Attribute
Message-ID: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>

A minor oversight in AttributeMapper type parameter bounds, that it should be bounded by Attribute. Only real impact is in BoundAttribute.readAttributes where a cast is now omitted, as other sites of access like Attribute::attributeMapper has already bounded the returned type argument.

-------------

Commit messages:
 - 8338700: AttributeMapper type parameter should be bounded by Attribute

Changes: https://git.openjdk.org/jdk/pull/20668/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20668&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338700
  Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20668/head:pull/20668

PR: https://git.openjdk.org/jdk/pull/20668

From prr at openjdk.org  Wed Aug 21 23:54:05 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 21 Aug 2024 23:54:05 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <yN8KUdmqxUOEEtAN8_71CHocXBbc5VZcPjGxJnkt85w=.d67be130-1459-4ace-afaa-7d178f000b9f@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

AWT changes look fine.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2252384240

From jiangli at openjdk.org  Thu Aug 22 00:33:02 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 22 Aug 2024 00:33:02 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

I compared the extracted changes in this PR with the related parts in https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as discussed in https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is  that these runtime changes for static JDK can't be tested even they are relatively simple, without the the actual linking change. Any timeline for the static linking changes?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2252486767

From sviswanathan at openjdk.org  Thu Aug 22 01:20:16 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 22 Aug 2024 01:20:16 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v3]
In-Reply-To: <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <eEiJ_5KabfDqodFjIpqQGPi-ju2m2BFaXW67nlub9qY=.ddeb138f-eae9-4751-9759-53eb440b2f10@github.com>
Message-ID: <VLkaLTJDPsuZdyE3JiUUWM0Bwi-91OfcsuyJDLqTfjs=.bbbb66af-32cb-4a59-83fb-9d2efa460c15@github.com>

On Wed, 21 Aug 2024 16:42:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass explicit wrap argument to selectFrom API with default value set to true.

@rose00 @PaulSandoz I have updated https://github.com/openjdk/jdk/pull/20634. Please take a look if it meets your expectations for the existing rearrange/selectFrom apis. Jatin can then base the new two vector selectFrom api in this PR on similar lines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2303383784

From dholmes at openjdk.org  Thu Aug 22 02:49:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Aug 2024 02:49:09 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2252973892

From liach at openjdk.org  Thu Aug 22 04:58:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 04:58:44 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
Message-ID: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>

Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

-------------

Commit messages:
 - Fix microbenchmark
 - Improve jmh
 - 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

Changes: https://git.openjdk.org/jdk/pull/20667/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20667&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338546
  Stats: 499 lines in 7 files changed: 498 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20667/head:pull/20667

PR: https://git.openjdk.org/jdk/pull/20667

From liach at openjdk.org  Thu Aug 22 04:58:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 04:58:44 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <4uHKiUWh0ci2M_AT21wefF0LwJtSBBAqbFV4RFCZqO4=.d2cebf9f-9669-43ae-890e-ebb62769a554@github.com>

On Wed, 21 Aug 2024 22:27:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

Current benchmark results on mac aarch64, where `oldStyleLookup` is the performance of the current `classEntry(ClassDesc)`:

Benchmark                                           Mode  Cnt    Score   Error   Units
ConstantPoolBuildingClassEntry.identicalLookup     thrpt    5  112.603 ?? 0.514  ops/ms
ConstantPoolBuildingClassEntry.internalNameLookup  thrpt    5  239.761 ?? 0.190  ops/ms
ConstantPoolBuildingClassEntry.nonIdenticalLookup  thrpt    5  169.954 ?? 0.606  ops/ms
ConstantPoolBuildingClassEntry.oldStyleLookup      thrpt    5   81.993 ?? 4.942  ops/ms

Windows x64:

Benchmark                                           Mode  Cnt    Score   Error   Units
ConstantPoolBuildingClassEntry.identicalLookup     thrpt    5  134.546 ? 0.835  ops/ms
ConstantPoolBuildingClassEntry.internalNameLookup  thrpt    5  201.743 ? 1.236  ops/ms
ConstantPoolBuildingClassEntry.nonIdenticalLookup  thrpt    5  134.512 ? 1.655  ops/ms
ConstantPoolBuildingClassEntry.oldStyleLookup      thrpt    5   78.647 ? 0.370  ops/ms

For some reason identity matching case hurts, but the other x64 platforms are much less affected. @cl4es would you know why these compiled benchmarks would behave so?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2303783382

From liach at openjdk.org  Thu Aug 22 05:19:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 05:19:05 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <I6x-7nQJ3Mmg6T2Dq3zPFl9f-hVhjCAPjVZ10AYEf0s=.425d1f20-9f18-4db2-98b5-b0a896198e0b@github.com>

On Wed, 21 Aug 2024 22:27:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

Ran the benchmarks with `-Xint` and this patch still sees a 50% increase in throughput from the baseline version; but it is a bit far from direct internal name usage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2303803328

From jwaters at openjdk.org  Thu Aug 22 05:30:02 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Aug 2024 05:30:02 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
Message-ID: <6Qu9wbsWf_YxFFvfA6KveCLOheMOsbo4z--gZzQh9xY=.b1d013f6-eb34-4d50-b19b-64c684cdea13@github.com>

On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks.

I believe the new methods are for checking whether the JDK was statically linked or not, but I half agree with your point. The change to using the new methods instead of preprocessor checks don't seem to really do anything. Maybe the new methods can be kept alongside the preprocessor checks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2303813593

From thartmann at openjdk.org  Thu Aug 22 05:52:09 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 22 Aug 2024 05:52:09 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
Message-ID: <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>

On Wed, 21 Aug 2024 20:11:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
> 
> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
> 
> Testing: jdk_jfr, loom testing
> 
> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
> 
> Thanks
> Markus

src/hotspot/share/opto/library_call.cpp line 3787:

> 3785:     set_all_memory(input_memory_state);
> 3786:     uncommon_trap_exact(Deoptimization::Reason_intrinsic,
> 3787:                         Deoptimization::Action_reinterpret);

Why do you use `Action_reinterpret` and not `Action_make_not_entrant` here?

You may need a check to avoid endless re-compilation of a method that always hits the trap:

  if (too_many_traps(Deoptimization::Reason_intrinsic)) {
    return false;
  }


See other intrinsics.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726376702

From asotona at openjdk.org  Thu Aug 22 06:05:02 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 22 Aug 2024 06:05:02 GMT
Subject: RFR: 8338700: AttributeMapper type parameter should be bounded by
 Attribute
In-Reply-To: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
References: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
Message-ID: <vtPaljYAbMDJRv5qbpJWcTso_LMR4KdX3Al7I-OWbxY=.c1cdc4e6-d960-465c-a65c-894276990582@github.com>

On Wed, 21 Aug 2024 23:20:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> A minor oversight in AttributeMapper type parameter bounds, that it should be bounded by Attribute. Only real impact is in BoundAttribute.readAttributes where a cast is now omitted, as other sites of access like Attribute::attributeMapper has already bounded the returned type argument.

Looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20668#pullrequestreview-2253566456

From dlong at openjdk.org  Thu Aug 22 07:17:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 22 Aug 2024 07:17:03 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
Message-ID: <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>

On Thu, 22 Aug 2024 05:47:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Greetings,
>> 
>> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>> 
>> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
>> 
>> Testing: jdk_jfr, loom testing
>> 
>> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
>> 
>> Thanks
>> Markus
>
> src/hotspot/share/opto/library_call.cpp line 3787:
> 
>> 3785:     set_all_memory(input_memory_state);
>> 3786:     uncommon_trap_exact(Deoptimization::Reason_intrinsic,
>> 3787:                         Deoptimization::Action_reinterpret);
> 
> Why do you use `Action_reinterpret` and not `Action_make_not_entrant` here?
> 
> You may need a check to avoid endless re-compilation of a method that always hits the trap:
> 
>   if (too_many_traps(Deoptimization::Reason_intrinsic)) {
>     return false;
>   }
> 
> 
> See other intrinsics.

A pin_count overflow/underflow should be a per-thread condition, not global.  If there is nothing in the nmethod to be invalidated, maybe this should be `Action_none`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726482790

From rkennke at openjdk.org  Thu Aug 22 07:57:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 07:57:11 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <xeGZVnrSupT_icxhlSJTf0YccAmOpBceUvCSIoAK7ec=.ea5b537d-06ff-4dad-8e5c-c03ac3dbc7d5@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

If I understand correctly, we already have limits on how many classes we can represent as compressed class-pointers. While this is nice for Lilliput, this is equally useful for non-Lilliput CCP, because addressable class-space doesn't get polluted by classes that never need to be encoded as CCP, and thus effectively increases the number of classes that we can address without resorting to -UseCompressedClassPointers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2304017272

From duke at openjdk.org  Thu Aug 22 08:37:04 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 22 Aug 2024 08:37:04 GMT
Subject: RFR: 8338700: AttributeMapper type parameter should be bounded by
 Attribute
In-Reply-To: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
References: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
Message-ID: <wHWurO3QkV8nM45WPQ7unOWgnHyeXhfuObmHK-Pyt8s=.46b27e6d-078a-4c52-874b-e55d77e6b87c@github.com>

On Wed, 21 Aug 2024 23:20:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> A minor oversight in AttributeMapper type parameter bounds, that it should be bounded by Attribute. Only real impact is in BoundAttribute.readAttributes where a cast is now omitted, as other sites of access like Attribute::attributeMapper has already bounded the returned type argument.

Note that this also?affects binary?compatibility as?the?erased?type of?`A` is?now?`java.lang.classfile.Attribute` instead of?`java.lang.Object`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20668#issuecomment-2304091808

From ihse at openjdk.org  Thu Aug 22 08:46:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 08:46:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com>
Message-ID: <lx_4v2Poa1_CV7IIBLQvAfrXgOKS3fGJQvNOMEAqE7U=.e67f6766-7ef6-4803-93ab-aa77c137d25f@github.com>

On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> I compared the extracted changes in this PR with the related parts in https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as discussed in https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is  that these runtime changes for static JDK can't be tested even they are relatively simple, without the the actual linking change. Any timeline for the static linking changes?

@jianglizhou 

> [...] these runtime changes for static JDK can't be tested [...]

Yes, they can. This is just a pure refactoring of existing code. I have deliberately kept out addition of the new places where static linking exceptions are needed in the code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2304110701

From ihse at openjdk.org  Thu Aug 22 08:59:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 08:59:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
Message-ID: <CXP90x_kG6QAqALKAtq7kv7NhIM4gAjq646Iln0Jhlg=.e66ac47f-90fc-4381-910c-711c433b3db9@github.com>

On Thu, 22 Aug 2024 02:46:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks.

@dholmes-ora 

> Sorry but I don't understand the point of changing build-time constructs using ifdef STATIC_BUILD into what appear to be runtime checks, but the result of which is already determined at build time. 

I apologize. I did not express the intent of this change clear enough.

The background is that we want to build and test statically linked native libraries. Currently, building a statically linked version requires recompiling all native source code into a completely new set of .o files, which are then linked into a static library.

This is extremely wasteful. Most of the code is completely identical for static and dynamic libraries. To fix this, me, Jiangli and her team have been working on a way to get around this.

By moving the ifdef check to a new file that just contains a single function, we only need to compile this single file twice -- once for the static library, and once for the dynamic library. All other .o files is compiled just once, and then you link "all other files" + "the one special file for your kind of library" to get what you want. 

Unfortunately, there is also one more blocker before this can be achieved. That is the reason the corresponding change in the build system is not included in this patch. (So this is a preparation for these future changes, but not the complete solution.) The missing part is that the `[JNI|Agent]_On[Un]Load` functions need to be able to use the static linked naming scheme, even for dynamically linked libraries. This is trivial per se, but requires a spec change, which has not yet happened.

The reason I want to get this partial solution into the mainline right now, instead of waiting for the spec change and the complete build system fix, is that these new functions for checking for static/dynamic are needed by additional changes that Jiangli have created upstream, and that I am trying to help her get integrated. (The goal of these changes is to make not just static libraries, but to link these static libraries with the java launcher into a statically linked launcher, which is a pre-requisite for the rest of the Hermetic Java story.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2304133213

From thartmann at openjdk.org  Thu Aug 22 09:15:04 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 22 Aug 2024 09:15:04 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
Message-ID: <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>

On Thu, 22 Aug 2024 07:14:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 3787:
>> 
>>> 3785:     set_all_memory(input_memory_state);
>>> 3786:     uncommon_trap_exact(Deoptimization::Reason_intrinsic,
>>> 3787:                         Deoptimization::Action_reinterpret);
>> 
>> Why do you use `Action_reinterpret` and not `Action_make_not_entrant` here?
>> 
>> You may need a check to avoid endless re-compilation of a method that always hits the trap:
>> 
>>   if (too_many_traps(Deoptimization::Reason_intrinsic)) {
>>     return false;
>>   }
>> 
>> 
>> See other intrinsics.
>
> A pin_count overflow/underflow should be a per-thread condition, not global.  If there is nothing in the nmethod to be invalidated, maybe this should be `Action_none`?

Right, that would make sense to me because `Deoptimization::Action_reinterpret` might also invalidate the nmethod.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726664123

From mgronlun at openjdk.org  Thu Aug 22 09:15:04 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 09:15:04 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
 <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
Message-ID: <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>

On Thu, 22 Aug 2024 09:09:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> A pin_count overflow/underflow should be a per-thread condition, not global.  If there is nothing in the nmethod to be invalidated, maybe this should be `Action_none`?
>
> Right, that would make sense to me because `Deoptimization::Action_reinterpret` might also invalidate the nmethod.

The functional requirement I have is that the branch takes an uncommon trap and restarts / re-executes the same method the interpreter, because that version enters the VM where an IllegalStateException is thrown. 

I don't need the compiled method to be invalidated, only that an attempt that over/underflows (thread-local) restarts in the interpeter for the exception to be thrown. Is Action_none better suited for this purpose?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726665198

From mgronlun at openjdk.org  Thu Aug 22 09:15:05 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 09:15:05 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <bf3z58eg9GfbpZ-wvLIMaAk7r6Y59GTWVneAC1hytxs=.09b4748c-7a7e-4ca4-8c3d-aec68ec5e986@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <bf3z58eg9GfbpZ-wvLIMaAk7r6Y59GTWVneAC1hytxs=.09b4748c-7a7e-4ca4-8c3d-aec68ec5e986@github.com>
Message-ID: <xdGyx5AEKpVI2ZNY5BR3OZu2A9UXmuI4jynIYYIJohs=.ed3b8e6c-708e-48d1-a4cc-561d2fab111d@github.com>

On Wed, 21 Aug 2024 21:19:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Greetings,
>> 
>> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>> 
>> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
>> 
>> Testing: jdk_jfr, loom testing
>> 
>> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
>> 
>> Thanks
>> Markus
>
> src/hotspot/share/opto/library_call.cpp line 3815:
> 
>> 3813: bool LibraryCallKit::inline_native_Continuation_unpin() {
>> 3814:   return inline_native_Continuation_pinning_shared_impl(true);
>> 3815: }
> 
> I don't see the need these 2 methods. You can directly call inline_native_Continuation_pinning_shared_impl() in switch in try_to_inline() and pass true or false there.
> You may also rename it to `inline_native_Continuation_pinning()`.

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726670122

From stuefe at openjdk.org  Thu Aug 22 09:16:07 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 22 Aug 2024 09:16:07 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <4FCg8K0oXo8mO47HSpZJ5Y4qS6oxspsM4Juqdj0mLkg=.9f0ef8c9-8f2d-44d5-ba56-348e8159c9a5@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

I am surprised that this patch is so small. I would have assumed a lot of code exists that unconditionally assumes we always can encode decode Klass*<->narrowKlass.

I looked through the typical cases (eg Klass validation) and all of them seem to be okay. I will keep looking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2304169936

From mgronlun at openjdk.org  Thu Aug 22 09:15:04 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 09:15:04 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
 <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
 <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>
Message-ID: <WP32qs-MFn1ILf3fy6sXVsO2s7uFksJh3Nj9vIHkHvg=.d8ffb5b8-6f7c-42ee-8c04-24275d6b5def@github.com>

On Thu, 22 Aug 2024 09:09:52 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Right, that would make sense to me because `Deoptimization::Action_reinterpret` might also invalidate the nmethod.
>
> The functional requirement I have is that the branch takes an uncommon trap and restarts / re-executes the same method the interpreter, because that version enters the VM where an IllegalStateException is thrown. 
> 
> I don't need the compiled method to be invalidated, only that an attempt that over/underflows (thread-local) restarts in the interpeter for the exception to be thrown. Is Action_none better suited for this purpose?

The pattern of the uncommon trap construct was taken from the precedent in LibraryCallKit::inline_profileBoolean().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726667330

From mgronlun at openjdk.org  Thu Aug 22 09:27:03 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 09:27:03 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <WP32qs-MFn1ILf3fy6sXVsO2s7uFksJh3Nj9vIHkHvg=.d8ffb5b8-6f7c-42ee-8c04-24275d6b5def@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
 <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
 <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>
 <WP32qs-MFn1ILf3fy6sXVsO2s7uFksJh3Nj9vIHkHvg=.d8ffb5b8-6f7c-42ee-8c04-24275d6b5def@github.com>
Message-ID: <wE7-j38wxrnGVW-UPE_jAFGD3hQDNNt2bgyD3IK9xz8=.4daca633-cdc2-4c62-92b9-95efb26d7b62@github.com>

On Thu, 22 Aug 2024 09:11:03 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The functional requirement I have is that the branch takes an uncommon trap and restarts / re-executes the same method the interpreter, because that version enters the VM where an IllegalStateException is thrown. 
>> 
>> I don't need the compiled method to be invalidated, only that an attempt that over/underflows (thread-local) restarts in the interpeter for the exception to be thrown. Is Action_none better suited for this purpose?
>
> The pattern of the uncommon trap construct was taken from the precedent in LibraryCallKit::inline_profileBoolean().

Is it an implicit invariant that execution always continues in the interpreter after an uncommon trap? I.e., I don't need to explicitly tell it to "re-execute" there?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726689737

From mgronlun at openjdk.org  Thu Aug 22 11:13:17 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 11:13:17 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v2]
In-Reply-To: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
Message-ID: <h-GlRFJq7QB5l3ExjhqONq1G72I5GZhUErIzDOU4qTM=.dd5e4a20-54ac-4301-bba9-15a9b2525064@github.com>

> Greetings,
> 
> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
> 
> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
> 
> Testing: jdk_jfr, loom testing
> 
> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  Deoptimization::Action_none for no deopt

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20664/files
  - new: https://git.openjdk.org/jdk/pull/20664/files/ab3af53a..fa9a737a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20664&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20664&range=00-01

  Stats: 20 lines in 2 files changed: 1 ins; 13 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20664/head:pull/20664

PR: https://git.openjdk.org/jdk/pull/20664

From liach at openjdk.org  Thu Aug 22 11:20:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 11:20:02 GMT
Subject: RFR: 8338700: AttributeMapper type parameter should be bounded by
 Attribute
In-Reply-To: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
References: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
Message-ID: <9BQpo84j-ZuCJdxu0i7YLtWJYNylN8HmZ9ZL1IKa4bY=.ebf78c2f-2c00-432e-916b-872807564662@github.com>

On Wed, 21 Aug 2024 23:20:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> A minor oversight in AttributeMapper type parameter bounds, that it should be bounded by Attribute. Only real impact is in BoundAttribute.readAttributes where a cast is now omitted, as other sites of access like Attribute::attributeMapper has already bounded the returned type argument.

This consideration is already mentioned in the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20668#issuecomment-2304415300

From mgronlun at openjdk.org  Thu Aug 22 11:24:05 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 11:24:05 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v2]
In-Reply-To: <wE7-j38wxrnGVW-UPE_jAFGD3hQDNNt2bgyD3IK9xz8=.4daca633-cdc2-4c62-92b9-95efb26d7b62@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
 <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
 <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>
 <WP32qs-MFn1ILf3fy6sXVsO2s7uFksJh3Nj9vIHkHvg=.d8ffb5b8-6f7c-42ee-8c04-24275d6b5def@github.com>
 <wE7-j38wxrnGVW-UPE_jAFGD3hQDNNt2bgyD3IK9xz8=.4daca633-cdc2-4c62-92b9-95efb26d7b62@github.com>
Message-ID: <X54g13BrvobyWpWIauGTu60hNUOY3ngmO8KGN1FwLtk=.e8e79849-9fff-45a1-b1a0-e1ca38a74504@github.com>

On Thu, 22 Aug 2024 09:24:18 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The pattern of the uncommon trap construct was taken from the precedent in LibraryCallKit::inline_profileBoolean().
>
> Is it an implicit invariant that execution always continues in the interpreter after an uncommon trap? I.e., I don't need to explicitly tell it to "re-execute" there?

It is updated to use Action::none to keep the nmethod. The trap code picks up the correct bytecode (invokestatic) from the trap scope. So after unrolling the host method (the inliner), the trap bytecode (i.e., the invokestatic call to Continuation.pin() or unpin()) is re-executed in the interpreter. This is also without setting the explicit re-execute state (which may mean something else).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726868890

From yzheng at openjdk.org  Thu Aug 22 11:30:05 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 22 Aug 2024 11:30:05 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v2]
In-Reply-To: <h-GlRFJq7QB5l3ExjhqONq1G72I5GZhUErIzDOU4qTM=.dd5e4a20-54ac-4301-bba9-15a9b2525064@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <h-GlRFJq7QB5l3ExjhqONq1G72I5GZhUErIzDOU4qTM=.dd5e4a20-54ac-4301-bba9-15a9b2525064@github.com>
Message-ID: <x8sPsS6rvQ5PLpgVyfNLqCd51SY0ZpIYfIOphe0tfIg=.42e89e4a-8c52-490a-b251-5a118c43624d@github.com>

On Thu, 22 Aug 2024 11:13:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>> 
>> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
>> 
>> Testing: jdk_jfr, loom testing
>> 
>> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deoptimization::Action_none for no deopt

src/hotspot/share/opto/library_call.cpp line 3733:

> 3731:   // TLS
> 3732:   Node* tls_ptr = _gvn.transform(new ThreadLocalNode());
> 3733:   Node* last_continuation_offset = basic_plus_adr(top(), tls_ptr, in_bytes(JavaThread::cont_entry_offset()));

Could you please export `JavaThread::_cont_entry` and `ContinuationEntry::_pin_count` to JVMCI? Thanks!

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 688691fb976..a25ecd2bab5 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -35,6 +35,7 @@
 #include "oops/methodCounters.hpp"
 #include "oops/objArrayKlass.hpp"
 #include "prims/jvmtiThreadState.hpp"
+#include "runtime/continuationEntry.hpp"
 #include "runtime/deoptimization.hpp"
 #include "runtime/flags/jvmFlag.hpp"
 #include "runtime/osThread.hpp"
@@ -244,10 +245,13 @@
   nonstatic_field(JavaThread,                  _held_monitor_count,                           intx)                                  \
   nonstatic_field(JavaThread,                  _lock_stack,                                   LockStack)                             \
   nonstatic_field(JavaThread,                  _om_cache,                                     OMCache)                               \
+  nonstatic_field(JavaThread,                  _cont_entry,                                   ContinuationEntry*)                    \
   JVMTI_ONLY(nonstatic_field(JavaThread,       _is_in_VTMS_transition,                        bool))                                 \
   JVMTI_ONLY(nonstatic_field(JavaThread,       _is_in_tmp_VTMS_transition,                    bool))                                 \
   JVMTI_ONLY(nonstatic_field(JavaThread,       _is_disable_suspend,                           bool))                                 \
                                                                                                                                      \
+  nonstatic_field(ContinuationEntry,           _pin_count,                                    uint32_t)                              \
+                                                                                                                                     \
   nonstatic_field(LockStack,                   _top,                                          uint32_t)                              \
                                                                                                                                      \
   JVMTI_ONLY(static_field(JvmtiVTMSTransitionDisabler, _VTMS_notify_jvmti_events,             bool))                                 \
diff --git a/src/hotspot/share/runtime/continuationEntry.hpp b/src/hotspot/share/runtime/continuationEntry.hpp
index 459321f444c..ac76cd6f088 100644
--- a/src/hotspot/share/runtime/continuationEntry.hpp
+++ b/src/hotspot/share/runtime/continuationEntry.hpp
@@ -39,6 +39,7 @@ class RegisterMap;
 
 // Metadata stored in the continuation entry frame
 class ContinuationEntry {
+  friend class JVMCIVMStructs;
   ContinuationEntryPD _pd;
 #ifdef ASSERT
 private:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726876549

From nbenalla at openjdk.org  Thu Aug 22 11:55:09 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 22 Aug 2024 11:55:09 GMT
Subject: RFR: 8331051: Add an `@since` checker test for `java.base` module
 [v11]
In-Reply-To: <ZvrMx6gMUd0a-GDpgSdmyVCjhzb8ysoQ4zPYIHhKA2Q=.ea66d0c9-9b33-4e76-8153-5cf0c567cc27@github.com>
References: <NRZmbFYvDwXPuizcmCilJx5Yb6HjZ-2fJa-YILxYUl8=.a79f79e4-77d5-4910-b3df-5e78bb7e402b@github.com>
 <ZvrMx6gMUd0a-GDpgSdmyVCjhzb8ysoQ4zPYIHhKA2Q=.ea66d0c9-9b33-4e76-8153-5cf0c567cc27@github.com>
Message-ID: <zSUj324di5zx3F5eJmV8sGxB6CdMoOJK7j7288jmSAE=.cd74abff-6487-4579-91ce-a307c9f92fdf@github.com>

On Fri, 28 Jun 2024 13:36:32 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:
> 
>   Skip over files and packages that aren't found

Keep alive, this will need a re-review eventually because of the new rules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18934#issuecomment-2304480262

From redestad at openjdk.org  Thu Aug 22 11:58:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 22 Aug 2024 11:58:03 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>

On Wed, 21 Aug 2024 22:27:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

test/micro/org/openjdk/bench/jdk/classfile/ConstantPoolBuildingClassEntry.java line 64:

> 62:         builder = ConstantPoolBuilder.of();
> 63:         classDescs = List.of(
> 64:                 CD_Byte, CD_Object, CD_Long.arrayType(), CD_String, CD_String, CD_Object, CD_Short,

Should this include some primitive class descs? I only see wrapper types like `CD_Integer`

test/micro/org/openjdk/bench/jdk/classfile/ConstantPoolBuildingClassEntry.java line 91:

> 89:     public void identicalLookup(Blackhole bh) {
> 90:         for (int i = 0; i < RUNS; i++) {
> 91:             int n = random.nextInt(size);

Why the randomization here? `Random` can be pretty slow in and off itself, skewing results, and scales poorly. Prefer `ThreadLocalRandom`. `classDescs` look pretty random to begin with, so why not just loop over it once per measurement?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1726914428
PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1726912737

From mgronlun at openjdk.org  Thu Aug 22 12:10:37 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 12:10:37 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v3]
In-Reply-To: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
Message-ID: <TgQMvUFE34-MAv_nhNUTAEA8hl4vFxKYMkVtouNIud0=.e207cebf-7baf-4b1e-8fad-97687f52ba17@github.com>

> Greetings,
> 
> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
> 
> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
> 
> Testing: jdk_jfr, loom testing
> 
> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  JVMCI exportation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20664/files
  - new: https://git.openjdk.org/jdk/pull/20664/files/fa9a737a..ba68f2c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20664&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20664&range=01-02

  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20664/head:pull/20664

PR: https://git.openjdk.org/jdk/pull/20664

From mgronlun at openjdk.org  Thu Aug 22 12:10:38 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 22 Aug 2024 12:10:38 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v3]
In-Reply-To: <x8sPsS6rvQ5PLpgVyfNLqCd51SY0ZpIYfIOphe0tfIg=.42e89e4a-8c52-490a-b251-5a118c43624d@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <h-GlRFJq7QB5l3ExjhqONq1G72I5GZhUErIzDOU4qTM=.dd5e4a20-54ac-4301-bba9-15a9b2525064@github.com>
 <x8sPsS6rvQ5PLpgVyfNLqCd51SY0ZpIYfIOphe0tfIg=.42e89e4a-8c52-490a-b251-5a118c43624d@github.com>
Message-ID: <ZxAuorRmwwMW28sBijBXqa0dTif0aBz1oupurYsvG9c=.ef3ad897-09bb-4e18-ab73-d8e1d732a2ae@github.com>

On Thu, 22 Aug 2024 11:27:27 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI exportation
>
> src/hotspot/share/opto/library_call.cpp line 3733:
> 
>> 3731:   // TLS
>> 3732:   Node* tls_ptr = _gvn.transform(new ThreadLocalNode());
>> 3733:   Node* last_continuation_offset = basic_plus_adr(top(), tls_ptr, in_bytes(JavaThread::cont_entry_offset()));
> 
> Could you please export `JavaThread::_cont_entry` and `ContinuationEntry::_pin_count` to JVMCI? Thanks!
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 688691fb976..a25ecd2bab5 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -35,6 +35,7 @@
>  #include "oops/methodCounters.hpp"
>  #include "oops/objArrayKlass.hpp"
>  #include "prims/jvmtiThreadState.hpp"
> +#include "runtime/continuationEntry.hpp"
>  #include "runtime/deoptimization.hpp"
>  #include "runtime/flags/jvmFlag.hpp"
>  #include "runtime/osThread.hpp"
> @@ -244,10 +245,13 @@
>    nonstatic_field(JavaThread,                  _held_monitor_count,                           intx)                                  \
>    nonstatic_field(JavaThread,                  _lock_stack,                                   LockStack)                             \
>    nonstatic_field(JavaThread,                  _om_cache,                                     OMCache)                               \
> +  nonstatic_field(JavaThread,                  _cont_entry,                                   ContinuationEntry*)                    \
>    JVMTI_ONLY(nonstatic_field(JavaThread,       _is_in_VTMS_transition,                        bool))                                 \
>    JVMTI_ONLY(nonstatic_field(JavaThread,       _is_in_tmp_VTMS_transition,                    bool))                                 \
>    JVMTI_ONLY(nonstatic_field(JavaThread,       _is_disable_suspend,                           bool))                                 \
>                                                                                                                                       \
> +  nonstatic_field(ContinuationEntry,           _pin_count,                                    uint32_t)                              \
> +                                                                                                                                     \
>    nonstatic_field(LockStack,                   _top,                                          uint32_t)                              \
>                                                                                                        ...

Done (only tested that it builds).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1726932124

From coleenp at openjdk.org  Thu Aug 22 12:30:06 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 22 Aug 2024 12:30:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <4FCg8K0oXo8mO47HSpZJ5Y4qS6oxspsM4Juqdj0mLkg=.9f0ef8c9-8f2d-44d5-ba56-348e8159c9a5@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <4FCg8K0oXo8mO47HSpZJ5Y4qS6oxspsM4Juqdj0mLkg=.9f0ef8c9-8f2d-44d5-ba56-348e8159c9a5@github.com>
Message-ID: <alF4uvf0FUN_1EnHNe6Hyf_qIRk_r_cBj5hlvr8RR5Y=.a1a39f27-34ba-4f16-985b-b84f49321ff9@github.com>

On Thu, 22 Aug 2024 09:12:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> I am surprised that this patch is so small. I would have assumed a lot of code exists that unconditionally assumes we always can encode decode Klass*<->narrowKlass.
> 
> I looked through the typical cases (eg Klass validation) and all of them seem to be okay. I will keep looking.

Thanks for looking at this @tstuefe. I was pleased that the change was small but once we identify the classes as AbstractClass instead of Class in metaspace, it just falls out. I thought CDS would have more changes, but CDS is all in one space and doesn't differentiate.  It's good that the only time we compress and uncompress klass pointers is when we get them out of an object and this should keep it that way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2304546143

From liach at openjdk.org  Thu Aug 22 12:53:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 12:53:03 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
In-Reply-To: <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>
Message-ID: <4r6JLOM2r7tytLhgb0m2YfbMWI1wsbIMM9AWE12vQ5k=.f65943fd-0732-4916-87c1-ebb356fe2129@github.com>

On Thu, 22 Aug 2024 11:54:48 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> test/micro/org/openjdk/bench/jdk/classfile/ConstantPoolBuildingClassEntry.java line 64:
> 
>> 62:         builder = ConstantPoolBuilder.of();
>> 63:         classDescs = List.of(
>> 64:                 CD_Byte, CD_Object, CD_Long.arrayType(), CD_String, CD_String, CD_Object, CD_Short,
> 
> Should this include some primitive class descs? I only see wrapper types like `CD_Integer`

Unfortunately primitive types aren't encoded by class entries, but accessed by getstatic on Wrapper's TYPE field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1726996341

From liach at openjdk.org  Thu Aug 22 13:35:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 13:35:28 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
Message-ID: <WSNFEvaB6MBD-WwCaz3jCX5T7RtL_P2Cbyj0t20nxmw=.ccf7face-e4d7-4f59-a593-b2e7bddab2f7@github.com>

> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.

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:

 - Improve benchmark as suggested
 - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
 - Fix microbenchmark
 - Improve jmh
 - 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20667/files
  - new: https://git.openjdk.org/jdk/pull/20667/files/9862ccb2..da9c6d82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20667&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20667&range=00-01

  Stats: 1904 lines in 24 files changed: 1796 ins; 51 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/20667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20667/head:pull/20667

PR: https://git.openjdk.org/jdk/pull/20667

From redestad at openjdk.org  Thu Aug 22 13:35:28 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 22 Aug 2024 13:35:28 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <4r6JLOM2r7tytLhgb0m2YfbMWI1wsbIMM9AWE12vQ5k=.f65943fd-0732-4916-87c1-ebb356fe2129@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>
 <4r6JLOM2r7tytLhgb0m2YfbMWI1wsbIMM9AWE12vQ5k=.f65943fd-0732-4916-87c1-ebb356fe2129@github.com>
Message-ID: <9wOdVQOrX_pTEkk8WbD6_MkBe4TUp0vvQqL72b7blas=.07bb7c4d-43e0-4d72-a5e3-9ea188b4801a@github.com>

On Thu, 22 Aug 2024 12:50:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/classfile/ConstantPoolBuildingClassEntry.java line 64:
>> 
>>> 62:         builder = ConstantPoolBuilder.of();
>>> 63:         classDescs = List.of(
>>> 64:                 CD_Byte, CD_Object, CD_Long.arrayType(), CD_String, CD_String, CD_Object, CD_Short,
>> 
>> Should this include some primitive class descs? I only see wrapper types like `CD_Integer`
>
> Unfortunately primitive types aren't encoded by class entries, but accessed by getstatic on Wrapper's TYPE field.

Ok, good. Maybe add a comment that this collection of descs deliberately omits primitive types since they would not usually end up in this code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1727068272

From redestad at openjdk.org  Thu Aug 22 13:48:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 22 Aug 2024 13:48:07 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <WSNFEvaB6MBD-WwCaz3jCX5T7RtL_P2Cbyj0t20nxmw=.ccf7face-e4d7-4f59-a593-b2e7bddab2f7@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <WSNFEvaB6MBD-WwCaz3jCX5T7RtL_P2Cbyj0t20nxmw=.ccf7face-e4d7-4f59-a593-b2e7bddab2f7@github.com>
Message-ID: <vS3YGpvG6rGt4E9J2IszN42bOcBHstdsrm8EYltWAQE=.64c3b70c-4b2d-469a-a336-117fcca343fe@github.com>

On Thu, 22 Aug 2024 13:35:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> 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:
> 
>  - Improve benchmark as suggested
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Fix microbenchmark
>  - Improve jmh
>  - 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 372:

> 370:      * }
> 371:      * }
> 372:      * This is converted to explicit initialization to avoid bootstrap overhead.

Have you measured this to be true and useful? Static array initializers are bulky at a bytecode level so sometimes just generating on the fly carries insignicant overhead. Then the `UtilTest` assertion test wouldn't really be needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1727092745

From liach at openjdk.org  Thu Aug 22 13:54:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Aug 2024 13:54:03 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <9wOdVQOrX_pTEkk8WbD6_MkBe4TUp0vvQqL72b7blas=.07bb7c4d-43e0-4d72-a5e3-9ea188b4801a@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>
 <4r6JLOM2r7tytLhgb0m2YfbMWI1wsbIMM9AWE12vQ5k=.f65943fd-0732-4916-87c1-ebb356fe2129@github.com>
 <9wOdVQOrX_pTEkk8WbD6_MkBe4TUp0vvQqL72b7blas=.07bb7c4d-43e0-4d72-a5e3-9ea188b4801a@github.com>
Message-ID: <reCOVWHfs5acjd0OQdTOa6JJMwfXgWcVIaohD4uWe6M=.2eec5211-4323-47a1-a147-d209fe8d2089@github.com>

On Thu, 22 Aug 2024 13:32:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Unfortunately primitive types aren't encoded by class entries, but accessed by getstatic on Wrapper's TYPE field.
>
> Ok, good. Maybe add a comment that this collection of descs deliberately omits primitive types since they would not usually end up in this code?

Uh, I mean it's a class entry... and class file format prohibits primitives in class entries. I would deduce that information from the benchmark name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1727104037

From redestad at openjdk.org  Thu Aug 22 14:38:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 22 Aug 2024 14:38:03 GMT
Subject: RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc)
 [v2]
In-Reply-To: <reCOVWHfs5acjd0OQdTOa6JJMwfXgWcVIaohD4uWe6M=.2eec5211-4323-47a1-a147-d209fe8d2089@github.com>
References: <u27FzM_-LCZNaASmmNvdKbbRQObex61xMdj45kp6juM=.b2279002-03f8-44f6-b296-b8b7e13edfa7@github.com>
 <7bsaTWFgj5ZY5F7b0lJI-6CIxbVbfPn8Mm56ZNvj3XI=.f4541ec7-9924-4fad-93f3-a5105ed81c25@github.com>
 <4r6JLOM2r7tytLhgb0m2YfbMWI1wsbIMM9AWE12vQ5k=.f65943fd-0732-4916-87c1-ebb356fe2129@github.com>
 <9wOdVQOrX_pTEkk8WbD6_MkBe4TUp0vvQqL72b7blas=.07bb7c4d-43e0-4d72-a5e3-9ea188b4801a@github.com>
 <reCOVWHfs5acjd0OQdTOa6JJMwfXgWcVIaohD4uWe6M=.2eec5211-4323-47a1-a147-d209fe8d2089@github.com>
Message-ID: <E30eLJFDyMZs0D3wryJJgjOUQnxKrr72YK3AWnk-wAs=.16bc530a-dc6b-4157-902b-5da0cdc6619a@github.com>

On Thu, 22 Aug 2024 13:51:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ok, good. Maybe add a comment that this collection of descs deliberately omits primitive types since they would not usually end up in this code?
>
> Uh, I mean it's a class entry... and class file format prohibits primitives in class entries. I would deduce that information from the benchmark name.

Yes, obvious in hind-sight, but comments are good to remind readers of context that might not be obvious at a glance or without paging in the full context.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20667#discussion_r1727181581

From kvn at openjdk.org  Thu Aug 22 15:54:08 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 22 Aug 2024 15:54:08 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v3]
In-Reply-To: <TgQMvUFE34-MAv_nhNUTAEA8hl4vFxKYMkVtouNIud0=.e207cebf-7baf-4b1e-8fad-97687f52ba17@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <TgQMvUFE34-MAv_nhNUTAEA8hl4vFxKYMkVtouNIud0=.e207cebf-7baf-4b1e-8fad-97687f52ba17@github.com>
Message-ID: <XZNNKKp_ourF0aLdA1yiIVWXBGUZGsUWyCJs6_erBIY=.7edb701d-271c-47e9-878f-8f6d33036341@github.com>

On Thu, 22 Aug 2024 12:10:37 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
>> 
>> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
>> 
>> Testing: jdk_jfr, loom testing
>> 
>> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JVMCI exportation

Marked as reviewed by kvn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20664#pullrequestreview-2255034428

From kvn at openjdk.org  Thu Aug 22 15:54:08 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 22 Aug 2024 15:54:08 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v3]
In-Reply-To: <X54g13BrvobyWpWIauGTu60hNUOY3ngmO8KGN1FwLtk=.e8e79849-9fff-45a1-b1a0-e1ca38a74504@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
 <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
 <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>
 <WP32qs-MFn1ILf3fy6sXVsO2s7uFksJh3Nj9vIHkHvg=.d8ffb5b8-6f7c-42ee-8c04-24275d6b5def@github.com>
 <wE7-j38wxrnGVW-UPE_jAFGD3hQDNNt2bgyD3IK9xz8=.4daca633-cdc2-4c62-92b9-95efb26d7b62@github.com>
 <X54g13BrvobyWpWIauGTu60hNUOY3ngmO8KGN1FwLtk=.e8e79849-9fff-45a1-b1a0-e1ca38a74504@github.com>
Message-ID: <v_NfukLQ8d-ViMIpHD2abtRH0V7mb91KMSfIMTlpb2A=.4238c2f0-7937-4e42-80e6-59706cae5663@github.com>

On Thu, 22 Aug 2024 11:21:46 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Is it an implicit invariant that execution always continues in the interpreter after an uncommon trap? I.e., I don't need to explicitly tell it to "re-execute" there?
>
> It is updated to use Action::none to keep the nmethod. The trap code picks up the correct bytecode (invokestatic) from the trap scope. So after unrolling the host method (the inliner), the trap bytecode (i.e., the invokestatic call to Continuation.pin() or unpin()) is re-executed in the interpreter. This is also without setting the explicit re-execute state (which may mean something else).

Yes, we should not throw out compiled nmethod if one thread need to got into Interpreter and throw an exception.
Other threads will continue to use this nmethod.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1727404499

From naoto at openjdk.org  Thu Aug 22 16:20:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Aug 2024 16:20:34 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats some
 numbers (few vs many)
Message-ID: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>

Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/20680/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20680&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338690
  Stats: 112 lines in 3 files changed: 64 ins; 39 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20680.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20680/head:pull/20680

PR: https://git.openjdk.org/jdk/pull/20680

From egahlin at openjdk.org  Thu Aug 22 16:46:03 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 Aug 2024 16:46:03 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v5]
In-Reply-To: <nT9FzW3e3iSRf8ViNqKxnpgNr3y68fh7NNbmUXGHAw8=.f9a5c6c3-ae25-4d61-90a2-6c287be83a19@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <nT9FzW3e3iSRf8ViNqKxnpgNr3y68fh7NNbmUXGHAw8=.f9a5c6c3-ae25-4d61-90a2-6c287be83a19@github.com>
Message-ID: <mXmlPh5QiqAMwJJb8QYPJtJ1Moz5H9Gxw9EKt3ueeOE=.d021bdb8-2e7b-4841-9d84-7ec33d34f477@github.com>

On Wed, 21 Aug 2024 18:26:20 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
>> 
>> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
>> 
>> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
>> 
>> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - pin state conditional delivered using event writer object
>  - Merge branch '8338417' of github.com:mgronlun/jdk into 8338417
>  - update test comment
>  - hoist pinVirtualThread
>  - 8338417

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20588#pullrequestreview-2255152669

From prappo at openjdk.org  Thu Aug 22 17:26:12 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Aug 2024 17:26:12 GMT
Subject: RFR: JDK-8322979: Add informative discussion to Modifier [v4]
In-Reply-To: <PEM-6f-vPXIgDPaXiYOWX9lVrSgIpuavUW00j_Q7TxI=.abea3ec0-3e67-44ea-b9ae-804121198475@github.com>
References: <w2pD6VH11lviAKmwHkKuJbxYmDcbRtfHTnSmJxO3gWo=.c6996b14-dfdd-460b-a2d2-df325562f792@github.com>
 <nWRuECg40mF-hrg0W0bXRoifp2GIsMZMu5LDnygTrK8=.208cfb34-6d54-4fe1-a38e-3b07e369bcff@github.com>
 <PEM-6f-vPXIgDPaXiYOWX9lVrSgIpuavUW00j_Q7TxI=.abea3ec0-3e67-44ea-b9ae-804121198475@github.com>
Message-ID: <5eeSuLv1CIm94VfmMg0gwUq9pyL3It56aK2ZNC3i8Ro=.fa768973-f6f6-470b-b4e7-1265969f9c8a@github.com>

On Thu, 11 Jan 2024 09:38:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Modifier.java line 238:
>> 
>>> 236:      * modifiers of a class or member, source-level modifiers that do
>>> 237:      * not <em>not</em> have a constant in the this class should be
>>> 238:      * included and ordered consistent with the full recommended
>> 
>> Suggestion:
>> 
>>      * included and ordered consistently with the full recommended
>
> Yes, "ordered consistently with" or "with order consistent with", I think both will work here.

I think, Joe might be considering "consistent" to be [flat](https://en.wikipedia.org/wiki/Flat_adverb).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17338#discussion_r1727539409

From dlong at openjdk.org  Thu Aug 22 19:51:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 22 Aug 2024 19:51:07 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v3]
In-Reply-To: <v_NfukLQ8d-ViMIpHD2abtRH0V7mb91KMSfIMTlpb2A=.4238c2f0-7937-4e42-80e6-59706cae5663@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <C9tdYI4JSn3SoT0yWGfAzDpfdYdhFoPDbYyMX-kfSu4=.2f776154-a819-4e42-bf05-348b3bbce75a@github.com>
 <6bsD-W2hquUgwdv7sxyEZHABzNqTNLyxm3d-GMMOR1g=.6d8c102b-e1c7-4408-aadf-6823c52f2ce0@github.com>
 <H364jemZHlhGw-U4XRo9xs04v9CB1QnMmUAJh3JH5c8=.839984f8-69d7-47ee-b072-5fe6e58f42e5@github.com>
 <eEHfXpezQy26_b7My98U-6nV1cZ-eOWDPd3bcnj_VCc=.5f08dc1e-b2b2-4050-bafd-388ec9a97d94@github.com>
 <WP32qs-MFn1ILf3fy6sXVsO2s7uFksJh3Nj9vIHkHvg=.d8ffb5b8-6f7c-42ee-8c04-24275d6b5def@github.com>
 <wE7-j38wxrnGVW-UPE_jAFGD3hQDNNt2bgyD3IK9xz8=.4daca633-cdc2-4c62-92b9-95efb26d7b62@github.com>
 <X54g13BrvobyWpWIauGTu60hNUOY3ngmO8KGN1FwLtk=.e8e79849-9fff-45a1-b1a0-e1ca38a74504@github.com>
 <v_NfukLQ8d-ViMIpHD2abtRH0V7mb91KMSfIMTlpb2A=.4238c2f0-7937-4e42-80e6-59706cae5663@github.com>
Message-ID: <iSbmtMeIsrzPMX32fTrURdhytW6fUeIVDOQjvJHz1nQ=.4568de2a-39a5-4929-a0ab-07c867e7a34c@github.com>

On Thu, 22 Aug 2024 15:50:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> It is updated to use Action::none to keep the nmethod. The trap code picks up the correct bytecode (invokestatic) from the trap scope. So after unrolling the host method (the inliner), the trap bytecode (i.e., the invokestatic call to Continuation.pin() or unpin()) is re-executed in the interpreter. This is also without setting the explicit re-execute state (which may mean something else).
>
> Yes, we should not throw out compiled nmethod if one thread need to got into Interpreter and throw an exception.
> Other threads will continue to use this nmethod.

> This is also without setting the explicit re-execute state (which may mean something else).

I think reexecute is implicitly set for uncommon traps, and the explicit flag is for deoptimization safepoints.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20664#discussion_r1727725892

From dholmes at openjdk.org  Thu Aug 22 22:52:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Aug 2024 22:52:05 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <CXP90x_kG6QAqALKAtq7kv7NhIM4gAjq646Iln0Jhlg=.e66ac47f-90fc-4381-910c-711c433b3db9@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
 <CXP90x_kG6QAqALKAtq7kv7NhIM4gAjq646Iln0Jhlg=.e66ac47f-90fc-4381-910c-711c433b3db9@github.com>
Message-ID: <KFw8bJ-sY91r6fKxN2XxxkuxKmG4UOq0gMCiMEJgHMg=.4c3ba368-880a-4e73-a695-cbaa9ba776e5@github.com>

On Thu, 22 Aug 2024 08:54:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Sorry but I don't understand the point of changing build-time constructs using `ifdef STATIC_BUILD` into what appear to be runtime checks, but the result of which is already determined at build time. These are not really runtime checks.
>
> @dholmes-ora 
> 
>> Sorry but I don't understand the point of changing build-time constructs using ifdef STATIC_BUILD into what appear to be runtime checks, but the result of which is already determined at build time. 
> 
> I apologize. I did not express the intent of this change clear enough.
> 
> The background is that we want to build and test statically linked native libraries. Currently, building a statically linked version requires recompiling all native source code into a completely new set of .o files, which are then linked into a static library.
> 
> This is extremely wasteful. Most of the code is completely identical for static and dynamic libraries. To fix this, me, Jiangli and her team have been working on a way to get around this.
> 
> By moving the ifdef check to a new file that just contains a single function, we only need to compile this single file twice -- once for the static library, and once for the dynamic library. All other .o files is compiled just once, and then you link "all other files" + "the one special file for your kind of library" to get what you want. 
> 
> Unfortunately, there is also one more blocker before this can be achieved. That is the reason the corresponding change in the build system is not included in this patch. (So this is a preparation for these future changes, but not the complete solution.) The missing part is that the `[JNI|Agent]_On[Un]Load` functions need to be able to use the static linked naming scheme, even for dynamically linked libraries. This is trivial per se, but requires a spec change, which has not yet happened.
> 
> The reason I want to get this partial solution into the mainline right now, instead of waiting for the spec change and the complete build system fix, is that these new functions for checking for static/dynamic are needed by additional changes that Jiangli have created upstream, and that I am trying to help her get integrated. (The goal of these changes is to make not just static libraries, but to link these static libraries with the java launcher into a statically linked launcher, which is a pre-requisite for the rest of the Hermetic Java story.)

@magicus is the final intent here that this one magic file will be compiled first with an inline declaration such that when the other files containing the apparent runtime check get compiled, it can actually be determined at build time and so have the same effects as the old ifdef logic?

Otherwise it concerns me that a build-time issue that affects a handful of people becomes a runtime issue that affects every single instance of a running Java program.

There are also other source-level solutions possible here by refactoring the code that has static vs dynamic linking dependencies into its own files and the build system can then select which set of files to compile.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2305875408

From jbhateja at openjdk.org  Fri Aug 23 05:46:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 23 Aug 2024 05:46:29 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v4]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <cKDr9VIe28p0YcN8tr_vwsuYuhIBPmoT7ty7-QL__1s=.476d9fe9-e77b-4e54-941f-ed7bb1946581@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Defaulting to index wrapping scheme.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/e24632cb..d7ad6887

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=02-03

  Stats: 424 lines in 39 files changed: 0 ins; 361 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Fri Aug 23 05:58:05 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 23 Aug 2024 05:58:05 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v4]
In-Reply-To: <cKDr9VIe28p0YcN8tr_vwsuYuhIBPmoT7ty7-QL__1s=.476d9fe9-e77b-4e54-941f-ed7bb1946581@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <cKDr9VIe28p0YcN8tr_vwsuYuhIBPmoT7ty7-QL__1s=.476d9fe9-e77b-4e54-941f-ed7bb1946581@github.com>
Message-ID: <e9Mqyh8KO_t4YVJAbRiMK-WcPVa-WE6enXya7cnBGo4=.e8768c2e-97ed-4a6b-9da1-66711fc340e6@github.com>

On Fri, 23 Aug 2024 05:46:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Defaulting to index wrapping scheme.

Hi @rose00 , @PaulSandoz , @sviswa7,

Latest patch removed explicit wrap argument passed to selectFrom API, instead uses wrapping scheme as a mitigation strategy to handle OOB partially wrapped indexes. 

Summarizing the new scheme for index wrapping:-
 - Shuffle always holds indexes in valid vector index range or partially wraps OOB indexes.
 - Following are the shuffle creation intercepts 
       - VectorShuffle.fromArray -  Partially wraps OOB indexes
       - iotaShuffle                      -  Accepts explicit wrap argument to chooses b/w wrapping vs partial wrapping of OOB indexes.
       - Vector.toShuffle              - Partially wraps OOB indexes.   
- Partial wrapping generate -ve indexes for OOB indices after wrapping them into valid index range.
      - Objective is to delegate mitigation strategy to subsequent APIs which can either generate a IndexOutOfBounds exception or  create valid index by adding vector length.
     -  An important point to mention here is that partially wrapped indexing schemes first wraps OOB index  ( index < 0 OR  index >= VECLEN) into valid index range and then subtracts VECLEN from wrapped index to generate a -ve number in [-VECLEN: -1] range.
- With new scheme we are choosing wrapping as a default mitigation strategy hence only client which make effective use of a partially wrapped indexes is two vector re-arrange, which uses it to compute the mask for blending two permuted vectors. 
-  Two vector re-arrange and selectFrom API differ in terms of acceptable index range, while former accepts shuffle indices in single vector index range [0:VECLEN) latter operates on two vector index range [0:2*VECLEN).

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2306344606

From jbhateja at openjdk.org  Fri Aug 23 06:09:48 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 23 Aug 2024 06:09:48 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v5]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <7e5pWnvjqk-dQYNeaZjFzXcd5WlzniZPl5T4l1rKQGE=.0882bcd4-e307-4a29-aa41-5496ee029a60@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Removing redundant checkIndex routine

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/d7ad6887..6cb1a46d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=03-04

  Stats: 35 lines in 7 files changed: 0 ins; 35 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From alanb at openjdk.org  Fri Aug 23 07:38:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Aug 2024 07:38:03 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v5]
In-Reply-To: <nT9FzW3e3iSRf8ViNqKxnpgNr3y68fh7NNbmUXGHAw8=.f9a5c6c3-ae25-4d61-90a2-6c287be83a19@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <nT9FzW3e3iSRf8ViNqKxnpgNr3y68fh7NNbmUXGHAw8=.f9a5c6c3-ae25-4d61-90a2-6c287be83a19@github.com>
Message-ID: <VwZ9UpAQKH40rlc2e-jTDJ-xRe6mxjxVgpnwryHxyp8=.728b1b87-d9cc-4a8a-85d5-6e750630d10d@github.com>

On Wed, 21 Aug 2024 18:26:20 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
>> 
>> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
>> 
>> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
>> 
>> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - pin state conditional delivered using event writer object
>  - Merge branch '8338417' of github.com:mgronlun/jdk into 8338417
>  - update test comment
>  - hoist pinVirtualThread
>  - 8338417

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20588#pullrequestreview-2256567425

From mcimadamore at openjdk.org  Fri Aug 23 09:03:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 Aug 2024 09:03:32 GMT
Subject: RFR: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI [v10]
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <HA3_7MIOfWFK3QKeLQUsXDMtbDGiEBaTnijTfbQxbj8=.17f3d5b1-ad76-431f-91a5-b2f95816db7a@github.com>

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into restricted_jni
 - Merge branch 'master' into restricted_jni
 - Address review comments
 - Add note on --illegal-native-access default value in the launcher help
 - Address review comment
 - Refine warning text for JNI method binding
 - Address review comments
   Improve warning for JNI methods, similar to what's described in JEP 472
   Beef up tests
 - Address review comments
 - Fix another typo
 - Fix typo
 - ... and 3 more: https://git.openjdk.org/jdk/compare/f7ea738c...04622748

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19213/files
  - new: https://git.openjdk.org/jdk/pull/19213/files/ff51ac6a..04622748

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19213&range=08-09

  Stats: 51278 lines in 1477 files changed: 28775 ins; 15348 del; 7155 mod
  Patch: https://git.openjdk.org/jdk/pull/19213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19213/head:pull/19213

PR: https://git.openjdk.org/jdk/pull/19213

From mgronlun at openjdk.org  Fri Aug 23 09:23:05 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 Aug 2024 09:23:05 GMT
Subject: RFR: 8338417: Explicitly pin a virtual thread before acquiring the
 JFR string pool monitor [v5]
In-Reply-To: <VwZ9UpAQKH40rlc2e-jTDJ-xRe6mxjxVgpnwryHxyp8=.728b1b87-d9cc-4a8a-85d5-6e750630d10d@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
 <nT9FzW3e3iSRf8ViNqKxnpgNr3y68fh7NNbmUXGHAw8=.f9a5c6c3-ae25-4d61-90a2-6c287be83a19@github.com>
 <VwZ9UpAQKH40rlc2e-jTDJ-xRe6mxjxVgpnwryHxyp8=.728b1b87-d9cc-4a8a-85d5-6e750630d10d@github.com>
Message-ID: <-JC36w76zmE373RVfQY7ezo9anT8bSZOPR3vpKVyrkk=.9b33aa51-cbd3-46b7-b250-de97b75d2492@github.com>

On Fri, 23 Aug 2024 07:35:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - pin state conditional delivered using event writer object
>>  - Merge branch '8338417' of github.com:mgronlun/jdk into 8338417
>>  - update test comment
>>  - hoist pinVirtualThread
>>  - 8338417
>
> Marked as reviewed by alanb (Reviewer).

Thank you for your reviews, @AlanBateman, @dholmes-ora and @egahlin.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20588#issuecomment-2306670631

From mgronlun at openjdk.org  Fri Aug 23 09:21:07 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 Aug 2024 09:21:07 GMT
Subject: RFR: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin() [v3]
In-Reply-To: <XZNNKKp_ourF0aLdA1yiIVWXBGUZGsUWyCJs6_erBIY=.7edb701d-271c-47e9-878f-8f6d33036341@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
 <TgQMvUFE34-MAv_nhNUTAEA8hl4vFxKYMkVtouNIud0=.e207cebf-7baf-4b1e-8fad-97687f52ba17@github.com>
 <XZNNKKp_ourF0aLdA1yiIVWXBGUZGsUWyCJs6_erBIY=.7edb701d-271c-47e9-878f-8f6d33036341@github.com>
Message-ID: <7kDAWMRy5cWRV_WFMhcQJ0i6gkVNMNmvutUQNyUvSiQ=.95990a93-0346-4e65-b617-ff6b3598780c@github.com>

On Thu, 22 Aug 2024 15:51:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JVMCI exportation
>
> Marked as reviewed by kvn (Reviewer).

Thank you for your reviews and comments, @vnkozlov, @dean-long, @TobiHartmann and @mur47x111.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20664#issuecomment-2306664937

From mgronlun at openjdk.org  Fri Aug 23 09:29:08 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 Aug 2024 09:29:08 GMT
Subject: Integrated: 8338745: Intrinsify Continuation.pin() and
 Continuation.unpin()
In-Reply-To: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
References: <SRGuIizZxWf7tm0X255IxROOcpR2cvucdDUscTAbPbg=.a0a37719-6fb5-4e36-95a1-c7bd6f3ed529@github.com>
Message-ID: <vL5BnC6MiHN0R2A9ibNwx3hgaiv4pauXw9La-E_1TAw=.ed76750e-f736-4587-9737-8729bc796797@github.com>

On Wed, 21 Aug 2024 20:11:05 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Please help review this change set that implements C2 intrinsics for jdk.internal.vm.Continuation.pin() and jdk.internal.vm.Continuation.unpin().
> 
> This work is a consequence of [JDK-8338417](https://bugs.openjdk.org/browse/JDK-8338417), which required us to introduce explicit pin constructs for Virtual threads in a relatively performance-sensitive path.
> 
> Testing: jdk_jfr, loom testing
> 
> Comment: I changed the type of the ContinuationEntry::_pin_count field from uint to uin32_t to make the size explicit and to access it uniformly from the intrinsic code using T_INT.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: fead3cf5
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fead3cf54130e3ab10f94a94dfbd382e4cb1e597
Stats:     109 lines in 9 files changed: 105 ins; 0 del; 4 mod

8338745: Intrinsify Continuation.pin() and Continuation.unpin()

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/jdk/pull/20664

From mgronlun at openjdk.org  Fri Aug 23 09:32:08 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 23 Aug 2024 09:32:08 GMT
Subject: Integrated: 8338417: Explicitly pin a virtual thread before acquiring
 the JFR string pool monitor
In-Reply-To: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
References: <uaBrtPI_neB7vQNZaeYauQEz2rX4blqTJXVNlVOxiLI=.f72e7ea4-b254-4ce8-86e4-a08b7fe50363@github.com>
Message-ID: <sCOwGO3YIHeK7DA3xM7M871QmUh-qnZ2pCncjNNNdx0=.8e005f7d-b807-4ac9-977d-0bfcf7b2db3c@github.com>

On Wed, 14 Aug 2024 20:53:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Explicitly pin a virtual thread before acquiring the JFR string pool monitor because migrating a carrier thread local event writer object onto another carrier thread is impossible.
> 
> During event commit, the thread is in a critical section because it has loaded a carrier thread local event writer object. For virtual threads, a contended monitor, such as a synchronized block, is a point where a thread could become unmounted.
> 
> A monitor guards the JFR string pool, but remounting a virtual thread onto another carrier is impossible because of the event writer.
> 
> Therefore, it's imperative to use explicit pin constructs to prevent unmounting at this location. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 69bd227e
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69bd227e6c497eb82c46ab85125610c0b44dc04e
Stats:     226 lines in 6 files changed: 189 ins; 10 del; 27 mod

8338417: Explicitly pin a virtual thread before acquiring the JFR string pool monitor

Reviewed-by: alanb, egahlin, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/20588

From ihse at openjdk.org  Fri Aug 23 10:07:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 23 Aug 2024 10:07:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <KFw8bJ-sY91r6fKxN2XxxkuxKmG4UOq0gMCiMEJgHMg=.4c3ba368-880a-4e73-a695-cbaa9ba776e5@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
 <CXP90x_kG6QAqALKAtq7kv7NhIM4gAjq646Iln0Jhlg=.e66ac47f-90fc-4381-910c-711c433b3db9@github.com>
 <KFw8bJ-sY91r6fKxN2XxxkuxKmG4UOq0gMCiMEJgHMg=.4c3ba368-880a-4e73-a695-cbaa9ba776e5@github.com>
Message-ID: <TUBTQ0DEb3uxCS4KxE26mHQnGVOdjsMDS1lGqISZMQs=.bde7f5ee-a3e0-4564-abfa-760cda29547b@github.com>

On Thu, 22 Aug 2024 22:49:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> is the final intent here that this one magic file will be compiled first with an inline declaration such that when the other files containing the apparent runtime check get compiled, it can actually be determined at build time and so have the same effects as the old ifdef logic?

Theoretically, this is a valid complaint: what is now inlined at compilation time will require an additional function call. And yes, if that had been a performance issue, I would have needed to do something like that. 

But, if you look at the actual functions that are affected, you can see that it is just a handful of calls that are all done at startup time. Adding like half a dozen calls to a trivial function before loading a DLL will not even be measurable, compared to all the work the OS will do afterwards when loading the DLL. So no, I do not intend to complicate the code further. Any impact of this code is measured in a few additional machine code operations.

> There are also other source-level solutions possible here by refactoring the code that has static vs dynamic linking dependencies into its own files and the build system can then select which set of files to compile.

There are definitely refactoring/restructuring opportunities to be had, both in Hotspot and in the JDK libraries! Overall, I have found a lot of redundant work, duplicated code, and legacy code that does not make sense anymore (like trying to differentiate between a JRE and a JDK) when setting up the initial environment wrt the basic dynamic libraries.

But in the grand scheme of things, I don't think it is reasonable that we spend too much efforts on cleaning up that. While it is definitely a "lava flow" anti-pattern, it mostly works, and starting to poke around will risk breaking things. We don't have a good testing story for the JDK bootstrapping. This is the same problem as the build is facing: you would need to have a ton of differently configured environments to be able to test all possible installations and paths etc. 

The patch presented here seem to me to be a cautious middle ground -- fixing what is needed to be able to progress, but doing so in a way that every single change is trivially and obviously correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2306752185

From jpai at openjdk.org  Fri Aug 23 10:50:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Aug 2024 10:50:34 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest
Message-ID: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>

Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?

The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.

When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.

As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.

The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.

A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.

-------------

Commit messages:
 - 8338445: close loaders that are not used by the URLClassPath
 - 8338445: add test

Changes: https://git.openjdk.org/jdk/pull/20691/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20691&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338445
  Stats: 195 lines in 2 files changed: 183 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20691/head:pull/20691

PR: https://git.openjdk.org/jdk/pull/20691

From redestad at openjdk.org  Fri Aug 23 12:38:11 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 23 Aug 2024 12:38:11 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type switch
 methods that don't use them
Message-ID: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>

This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 

Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.

-------------

Commit messages:
 - Logic fix, improve documentation
 - Improve comments, remove stray debug scaffolding
 - Avoid binding in lists of EnumDesc and extra classes in type switches when not needed

Changes: https://git.openjdk.org/jdk/pull/20693/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20693&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338906
  Stats: 95 lines in 1 file changed: 44 ins; 10 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/20693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20693/head:pull/20693

PR: https://git.openjdk.org/jdk/pull/20693

From liach at openjdk.org  Fri Aug 23 13:09:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Aug 2024 13:09:02 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them
In-Reply-To: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
Message-ID: <uIEkaY0NJ-N190VF66hEKbJJzy_S0jLzmscofztwh9g=.71108746-0d61-4d71-bb62-847223ca646d@github.com>

On Fri, 23 Aug 2024 12:34:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
> 
> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.

Bytecode generation changes look good. Will wait for another compiler engineer to review.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20693#pullrequestreview-2257191470

From pminborg at openjdk.org  Fri Aug 23 13:49:02 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 23 Aug 2024 13:49:02 GMT
Subject: RFR: 8338728: Misc issues in memory layout javadoc [v2]
In-Reply-To: <CqqWAiXYveYtkmMYnoqD5ux-oUHni7bhLlI_fCl6eLY=.65a0d4e1-abc3-4c06-9c86-4e686d6ff85b@github.com>
References: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>
 <CqqWAiXYveYtkmMYnoqD5ux-oUHni7bhLlI_fCl6eLY=.65a0d4e1-abc3-4c06-9c86-4e686d6ff85b@github.com>
Message-ID: <zRv-Gb9IeqVgSRTq1fRbAfJcNXyrI0tLNAn1cZ5vNyw=.84e3330d-bfde-4d92-ab53-a8d7d01d30a0@github.com>

On Wed, 21 Aug 2024 13:24:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes two minor issues in the `MemoryLayout` javadoc:
>> * the section describing dereference path talks about `P` and `P'` but then only uses `P` in the code;
>> * the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is wrong, as the division returns a negative number for F < 0, which is incorrect
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Clarify javadoc for var handles with dereference path elements
>   * Add test where dereference path element is last element in path

LGTM. Nice with a test even though just for documentation validation.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20659#pullrequestreview-2257299547

From eirbjo at openjdk.org  Fri Aug 23 14:00:13 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 23 Aug 2024 14:00:13 GMT
Subject: RFR: 8338729: Retire the test jdk/java/util/zip/TestZipError.java
Message-ID: <2qQYLW8xwJAtu8UiUmvQVScFmXC61npdY6AYI-Yt5GY=.40c86241-851a-4ce7-9085-ac8bc7356924@github.com>

Please review this test-only, cleanup PR which proposes that we retire the `jdk/java/util/zip/TestZipError.java` test.

The test has fallen out of sync with its original and stated purpose described by its name, `@summary` tag and code comments. The error condition actually being exercised has existing coverage in the `ZipSourceCache` test.

Background:

* The test was initially added in JDK-4615343 (Java 6) to exercise code paths which caused `ZipFile` entry enumeration to throw a `ZipError` (a subclass of `InternalError`).
* After the rewrite of the ZipFile API from native to Java in JDK-8145260 (JDK 9), the Java code now tested no longer throws `ZipError` (The `ZipError` class is no longer used in OpenJDK)
* As part of JDK-8145260, `TestZipError.java` was updated to catch `ZipException` instead of `ZipError` for the expected/passing case. Interestingly, a line was added which caused the test to not simply enumerate the entries of the updated ZipFile, but to also consume the input stream of the entries.
* The added line caused `ZipFileInputStream.initDataOffset` to throw a `ZipException` when the CEN local header offset does not contain the expected LOC header, resulting in a ZipException with the message "ZipFile invalid LOC header (bad signature)". This added line caused the test to (accidentally?) test something which is actually different than its original purpose. 
* The "invalid LOC header" scenario is currently better tested by the `ZipSourceCache` JUnit test, which also runs on non-Windows platforms.
* Note that JDK-8145260 did not update the copyright years in the license header of this file.

Considering all of the above, I suggest that we do not invest resources in bringing the naming, summary and code comments of this test in line with what is actually being tested. Instead, we should simply retire it in favor of the existing `ZipSourceCache` test.

Testing:

* No tests are updated in this PR, I added a `noreg-cleanup` label in the JBS
* By collecting a stack trace, I verified that the `ZipException` caught by `TestZipError` is indeed caused by the LOC header validation logic in `ZipFileInputStream.initDataOffset`
* Similarly, I also verified that `ZipSourceCache` throws on the same condition as `TestZipError`

-------------

Commit messages:
 - Retire the test TestZipError.java

Changes: https://git.openjdk.org/jdk/pull/20660/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20660&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338729
  Stats: 116 lines in 1 file changed: 0 ins; 116 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20660.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20660/head:pull/20660

PR: https://git.openjdk.org/jdk/pull/20660

From pminborg at openjdk.org  Fri Aug 23 14:04:03 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 23 Aug 2024 14:04:03 GMT
Subject: RFR: 8338731: MemoryLayout::offsetHandle can return a negative
 offset
In-Reply-To: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
References: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
Message-ID: <NhPUT3KpdqcC7WHscC0ei6bXCkHkHUwTnu9BDvqY-wE=.801f4070-1083-4da9-ad99-13d0717e2a53@github.com>

On Wed, 21 Aug 2024 13:26:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.
> 
> In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.
> 
> The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.

Nice catch.

Unrelated: I wonder if the performance of:


MH_ADD = lookup.findStatic(Long.class, "sum",
                    MethodType.methodType(long.class, long.class, long.class));
                    


and 


MH_ADD = MethodHandles.publicLookup().findStatic(Long.class, "sum",
                    MethodType.methodType(long.class, long.class, long.class));

Differ?

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20662#pullrequestreview-2257329578
PR Comment: https://git.openjdk.org/jdk/pull/20662#issuecomment-2307163178

From liach at openjdk.org  Fri Aug 23 14:11:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Aug 2024 14:11:03 GMT
Subject: RFR: 8338731: MemoryLayout::offsetHandle can return a negative
 offset
In-Reply-To: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
References: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
Message-ID: <5fSKjI1EWwvNMvUnKncq7KPQ_srA9-qHjDZtEZyPP-A=.7eae8fe1-04e3-4e0d-bf5d-a1195249fff6@github.com>

On Wed, 21 Aug 2024 13:26:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.
> 
> In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.
> 
> The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.

They should have the same performance characteristics. They have different permissions for access checks, and since `Long` is exported public API and `sum` is public both will pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20662#issuecomment-2307175829

From eirbjo at openjdk.org  Fri Aug 23 15:07:38 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 23 Aug 2024 15:07:38 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
Message-ID: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>

Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.

The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.

I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.

A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.

This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

-------------

Commit messages:
 - Update copyright year
 - Deprecate java.util.zip.ZipError for removal

Changes: https://git.openjdk.org/jdk/pull/20642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20642&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336843
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20642/head:pull/20642

PR: https://git.openjdk.org/jdk/pull/20642

From stuefe at openjdk.org  Fri Aug 23 15:23:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 23 Aug 2024 15:23:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <Xi9MiXjLHkqFeeUpKJNsZylEe6V77CHcVLxm0GdZ5Wk=.6f66052d-ce0d-442a-b29f-c2f20d90fcaa@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Hi Coleen,

IIUC, the new "is_in_klass_space" function that now is present in all Metadata children only exists because of the template function in MetadataFactory, right? Just for the purpose of deallocation?

If so, see this proposed addition to your patch: https://gist.github.com/tstuefe/5111c735b12f6d9c3c1d32699d0820f6

This would make Metaspace::deallocate smarter - Metaspace knows whether a given pointer is in class space or not, it can do automatically the right thing. There should be no need to tell it how to deallocate that storage. (If you are worried, in debug builds there are also sanity checks).

If you do this, I think you could remove all variants of "is_in_klass_space" apart from the one in Klass.

src/hotspot/share/memory/allocation.hpp line 319:

> 317:   f(SharedClassPathEntry) \
> 318:   f(RecordComponent) \
> 319:   f(AbstractClass)

This is a minor nit: I assume this new constant is just there to steer allocation down in metaspace away from Class space? This breaks a bit with established pattern, because the type `Klass::type()` returns is still "ClassType", so this new constant never really appears anywhere. Its only point is "its not classtype". You could probably hand down any other constant to Metaspace::allocate, as long as its not `ClassType`.

What we should eventually do, but in a follow up RFE:  modify `Metaspace::allocate` to replace the `MetaspaceObj::Type` parameter with a `MetadataType mdType` parameter. Or a plain "allocate_in_classspace_please" boolean parameter. Because Metaspace::allocate does not really need to know the type of the metadata object. It just needs to know if the caller insists on having the data in class space.

 But lets do this in a follow-up.

src/hotspot/share/oops/instanceKlass.cpp line 456:

> 454: 
> 455:   InstanceKlass* ik;
> 456:   MetaspaceObj::Type type = (parser.is_interface() || parser.is_abstract()) ? MetaspaceObj::AbstractClassType : MetaspaceObj::ClassType;

small nit, const or constexpr?

src/hotspot/share/oops/klass.hpp line 205:

> 203: 
> 204:   void* operator new(size_t size, ClassLoaderData* loader_data, size_t word_size, TRAPS) throw();
> 205: 

Oh ArrayKlass never used this? Its good to move it to InstanceKlass.

src/hotspot/share/oops/klass.hpp line 214:

> 212:   virtual bool is_klass() const { return true; }
> 213: 
> 214:   bool is_in_klass_space() const { return !is_interface() && !is_abstract(); }

This name is misleading. As a caller, I expect a function with this name to make a range check of Klass* to be inside class space range. This is more of a "should be".

(We also write class space with `c` throughout hotspot, its weird to have it with `k` now)

How about, instead: "needs_narrow_klass_id" or "must_be_narrow_encodable" or similar? That clearly says what you want, that this class needs to be encodable with a narrow id for whatever is your reason. This leaves room for future changes (e.g. a possible future where we need narrow klass ids for other reasons than to make heap objects smaller, or where there is no class space anymore).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2256433389
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1728452223
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1728421710
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1728421197
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1728417646

From liach at openjdk.org  Fri Aug 23 15:19:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Aug 2024 15:19:07 GMT
Subject: Integrated: 8338700: AttributeMapper type parameter should be bounded
 by Attribute
In-Reply-To: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
References: <IagJ4J6Kd8ElY2-Ujx4TkquHFnX72vAd7VzXwRTMCNc=.b8aa6b93-c171-4f1d-906c-b57d537a2afa@github.com>
Message-ID: <u-PBQPDp1f7UByX0ruBlT4lj3z-M6H5yxfn4MTJF5_k=.cd808099-f8fc-4a6e-a142-7ec9c593efad@github.com>

On Wed, 21 Aug 2024 23:20:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> A minor oversight in AttributeMapper type parameter bounds, that it should be bounded by Attribute. Only real impact is in BoundAttribute.readAttributes where a cast is now omitted, as other sites of access like Attribute::attributeMapper has already bounded the returned type argument.

This pull request has now been integrated.

Changeset: a461369f
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a461369f16a2d92ab428d14c36dd69fa5942bbc5
Stats:     6 lines in 5 files changed: 0 ins; 0 del; 6 mod

8338700: AttributeMapper type parameter should be bounded by Attribute

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20668

From joehw at openjdk.org  Fri Aug 23 17:19:07 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 23 Aug 2024 17:19:07 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
Message-ID: <TyPROrnyMvjp-lOh_Qjr1L5ouOTaLTpouzdyhjeHHjo=.f6c3bebb-a905-48b5-bad1-c7d06de32087@github.com>

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

Marked as reviewed by joehw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20680#pullrequestreview-2257726181

From rriggs at openjdk.org  Fri Aug 23 18:08:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Aug 2024 18:08:04 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
Message-ID: <XrNegzZMsVcOOiZUzn1eSNTzfN6wN4P_Riznrm5aL5Q=.70b24d65-386d-4dd9-afd8-45b67af114c7@github.com>

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

src/java.base/share/classes/java/text/CompactNumberFormat.java line 905:

> 903:                 divisor = divisors.get(++compactDataIndex);
> 904:             }
> 905:             var noFraction = number.mod(new BigInteger(divisor.toString()))

Why not create the BigInteger from the `divisor.longValue()`.
I see the pattern formatting to a string and BigInteger re-parsing it but why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20680#discussion_r1729330940

From rriggs at openjdk.org  Fri Aug 23 19:04:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Aug 2024 19:04:07 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
Message-ID: <0g7zNVxJLk358bJWsrzIxtuzQAKP7yNVeNJORQKG9p0=.17623b27-64a0-4975-b52b-e3e9dd00b3f9@github.com>

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20680#pullrequestreview-2257919269

From rriggs at openjdk.org  Fri Aug 23 19:04:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Aug 2024 19:04:09 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <XrNegzZMsVcOOiZUzn1eSNTzfN6wN4P_Riznrm5aL5Q=.70b24d65-386d-4dd9-afd8-45b67af114c7@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
 <XrNegzZMsVcOOiZUzn1eSNTzfN6wN4P_Riznrm5aL5Q=.70b24d65-386d-4dd9-afd8-45b67af114c7@github.com>
Message-ID: <CWXAlb_sTDi8hGD5PtzxJWAKlEnPyD2NnzsoTX_9Nk4=.46b2f3be-d7b4-4df8-87ea-5c8ed5380a18@github.com>

On Fri, 23 Aug 2024 17:54:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 905:
> 
>> 903:                 divisor = divisors.get(++compactDataIndex);
>> 904:             }
>> 905:             var noFraction = number.mod(new BigInteger(divisor.toString()))
> 
> Why not create the BigInteger from the `divisor.longValue()`.
> I see the pattern formatting to a string and BigInteger re-parsing it but why?

I guess the range of the divisor may be bigger than a long.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20680#discussion_r1729402019

From jlu at openjdk.org  Fri Aug 23 19:19:03 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Aug 2024 19:19:03 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
Message-ID: <OfjvQZNRpq7ePfaB4xX9BHptY4LqnVhV4GNjmR1LOKQ=.9ad042cf-02c9-4f7a-bb59-ada0f0b1e0fa@github.com>

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

Makes sense to defer the affix matching until the value is rounded. And moving the rounding logic before and using `decimalFormat.getDigitList().getDouble();` looks to be accurate in that regard. LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20680#pullrequestreview-2257951361

From lancea at openjdk.org  Fri Aug 23 19:16:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 Aug 2024 19:16:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <LIZcPDCBAWIe20r1sCN61ZAncxGj43bc81Ssum-e5BU=.46de8e9d-6221-4316-b9d0-8b3a309732e3@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

On a corpus search, found
org.eclipse.jdt.core/search/org/eclipse/jdt/internal/core/search/indexing/AddJarFileToIndex.java references ZipError (16 usages)

sbt/internal/inc/zip/ZipCentralDir.java referenced ZipError(was based off an old copy of ZipFS I believe), the file does not seem to be part of the GitHub repository and there are 5 usages

com/aoapps/lang/Throwables.class  and com/aoindustries/lang/Throwables.class (clone of each other I believe) 

com/android/tools/apk/analyzer/internal/ArchiveManagerImpl. ( 1 usage)


So would be good to also alert those projects if possible

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2307668978

From coleenp at openjdk.org  Fri Aug 23 19:29:06 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Aug 2024 19:29:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>

On Thu, 9 May 2024 13:51:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Yes, is_in_klass_space was just to direct where to deallocate the metaspace pointer.  In your patch isn't the contains metaspace call still very slow?  Or I suppose for class space, it's not because it's a fixed space.  But it's not an inlined call at all because I had to search in cpp files for the range check.
+  const bool is_class = Metaspace::contains_in_class_space(ptr);

I sort of think it might be better for the outside runtime code to control this and the metaspace call assert if its wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2307688050

From jlu at openjdk.org  Fri Aug 23 19:29:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Aug 2024 19:29:43 GMT
Subject: RFR: 8313205: Modernize java.text.Format with StringBuilder [v3]
In-Reply-To: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
References: <pcp8sniMJo1xfOi4YfMgyd3vXhE1-w6AKGU_FBbPLQI=.6160525d-5e8c-40bd-879d-1664ff470abb@github.com>
Message-ID: <nEZ9XkC1FzuZxH1v2RxUo3E34q1tOf3A20HjInMSvdU=.890c1342-29b4-43d4-9b7d-a181c4dddad1@github.com>

> Please review this PR which adds public StringBuilder overloads to the formatting methods of java.text.Format and implementing subclasses.
> 
> While Format, NumberFormat, and DateFormat are abstract, these new methods are not added as abstract to prevent compatibility concerns. Instead they are added as non-abstract methods, with a default implementation that throws UOE and a recommendation that subclasses override and provide their own implementations. These new methods use the same specification as the StringBuffer ones, with exception of `MessageFormat.format(format(Object[] arguments, StringBuilder result, FieldPosition pos)` which omits the table, and instead links to it.
> 
> The JDK implementing Format classes, (such as DecimalFormat) leverage the StringBuf proxy methods.
> 
> A corresponding CSR has been drafted: https://bugs.openjdk.org/browse/JDK-8337141, which goes into detail on motivation/history. (Holding off on uploading the specification to CSR until wording finalized).

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 four additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8313205-Format-publicStrBldr-overloads
 - throw UOE where possible in abstract class level
 - add since tags
 - init

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20337/files
  - new: https://git.openjdk.org/jdk/pull/20337/files/314b8d7b..0e4a70c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20337&range=01-02

  Stats: 40405 lines in 1259 files changed: 21540 ins; 13082 del; 5783 mod
  Patch: https://git.openjdk.org/jdk/pull/20337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20337/head:pull/20337

PR: https://git.openjdk.org/jdk/pull/20337

From duke at openjdk.org  Fri Aug 23 20:02:05 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 23 Aug 2024 20:02:05 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <zFXBpNpKYNxALspWNZ1hJpmqLwsxLY2Wdj0uPvLi9hY=.7aaf15d8-1881-40fe-8979-c64484bf95f2@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

There?s?also [HMCL?s?`org.jackhuang.hmcl.util.io.CompressingUtils`][1], which catches `ZipError` to?convert?it to?a?`ZipException` when?run on?**Java?8** ([this?was also?mentioned in?the?linked core?libs?dev discussion][2]).

[1]: https://github.com/HMCL-dev/HMCL/blob/95a1496389e6a8c2f51697706a20055a7952b8a5/HMCLCore/src/main/java/org/jackhuang/hmcl/util/io/CompressingUtils.java#L218-L220
[2]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125724.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2307731146

From jlu at openjdk.org  Fri Aug 23 20:03:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Aug 2024 20:03:37 GMT
Subject: RFR: 8338882: Clarify matching order of MessageFormat subformat
 factory styles
Message-ID: <6y7WfaWdoIJGDvbj9NxDqx0RbxxFrfaLY0_AIHqrETs=.6139748e-eae0-412b-80ad-21ae7886a0c9@github.com>

Please review this PR which clarifies that the matching order of format styles for MessageFormat sub formats is not guaranteed by the JDK implementation. A corresponding CSR has also been drafted.

This is relevant when a locale provides equivalent patterns for multiple format factory styles. For example, a locale X could provide some equivalent date style "xyz" for both a MEDIUM and LONG style. Thus invoking toPattern() could output `date`, `date,medium`, or `date,long` depending on the order of such matching.

-------------

Commit messages:
 - minor wording change
 - init

Changes: https://git.openjdk.org/jdk/pull/20695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20695&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338882
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20695/head:pull/20695

PR: https://git.openjdk.org/jdk/pull/20695

From lancea at openjdk.org  Fri Aug 23 20:15:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 23 Aug 2024 20:15:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <BF2dCk8yUjMoubQSf6ZeNQcq0pD7ZdNGKoniiG0sSrA=.0c8c2459-34fc-4452-a062-65e01441b2a1@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

> There?s?also [HMCL?s?`org.jackhuang.hmcl.util.io.CompressingUtils`](https://github.com/HMCL-dev/HMCL/blob/95a1496389e6a8c2f51697706a20055a7952b8a5/HMCLCore/src/main/java/org/jackhuang/hmcl/util/io/CompressingUtils.java#L218-L220), which catches `ZipError` to?convert?it to?a?`ZipException` when?run on?**Java?8** ([this?was also?mentioned in?the?linked core?libs?dev discussion](https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125724.html)).

Yes that is true.  The difference there is that is due to the demo version of Zip FS and as of JDK 9, when Zip FS was supported, it did not throw ZipError

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2307744487

From liach at openjdk.org  Fri Aug 23 20:15:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Aug 2024 20:15:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <6OyOFAfLM1lOi6csrRPKLapcW8m1KNTdAMHgzPUZGCw=.3fd0503c-0960-4dcc-9793-bed5a075fa70@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

A search on GitHub shows multiple Minecraft-related Java projects catch (but not create) ZipError for Java 8 backward compatibility. Maybe the actual deprecation can take steps; first with a functional removal to make ZipError constructors and methods throw errors, before finally removing it many releases later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2307747647

From coleenp at openjdk.org  Fri Aug 23 20:46:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Aug 2024 20:46:39 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v2]
In-Reply-To: <zwd_E0T36hapXYeqFQc0O9VsL4eyN8tPvMlv-Vo2xIw=.d833292a-6f8e-4a34-b0da-2fddfef5cbd8@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <zwd_E0T36hapXYeqFQc0O9VsL4eyN8tPvMlv-Vo2xIw=.d833292a-6f8e-4a34-b0da-2fddfef5cbd8@github.com>
Message-ID: <A22WxHYveDX2yo-C1B8_9IwL9fDLKbLoH-r8Q6_qb9A=.3a12360b-60e1-4879-8ac0-ff837287805b@github.com>

On Fri, 23 Aug 2024 20:43:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.

Thanks for reviewing this and your comments Thomas.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2258059047

From coleenp at openjdk.org  Fri Aug 23 20:46:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Aug 2024 20:46:39 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v2]
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <zwd_E0T36hapXYeqFQc0O9VsL4eyN8tPvMlv-Vo2xIw=.d833292a-6f8e-4a34-b0da-2fddfef5cbd8@github.com>

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19157/files
  - new: https://git.openjdk.org/jdk/pull/19157/files/da077055..c58278a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=00-01

  Stats: 37 lines in 16 files changed: 3 ins; 1 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/19157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19157/head:pull/19157

PR: https://git.openjdk.org/jdk/pull/19157

From coleenp at openjdk.org  Fri Aug 23 20:46:40 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Aug 2024 20:46:40 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v2]
In-Reply-To: <QJcnt-llBW0BOS1cbOkNQtq_cOfgKbZFGmhbpRDE2cM=.04376a07-e27d-4294-b47f-5d9395bdc49c@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <Xi9MiXjLHkqFeeUpKJNsZylEe6V77CHcVLxm0GdZ5Wk=.6f66052d-ce0d-442a-b29f-c2f20d90fcaa@github.com>
 <QJcnt-llBW0BOS1cbOkNQtq_cOfgKbZFGmhbpRDE2cM=.04376a07-e27d-4294-b47f-5d9395bdc49c@github.com>
Message-ID: <JwpZ8m1ke9LaEZXJ6baGX8VV3w3PyV7QjGu6I5eGp3w=.b2e9d213-9dcc-4a37-9dc8-1157ab8988c4@github.com>

On Fri, 23 Aug 2024 20:37:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/klass.hpp line 214:
>> 
>>> 212:   virtual bool is_klass() const { return true; }
>>> 213: 
>>> 214:   bool is_in_klass_space() const { return !is_interface() && !is_abstract(); }
>> 
>> This name is misleading. As a caller, I expect a function with this name to make a range check of Klass* to be inside class space range. This is more of a "should be".
>> 
>> (We also write class space with `c` throughout hotspot, its weird to have it with `k` now)
>> 
>> How about, instead: "needs_narrow_klass_id" or "must_be_narrow_encodable" or similar? That clearly says what you want, that this class needs to be encodable with a narrow id for whatever is your reason. This leaves room for future changes (e.g. a possible future where we need narrow klass ids for other reasons than to make heap objects smaller, or where there is no class space anymore).
>
> I renamed this is_in_class_space() with the lower case 'c'.  It's still directing metaspace or indicating where the object was allocated.  Your name is a little better but I think not enough until we want to expand the things we want allocated in the class space.  As we talked about, with Tiny Class Pointers, class space will have different things in it (not that these new things need a compressed pointers).  But I think we're better off having less things in the space where their pointers can be compressed since this space is constrained.

I have to think about this more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1729492034

From coleenp at openjdk.org  Fri Aug 23 20:46:40 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 23 Aug 2024 20:46:40 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v2]
In-Reply-To: <Xi9MiXjLHkqFeeUpKJNsZylEe6V77CHcVLxm0GdZ5Wk=.6f66052d-ce0d-442a-b29f-c2f20d90fcaa@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <Xi9MiXjLHkqFeeUpKJNsZylEe6V77CHcVLxm0GdZ5Wk=.6f66052d-ce0d-442a-b29f-c2f20d90fcaa@github.com>
Message-ID: <QJcnt-llBW0BOS1cbOkNQtq_cOfgKbZFGmhbpRDE2cM=.04376a07-e27d-4294-b47f-5d9395bdc49c@github.com>

On Fri, 23 Aug 2024 06:43:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.
>
> src/hotspot/share/memory/allocation.hpp line 319:
> 
>> 317:   f(SharedClassPathEntry) \
>> 318:   f(RecordComponent) \
>> 319:   f(AbstractClass)
> 
> This is a minor nit: I assume this new constant is just there to steer allocation down in metaspace away from Class space? This breaks a bit with established pattern, because the type `Klass::type()` returns is still "ClassType", so this new constant never really appears anywhere. Its only point is "its not classtype". You could probably hand down any other constant to Metaspace::allocate, as long as its not `ClassType`.
> 
> What we should eventually do, but in a follow up RFE:  modify `Metaspace::allocate` to replace the `MetaspaceObj::Type` parameter with a `MetadataType mdType` parameter. Or a plain "allocate_in_classspace_please" boolean parameter. Because Metaspace::allocate does not really need to know the type of the metadata object. It just needs to know if the caller insists on having the data in class space.
> 
>  But lets do this in a follow-up.

Yes, this is a bit inconsistent.  I like your suggestion for an improvement.  I was going to try to do this in this patch but the MetaspaceObj::Type is used for the report_metadata_oom event, so it's still needed in metaspace::allocate.  Which is unfortunate because I always get these two MetadataType and MetaspaceObj::Type things confused.

> src/hotspot/share/oops/instanceKlass.cpp line 456:
> 
>> 454: 
>> 455:   InstanceKlass* ik;
>> 456:   MetaspaceObj::Type type = (parser.is_interface() || parser.is_abstract()) ? MetaspaceObj::AbstractClassType : MetaspaceObj::ClassType;
> 
> small nit, const or constexpr?

I changed this line now (and used const for bool).

> src/hotspot/share/oops/klass.hpp line 214:
> 
>> 212:   virtual bool is_klass() const { return true; }
>> 213: 
>> 214:   bool is_in_klass_space() const { return !is_interface() && !is_abstract(); }
> 
> This name is misleading. As a caller, I expect a function with this name to make a range check of Klass* to be inside class space range. This is more of a "should be".
> 
> (We also write class space with `c` throughout hotspot, its weird to have it with `k` now)
> 
> How about, instead: "needs_narrow_klass_id" or "must_be_narrow_encodable" or similar? That clearly says what you want, that this class needs to be encodable with a narrow id for whatever is your reason. This leaves room for future changes (e.g. a possible future where we need narrow klass ids for other reasons than to make heap objects smaller, or where there is no class space anymore).

I renamed this is_in_class_space() with the lower case 'c'.  It's still directing metaspace or indicating where the object was allocated.  Your name is a little better but I think not enough until we want to expand the things we want allocated in the class space.  As we talked about, with Tiny Class Pointers, class space will have different things in it (not that these new things need a compressed pointers).  But I think we're better off having less things in the space where their pointers can be compressed since this space is constrained.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1729487783
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1729488157
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1729490999

From naoto at openjdk.org  Fri Aug 23 21:18:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Aug 2024 21:18:03 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <CWXAlb_sTDi8hGD5PtzxJWAKlEnPyD2NnzsoTX_9Nk4=.46b2f3be-d7b4-4df8-87ea-5c8ed5380a18@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
 <XrNegzZMsVcOOiZUzn1eSNTzfN6wN4P_Riznrm5aL5Q=.70b24d65-386d-4dd9-afd8-45b67af114c7@github.com>
 <CWXAlb_sTDi8hGD5PtzxJWAKlEnPyD2NnzsoTX_9Nk4=.46b2f3be-d7b4-4df8-87ea-5c8ed5380a18@github.com>
Message-ID: <UJW56W_L_Qx2jwcG_v3QjQwhjyfMj4Wc35r0PFmp_bk=.53295827-93dd-463e-85c5-09fa7ccf8d10@github.com>

On Fri, 23 Aug 2024 19:01:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 905:
>> 
>>> 903:                 divisor = divisors.get(++compactDataIndex);
>>> 904:             }
>>> 905:             var noFraction = number.mod(new BigInteger(divisor.toString()))
>> 
>> Why not create the BigInteger from the `divisor.longValue()`.
>> I see the pattern formatting to a string and BigInteger re-parsing it but why?
>
> I guess the range of the divisor may be bigger than a long.

That is my thinking too. Compact format is supposed to deal with big numbers, it can go beyond the range of a long.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20680#discussion_r1729523116

From psandoz at openjdk.org  Fri Aug 23 22:33:09 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 23 Aug 2024 22:33:09 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v5]
In-Reply-To: <7e5pWnvjqk-dQYNeaZjFzXcd5WlzniZPl5T4l1rKQGE=.0882bcd4-e307-4a29-aa41-5496ee029a60@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7e5pWnvjqk-dQYNeaZjFzXcd5WlzniZPl5T4l1rKQGE=.0882bcd4-e307-4a29-aa41-5496ee029a60@github.com>
Message-ID: <2_P1qPMS46tgh4RUSuitcjXYnd0koS_BxfRRRmj79EY=.c3baeeaa-87f7-47d4-bc70-ae2afd9de745@github.com>

On Fri, 23 Aug 2024 06:09:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing redundant checkIndex routine

API changes look good. (Note at the moment we are not proposing to change how shuffles works - as you point out the two vector `selectFrom` and `rearrange` differ in the index representation.)

IIUC if the more direct two-table instruction is not available you fall back to calling two single arg rearranges with a blend, as a lowering transformation, similar to the fallback Java expression.

The float/double conversion bothers me, not suggesting we do something about it here, noting down for any future conversation on shuffles. Ideally we would want the equivalent integral vector (int or long) to represent the index, tricky to express in the API, or alternative treat as a bitwise no-op conversion (there is also impact on `toShuffle` too).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2307886044

From sviswanathan at openjdk.org  Fri Aug 23 23:33:14 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 23 Aug 2024 23:33:14 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <aOClzuY1eNomB-ouL3TnQZUtxibpuIaiW-02bJiplo0=.335d6812-8f45-49f0-b3a5-5a829f5dcaff@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/java.base/share/classes/java/lang/Byte.java line 647:

> 645:      */
> 646:     public static byte subSaturating(byte a, byte b) {
> 647:         byte res = (byte)(a - b);

Could we not do subSaturating as an int operation on similar lines as addSaturating?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1729570756

From duke at openjdk.org  Sat Aug 24 03:08:13 2024
From: duke at openjdk.org (xxDark)
Date: Sat, 24 Aug 2024 03:08:13 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
Message-ID: <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>

On Wed, 17 Jul 2024 08:59:07 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
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I've been trying to work with classfile api, and:
- `AttributesProcessingOption` is unused, does nothing?
- Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as `JAVA_1_VERSION` exist in `java.lang.classfile.ClassFile`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308012254

From liach at openjdk.org  Sat Aug 24 03:49:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 03:49:07 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>
Message-ID: <4HPAEtrghKTT911EngoStpgrFLU8R83bsqR9rs_1Xng=.686fdb94-0fe5-4708-be39-9f79af07eb58@github.com>

On Sat, 24 Aug 2024 03:05:14 GMT, xxDark <duke at openjdk.org> wrote:

> Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as `JAVA_1_VERSION` exist in `java.lang.classfile.ClassFile`.

Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, for release N, we will not support correct parsing or writing of preview class files from N-1, N-2, etc.

While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):
https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/hotspot/share/classfile/classFileParser.cpp#L2332-L2334
Nor by the JVMS: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.7.3

And as such, it falls out of the [goals](https://openjdk.org/jeps/466#Goals) of the API, and is likely not going to be added. You most likely will resort to a third party library to handle such frozen format, as the main issue ClassFile API is solving is that a library built against JDK 21 may not run on JDK 23 unless it bumps its ASM dependency to support reading JDK 23 Class File format, which doesn't exist for the said oak format.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308036118

From duke at openjdk.org  Sat Aug 24 04:07:02 2024
From: duke at openjdk.org (xxDark)
Date: Sat, 24 Aug 2024 04:07:02 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <4HPAEtrghKTT911EngoStpgrFLU8R83bsqR9rs_1Xng=.686fdb94-0fe5-4708-be39-9f79af07eb58@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <j1FfFQi2BH1Lw4YgwgT-H7le3bvo_AeEsqPhg3vC4aE=.b4dd569a-a4e2-4e62-a2ea-65e06bf05a62@github.com>
 <4HPAEtrghKTT911EngoStpgrFLU8R83bsqR9rs_1Xng=.686fdb94-0fe5-4708-be39-9f79af07eb58@github.com>
Message-ID: <8mR8hNkY-JGoTiHFXQ3o9JO53s4lPc9_c0vEW_5IXgo=.bac37181-9774-4a50-b3ab-1f1e4f7e8d13@github.com>

On Sat, 24 Aug 2024 03:45:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):
> 
> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/hotspot/share/classfile/classFileParser.cpp#L2332-L2334

Interesting. I guess handling of oak classfiles was removed a long time ago by [this](https://github.com/openjdk/jdk17u-dev/commit/eedc99c9ab2647f0233e4899a2976eb6f3095319) commit.
But, does this mean that now, Hotspot blindly accepts classfiles with version 45 with, technically, incorrect data?

java -cp . Test
Hello, World

jdk-1.8.0_402\bin\java -cp . Test
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.ClassFormatError: Invalid code attribute name index 10 in class file Test
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308042111

From jwaters at openjdk.org  Sat Aug 24 04:38:03 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Aug 2024 04:38:03 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v3]
In-Reply-To: <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <TzQ3jw4UgX7cht4GMkoHEGrH0Hld6WBERcowz_DWjTk=.b855a109-c239-4055-827d-158ec455996e@github.com>
Message-ID: <HZ8PDvSYig0hFlp5lVjbHh2Bg4qanamzSLa1qu4OjsY=.816cf994-7216-48e9-9466-5dd48c1e7db3@github.com>

On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Standard Integer type rewrite

I was going to ask for a security review, but I decided to only do that after I change the copyright years in the files that need it. Well, when I have the time that is...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2308076996

From liach at openjdk.org  Sat Aug 24 04:59:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 04:59:07 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
Message-ID: <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>

On Wed, 17 Jul 2024 08:59:07 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
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

I think so. See https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039795.html for some context. There are also historical evaluations available at https://bugs.openjdk.org/browse/JDK-8232890 and https://bugs.openjdk.org/browse/JDK-8232967, notably the judgement in Compatibility Risk Description:

> Class files with versions < 45.3 predate Java.

> But, does this mean that now, Hotspot blindly accepts classfiles with version 45 with, technically, incorrect data?

It appears so. See note in `ClassFileFormatVersion`: https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java#L413-L414
It seems that now major version 45, regardless of the minor version, is simply seen as the Class File format for Java 1.1.

> Also now, [this](https://github.com/Col-E/CAFED00D) library which took special care to parse oak files reports wrong instructions does not parse classfile at all.

Indeed, it would be a good RFE to allow users to override default attribute mappers to parse attributes; this would be extremely useful if users wish to support previous previews that only differed in the attribute formats.

> `jdk-1.8.0_402\bin\java -cp . Test`
> `Hello World`

For the behavioral inconsistencies, we can backport this special handling removal to active jdk update projects or even request specification changes on LTS versions (see https://github.com/openjdk/jdk8u-ri) if this is deemed important enough.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308099862

From jwaters at openjdk.org  Sat Aug 24 05:06:18 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Aug 2024 05:06:18 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v4]
In-Reply-To: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
Message-ID: <HcrEC2ZV5wAP92CAX_KvRmSpbnpFL4vDdzcVGP6tXWY=.e25f365b-9e66-40d9-ae9e-1bea3b5f5981@github.com>

> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul
 l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
> 
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Change copyright years and formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20153/files
  - new: https://git.openjdk.org/jdk/pull/20153/files/a0477b8b..e14ef6b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=02-03

  Stats: 46 lines in 10 files changed: 0 ins; 0 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/20153.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153

PR: https://git.openjdk.org/jdk/pull/20153

From duke at openjdk.org  Sat Aug 24 05:07:03 2024
From: duke at openjdk.org (xxDark)
Date: Sat, 24 Aug 2024 05:07:03 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
Message-ID: <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>

On Sat, 24 Aug 2024 04:56:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> 
> Indeed, it would be a good RFE to allow users to override default attribute mappers to parse attributes; this would be extremely useful if users wish to support previous previews that only differed in the attribute formats.
> 
I don't think at this point in time there would be any change in the format of any existing attributes, as that would be a binary incompatible change.
But yes, having a way to override parsing of builtin attributes would be nice.

> For the behavioral inconsistencies, we can backport this special handling removal to active jdk update projects or even request specification changes on LTS versions (see https://github.com/openjdk/jdk8u-ri) if this is deemed important enough.

I don't think that many projects use pre-Java 1 format at this point. While I saw some libraries that kept their version set to versions like Java 4 for no apparent reason... Hey, at least it's not Java 1 version.
If Hotspot now parses these files incorrectly, it might be worth to just throw `UnsupportedClassVersionError` for oak class files?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308102351

From jwaters at openjdk.org  Sat Aug 24 05:12:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Aug 2024 05:12:42 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
Message-ID: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>

> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul
 l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
> 
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)

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 five additional commits since the last revision:

 - Merge branch 'master' into snprintf
 - Change copyright years and formatting
 - Revert Standard Integer type rewrite
 - USe os::snprintf in HotSpot
 - Obliterate most references to _snprintf in the Windows JDK

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20153/files
  - new: https://git.openjdk.org/jdk/pull/20153/files/e14ef6b6..d8f7b849

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20153&range=03-04

  Stats: 56099 lines in 1629 files changed: 32020 ins; 16189 del; 7890 mod
  Patch: https://git.openjdk.org/jdk/pull/20153.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20153/head:pull/20153

PR: https://git.openjdk.org/jdk/pull/20153

From jwaters at openjdk.org  Sat Aug 24 05:12:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Aug 2024 05:12:42 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v4]
In-Reply-To: <HcrEC2ZV5wAP92CAX_KvRmSpbnpFL4vDdzcVGP6tXWY=.e25f365b-9e66-40d9-ae9e-1bea3b5f5981@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <HcrEC2ZV5wAP92CAX_KvRmSpbnpFL4vDdzcVGP6tXWY=.e25f365b-9e66-40d9-ae9e-1bea3b5f5981@github.com>
Message-ID: <3ewsuSYlM6tvlOjvAlBCPcam2tLiPTx_fv9le9GKpJY=.1030005f-dcbc-4b65-a7f1-c35382f60cc0@github.com>

On Sat, 24 Aug 2024 05:06:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change copyright years and formatting

Alright, never mind, I've gone ahead with the copyright anyway, and in the process also fought my OCD and given the snprintf calls proper formatting too. Now awaiting re-review from all, as well as the missing review from security

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2308107303

From jpai at openjdk.org  Sat Aug 24 05:24:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 24 Aug 2024 05:24:10 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <Bj9yUDMOcuGEKdhDswixeePjiGjUVaWU9w9il_pjXXA=.74cf3f8e-258f-486a-a008-629eb33d0b5a@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2258410435

From duke at openjdk.org  Sat Aug 24 06:27:26 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 24 Aug 2024 06:27:26 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v17]
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <uLIeI8246MZSqmJ4_IR3Zq5PDV0DAo-DiELcHHmeUg0=.8ffc43d7-4de4-40b9-8bc9-f80891d5732e@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 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 optim_str_builder_append_202406
 - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
 - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
 - replace unsafe with putChar
 - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
 - private static final field `UNSAFE`
 - Utf16 case remove `append first utf16 char`
 - `delete` -> `setLength`
 - copyright 2024
 - optimization for x64
 - ... and 9 more: https://git.openjdk.org/jdk/compare/d881a7b4...61196ecd

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19626/files
  - new: https://git.openjdk.org/jdk/pull/19626/files/d2dcc24d..61196ecd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19626&range=15-16

  Stats: 46886 lines in 1334 files changed: 26149 ins; 14297 del; 6440 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  Sat Aug 24 06:46:08 2024
From: duke at openjdk.org (Matt)
Date: Sat, 24 Aug 2024 06:46:08 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
Message-ID: <R4codYRoyxsreqAWoonXwPQWZMCg-PSngjNrH3gdW9g=.185e4e51-fc1c-45b5-8ac0-7a30d6a410f8@github.com>

On Wed, 17 Jul 2024 08:59:07 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
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8334714-final
>  - bumped @since tag
>  - 8334714: Class-File API leaves preview

> Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, **for release N, we will not support correct _parsing_ or writing of preview class files from N-1, N-2, etc.**

I understand that there is no explicit goal for this API to be used for general purposes, but it seems really odd that I cannot safely assume that classes that are successfully loaded in the current runtime will be parsable. Oak classes are a notable exception, and nobody should realistically expect to see an oak class ever. However, if we only can guarantee that the current class file version will be supported and not even N-1 then no application/library expecting reliability _(without constant recompilation to ensure the class versions are current)_ should use the API.

Again, its not a goal per-say but it seems really disappointing and odd.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308154137

From eirbjo at openjdk.org  Sat Aug 24 10:19:02 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 24 Aug 2024 10:19:02 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <LIZcPDCBAWIe20r1sCN61ZAncxGj43bc81Ssum-e5BU=.46de8e9d-6221-4316-b9d0-8b3a309732e3@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <LIZcPDCBAWIe20r1sCN61ZAncxGj43bc81Ssum-e5BU=.46de8e9d-6221-4316-b9d0-8b3a309732e3@github.com>
Message-ID: <DTtR7YI8ECsagyP7DikRe4vmZl2RGMZnEo5Ssr1Cj6o=.f3a6dba0-17b1-4463-acc3-5026ed6722e1@github.com>

On Fri, 23 Aug 2024 19:13:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> So would be good to also alert those projects if possible

I guess the deprecation warning itself is the "official" channel for communicating this type of information. But I agree it doesn't hurt to alert at least some of the larger projects, on a best-effort bases. So I have reached out to the following projects by reporting issues:

* Eclipse JDT: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2856
* SBT / Zinc: https://github.com/sbt/zinc/issues/1385    
* Android Studio apkparser: https://issuetracker.google.com/issues/361862739

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2308313284

From stuefe at openjdk.org  Sat Aug 24 10:56:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 24 Aug 2024 10:56:05 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
Message-ID: <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>

On Fri, 23 Aug 2024 19:26:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Yes, is_in_klass_space was just to direct where to deallocate the metaspace pointer. In your patch isn't the contains metaspace call still very slow? Or I suppose for class space, it's not because it's a fixed space. But it's not an inlined call at all because I had to search in cpp files for the range check.
> 
> * const bool is_class = Metaspace::contains_in_class_space(ptr);
> 
> I sort of think it might be better for the outside runtime code to control this and the metaspace call assert if its wrong.

No, I think my way is better and it will be needed anyway for TinyCP/Lilliput. We only need to do two address comparisons, that should be simple and fast. 

I opened a PR to separate the change, and in that PR I also inline the check. 

https://github.com/openjdk/jdk/pull/20701

I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2308352940

From stuefe at openjdk.org  Sat Aug 24 10:56:06 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 24 Aug 2024 10:56:06 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v2]
In-Reply-To: <zwd_E0T36hapXYeqFQc0O9VsL4eyN8tPvMlv-Vo2xIw=.d833292a-6f8e-4a34-b0da-2fddfef5cbd8@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <zwd_E0T36hapXYeqFQc0O9VsL4eyN8tPvMlv-Vo2xIw=.d833292a-6f8e-4a34-b0da-2fddfef5cbd8@github.com>
Message-ID: <DQrR5Uv6w_ynY6UYx607SSu-11C2F8vEfDtDBPsru7c=.33341073-02d8-4146-ba82-686eea3a66bb@github.com>

On Fri, 23 Aug 2024 20:46:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.

> I renamed this is_in_class_space() with the lower case 'c'. It's still directing metaspace or indicating where the object was allocated. Your name is a little better but I think not enough until we want to expand the things we want allocated in the class space. As we talked about, with Tiny Class Pointers, class space will have different things in it (not that these new things need a compressed pointers). But I think we're better off having less things in the space where their pointers can be compressed since this space is constrained.


How about "needs_class_space" then?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2308353198

From duke at openjdk.org  Sat Aug 24 12:35:03 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 24 Aug 2024 12:35:03 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them
In-Reply-To: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
Message-ID: <DQ5B9AazRDcPZjEoa918riCD0wJHvz83TNhix8GXQjA=.70598fcd-4e6a-4469-a396-916a06424a66@github.com>

On Fri, 23 Aug 2024 12:34:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
> 
> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 85:

> 83:     private static final boolean previewEnabled = PreviewFeatures.isEnabled();
> 84: 
> 85:     private static final ClassDesc CD_BiPredicate = referenceClassDesc(BiPredicate.class);

This?can?use `ReferenceClassDescImpl?::ofValidated?(String)`, which?also?avoids going?through `Class?::descriptorString()` for?a?statically known class?descriptor:
Suggestion:

    private static final ClassDesc CD_BiPredicate = ReferenceClassDescImpl.ofValidated("Ljava/util/function/BiPredicate;");

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 97:

> 95:             ConstantDescs.CD_int,
> 96:             CD_BiPredicate,
> 97:             ConstantDescs.CD_List);

These?can?use `MethodTypeDescImpl?::ofValidated(?)`:
Suggestion:

    private static final MethodTypeDesc MTD_TYPE_SWITCH = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_int,
            ConstantDescs.CD_Object,
            ConstantDescs.CD_int);
    private static final MethodTypeDesc MTD_TYPE_SWITCH_EXTRA = MethodTypeDescImpl.ofValidated(ConstantDescs.CD_int,
            ConstantDescs.CD_Object,
            ConstantDescs.CD_int,
            CD_BiPredicate,
            ConstantDescs.CD_List);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20693#discussion_r1729952813
PR Review Comment: https://git.openjdk.org/jdk/pull/20693#discussion_r1729952571

From eirbjo at openjdk.org  Sat Aug 24 12:51:32 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 24 Aug 2024 12:51:32 GMT
Subject: RFR: 8338931: ZipEntry.flags could be made internal to ZipOutputStream
Message-ID: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>

Please review this refactoring PR which moves the `ZipEntry.flags` field to `ZipOutputStream.XEntry`.

Moving this field will save four bytes from the `ZipEntry` object size and also saves an unneccessary read in `ZipFile.getZipEntry`.

Testing:

This PR is a refactoring of existing code and does not update any tests. I added the label `noreg-cleanup` to the JBS issue.

The following runs clean:


make test TEST="test/jdk/java/util/zip"
make test TEST="test/jdk/java/util/jar"


Performance:

The JMH benchmark `java.util.zip.ZipFileGetEntry.getEntryHit` show a small but consistent improvement (2-3%).

-------------

Commit messages:
 - Rename XEntry.flag to XEntry.flags
 - Move ZipEntry.flags to ZipOutputStream.XEntry

Changes: https://git.openjdk.org/jdk/pull/20702/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20702&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338931
  Stats: 13 lines in 3 files changed: 2 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20702/head:pull/20702

PR: https://git.openjdk.org/jdk/pull/20702

From liach at openjdk.org  Sat Aug 24 13:56:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 13:56:04 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
 <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>
Message-ID: <v6SYBNZ5TY8V6VXo4jaz5z5YWndy-8T7arwHOYTA23c=.af3a2596-62cb-4f76-a1c0-cc975e943351@github.com>

On Sat, 24 Aug 2024 05:03:33 GMT, xxDark <duke at openjdk.org> wrote:

> If Hotspot now parses these files incorrectly, it might be worth to just throw `UnsupportedClassVersionError` for oak class files?

This would be an important decision; I would wait till Monday when more engineers are back to discuss about the histroy of dropping support for such files, why this format never made its way to the JVMS, and the correct way to handle so as to avoid inconsistency between different versions.

> Edit: I missed the word `preview` in the quote. Does this only apply to *preview* class file features?

Yes, Class-File API is supposed to handle whatever the VM handles. It's actually considered a "JVM API" in Oracle's documentations: https://docs.oracle.com/en/java/javase/22/vm/class-file-api.html

OpenJDK's preview version policy allows shipping the preview features for testing to a wider audience without any implied burden of long-term maintenance. So for example, if the Nullable Types JEP preview adds `~` as a null marker in `Signature` attribute but changes it to `?` in a subsequent preview, the JVM and core libraries will act as if a previous iteration with `~` marker never existed; the policy is similar to that for preview libraries.

Unfortunately, there seems to be some misunderstanding around the role of preview, so some are asking if preview features that is largely unchanged and finalized in a future release can become finalized in an LTS as well. Short answer, no: it's an experiment format enabled by the new 6-month release schedule.

And note that javap uses ClassFile API, and as a result, javap for release N cannot correctly decompile Class Files with version N-1.65535, etc. We are planning to decompile on a best-effort basis, that we try to interpret such as class as if it's N.65535 (maybe emit a warning), trying to salvage the most out of the Class File and printing errors (but continue to output) if we encounter anything we don't expect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308402818

From liach at openjdk.org  Sat Aug 24 15:39:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 15:39:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <RYp11eHba8vSt0SvtFxL07LK1OdUVLz6_34tsVawvII=.959d97ab-783e-4060-8410-a96a8a804830@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

src/java.base/share/classes/java/util/zip/ZipError.java line 29:

> 27: 
> 28: /**
> 29:  * Signals that an unrecoverable error has occurred.

I recommend updating this description to indicate it was a bridge for users that handled InternalErrors thrown for input zip format errors.

src/java.base/share/classes/java/util/zip/ZipError.java line 30:

> 28: /**
> 29:  * Signals that an unrecoverable error has occurred.
> 30:  * @deprecated Use {@link ZipException} instead.

We should probably talk about how this is no longer created by the reference implementation since JDK 9 (and JDK 8's zipfs is really a demo). Should we note that we might functionally disable the constructor first?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1729996156
PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1729997361

From liach at openjdk.org  Sat Aug 24 16:23:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 16:23:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <DTtR7YI8ECsagyP7DikRe4vmZl2RGMZnEo5Ssr1Cj6o=.f3a6dba0-17b1-4463-acc3-5026ed6722e1@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <LIZcPDCBAWIe20r1sCN61ZAncxGj43bc81Ssum-e5BU=.46de8e9d-6221-4316-b9d0-8b3a309732e3@github.com>
 <DTtR7YI8ECsagyP7DikRe4vmZl2RGMZnEo5Ssr1Cj6o=.f3a6dba0-17b1-4463-acc3-5026ed6722e1@github.com>
Message-ID: <5dQZSSLpla3hBaC0jrbQXgktYy4faTJD9niUyi-TQHQ=.493f164f-b897-420c-ac13-27d181ada1b5@github.com>

On Sat, 24 Aug 2024 10:16:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> On a corpus search, found
>> org.eclipse.jdt.core/search/org/eclipse/jdt/internal/core/search/indexing/AddJarFileToIndex.java references ZipError (16 usages)
>> 
>> sbt/internal/inc/zip/ZipCentralDir.java referenced ZipError(was based off an old copy of ZipFS I believe), the file does not seem to be part of the GitHub repository and there are 5 usages
>> 
>> com/aoapps/lang/Throwables.class  and com/aoindustries/lang/Throwables.class (clone of each other I believe) 
>> 
>> com/android/tools/apk/analyzer/internal/ArchiveManagerImpl. ( 1 usage)
>> 
>> 
>> So would be good to also alert those projects if possible
>
>> So would be good to also alert those projects if possible
> 
> I guess the deprecation warning itself is the "official" channel for communicating this type of information. But I agree it doesn't hurt to alert at least some of the larger projects, on a best-effort bases. So I have reached out to the following projects by reporting issues:
> 
> * Eclipse JDT: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2856
> * SBT / Zinc: https://github.com/sbt/zinc/issues/1385    
> * Android Studio apkparser: https://issuetracker.google.com/issues/361862739

@eirbjo I have updated the CSR to describe the solutions from both our and user sides.

I think you can update the class Javadoc to something like:


/**
 * A legacy error for invalid ZIP format from argument incorrectly regarded as an internal error.
 * This extends {@code InternalError} to maintain compatibility with preexisting client code catching
 * {@code InternalError}.
 * 
 * @deprecated
 * This error is not suitable to indicate an exception for a general ZIP file; use {@link
 * ZipException} instead.
 * <p>
 * {@code ZipError} fell out of use in the reference implementation in release 9 when the native ZIP
 * API was brought over to Java. Its last uses was in ZipFile and the demo zipfs in release 8.
 * <p>
 * Code bases supporting release 8 should update to catch InternalError instead. Old binaries can
 * use bytecode patching to upgrade CONSTANT_Class references to {@code java/util/zip/ZipError} in
 * exception handler ranges to {@code java/lang/InternalError}.
 */

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2308445973

From lancea at openjdk.org  Sat Aug 24 16:52:02 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 24 Aug 2024 16:52:02 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <DTtR7YI8ECsagyP7DikRe4vmZl2RGMZnEo5Ssr1Cj6o=.f3a6dba0-17b1-4463-acc3-5026ed6722e1@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <LIZcPDCBAWIe20r1sCN61ZAncxGj43bc81Ssum-e5BU=.46de8e9d-6221-4316-b9d0-8b3a309732e3@github.com>
 <DTtR7YI8ECsagyP7DikRe4vmZl2RGMZnEo5Ssr1Cj6o=.f3a6dba0-17b1-4463-acc3-5026ed6722e1@github.com>
Message-ID: <JOJHuBX2oafDDXjgBYlfwiznDKiPP0ggrhtkP3TI9BM=.68a3812c-dc4d-4bde-8dab-af7602737647@github.com>

On Sat, 24 Aug 2024 10:16:55 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> On a corpus search, found
>> org.eclipse.jdt.core/search/org/eclipse/jdt/internal/core/search/indexing/AddJarFileToIndex.java references ZipError (16 usages)
>> 
>> sbt/internal/inc/zip/ZipCentralDir.java referenced ZipError(was based off an old copy of ZipFS I believe), the file does not seem to be part of the GitHub repository and there are 5 usages
>> 
>> com/aoapps/lang/Throwables.class  and com/aoindustries/lang/Throwables.class (clone of each other I believe) 
>> 
>> com/android/tools/apk/analyzer/internal/ArchiveManagerImpl. ( 1 usage)
>> 
>> 
>> So would be good to also alert those projects if possible
>
>> So would be good to also alert those projects if possible
> 
> I guess the deprecation warning itself is the "official" channel for communicating this type of information. But I agree it doesn't hurt to alert at least some of the larger projects, on a best-effort bases. So I have reached out to the following projects by reporting issues:
> 
> * Eclipse JDT: https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2856
> * SBT / Zinc: https://github.com/sbt/zinc/issues/1385    
> * Android Studio apkparser: https://issuetracker.google.com/issues/361862739

> @eirbjo I have updated the CSR to describe the solutions from both our and user sides.
> 
> I think you can update the class Javadoc to something like:
> 
> ```java
> /**
>  * A legacy error for invalid ZIP format from argument incorrectly regarded as an internal error.
>  * This extends {@code InternalError} to maintain compatibility with preexisting client code catching
>  * {@code InternalError}.
>  * 
>  * @deprecated
>  * This error is not suitable to indicate an exception for a general ZIP file; use {@link
>  * ZipException} instead.
>  * <p>
>  * {@code ZipError} fell out of use in the reference implementation in release 9 when the native ZIP
>  * API was brought over to Java. Its last uses was in ZipFile and the demo zipfs in release 8.
>  * <p>
>  * Code bases supporting release 8 should update to catch InternalError instead. Old binaries can
>  * use bytecode patching to upgrade CONSTANT_Class references to {@code java/util/zip/ZipError} in
>  * exception handler ranges to {@code java/lang/InternalError}.
>  */
> ```
> 
> I don't know if we should include such an excerpt:
> 
> ```java
> /**
>  * <p>
>  * In a future release, implementation of {@code ZipError} will be removed before this class itself
>  * is removed; at that point, {@code ZipError} can no longer be constructed or used, but can still
>  * be compiled against as an aid in migration.
>  */
> ```
> 
> I left the questions in CSR comment section; hope Joe Darcy can give us some advice here.

While I agree an `@deprecated` note should be added, I do not feel it needs to be that verbose.  I would simply borrow from what was done for `SecurityManager`.  The CSR can provide some more background


I also do not see a need to anything WRT the constructors as that is overkill IMHO.   

A release note will also go with this change which can  suggest that code that also must support JDK 8 leverage InternalError

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2308453719

From liach at openjdk.org  Sat Aug 24 17:25:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Aug 2024 17:25:02 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <04mDTpAYPyJc_PVg2TQq1Fmvf1p7PgfVJkHDcGETuhA=.723673dc-390e-4c1b-aebb-e9867fd9d665@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`: https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2308462889

From redestad at openjdk.org  Sat Aug 24 21:16:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sat, 24 Aug 2024 21:16:34 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them [v2]
In-Reply-To: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
Message-ID: <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>

> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
> 
> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.

Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20693/files
  - new: https://git.openjdk.org/jdk/pull/20693/files/3c793661..fcdc4c68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20693&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20693&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20693/head:pull/20693

PR: https://git.openjdk.org/jdk/pull/20693

From liach at openjdk.org  Sun Aug 25 02:11:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Aug 2024 02:11:15 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them [v2]
In-Reply-To: <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
 <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
Message-ID: <3qM_SkQMOTg_QQKqeKIroBZStsWM__vRhC9dzRLT0xM=.d1cad66f-9ed5-4c81-a409-64f623d9e8d3@github.com>

On Sat, 24 Aug 2024 21:16:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
>> 
>> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20693#pullrequestreview-2259071643

From duke at openjdk.org  Sun Aug 25 04:33:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 04:33:38 GMT
Subject: RFR: 8338930: StringConcatFactory static string concatenation strategy
Message-ID: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>

This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.

When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

-------------

Commit messages:
 - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
 - revert code style
 - from suggest
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - support staticConcat

Changes: https://git.openjdk.org/jdk/pull/20675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338930
  Stats: 159 lines in 3 files changed: 90 ins; 11 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From duke at openjdk.org  Sun Aug 25 04:33:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 04:33:38 GMT
Subject: RFR: 8338930: StringConcatFactory static string concatenation
 strategy
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <CehhixRRNhiLq-vI5bkru89-oF_nZgYiF8cCu-bvIks=.9d8bb8ff-87dd-4c11-83aa-af8fe7b11056@github.com>

On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Below are the performance numbers on a MacBook M1 Pro. When the number of parameters is greater than 16, the performance is significantly improved.

## Script

# baseline
git checkout 6644dd33f6f4b440105d84ef187a0ff6b1d60827
make test TEST="micro:java.lang.StringConcat."

# current
git checkout a2465a0e6011c4433833c5088ebcb5d56c6a5587
make test TEST="micro:java.lang.StringConcat."


## Performance Numbers

-# baseline
-Benchmark                                            (intValue)  Mode  Cnt     Score    Error  Units
-StringConcat.concat123String                               4711  avgt   15  1021.422 ?  5.979  ns/op
-StringConcat.concat23String                                4711  avgt   15    80.279 ?  0.338  ns/op
-StringConcat.concat23StringConst                           4711  avgt   15   103.502 ?  0.477  ns/op
-StringConcat.concat30Mix                                   4711  avgt   15   339.447 ? 14.675  ns/op

+# current
+Benchmark                                            (intValue)  Mode  Cnt     Score    Error  Units
+StringConcat.concat123String                               4711  avgt   15  1021.422 ?  5.979  ns/op
+StringConcat.concat23String                                4711  avgt   15    80.279 ?  0.338  ns/op
+StringConcat.concat23StringConst                           4711  avgt   15   103.502 ?  0.477  ns/op
+StringConcat.concat30Mix                                   4711  avgt   15   339.447 ? 14.675  ns/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 1078.649 | 1021.422 | 5.60% |
| StringConcat.concat23String | 139.407 | 80.279 | 73.65% |
| StringConcat.concat23StringConst | 119.125 | 103.502 | 15.09% |
| StringConcat.concat30Mix | 425.278 | 339.447 | 25.29% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308154069

From duke at openjdk.org  Sun Aug 25 04:33:39 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 25 Aug 2024 04:33:39 GMT
Subject: RFR: 8338930: StringConcatFactory static string concatenation
 strategy
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <WuqUnZ-Nfz7lU8ynMbaIi38mmIy3LPKOl4v-Pv5ICAw=.e40d382d-157a-4915-b382-f279636637e3@github.com>

On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1476:

> 1474:                      * coder = coder(this.coder, arg0, arg1, ... argN);
> 1475:                      */
> 1476:                     if (staticConcat) {

It?might be?better for?this?loop to?only be?ran when?`staticConcat` is?`true`:
Suggestion:


                    /*
                     * coder = coder(this.coder, arg0, arg1, ... argN);
                     */
                    if (staticConcat) {
                        for (var constant : constants) {
                            coder  |= JLA.stringCoder(constant);
                            length += constant.length();
                        }

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1711:

> 1709:                      */
> 1710:                     cb.iload(lengthSlot);
> 1711:                     for (int i = prependArgs.parameterCount() - 1; i >= (staticConcat ? 3 : 4); i--) {

The?result of?`staticConcat ??3 :?4` should?probably be?stored in?a?local outside?the?loop:
Suggestion:

                    for (int i = prependArgs.parameterCount() - 1, end = staticConcat ? 3 : 4; i >= end; i--) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1728578074
PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1728586732

From markus at headcrashing.eu  Sun Aug 25 05:31:22 2024
From: markus at headcrashing.eu (Markus Karg)
Date: Sun, 25 Aug 2024 07:31:22 +0200
Subject: AW: RFR: 8338930: StringConcatFactory static string concatenation
 strategy
In-Reply-To: <CehhixRRNhiLq-vI5bkru89-oF_nZgYiF8cCu-bvIks=.9d8bb8ff-87dd-4c11-83aa-af8fe7b11056@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <CehhixRRNhiLq-vI5bkru89-oF_nZgYiF8cCu-bvIks=.9d8bb8ff-87dd-4c11-83aa-af8fe7b11056@github.com>
Message-ID: <000001daf6b0$05723a20$1056ae60$@eu>

Could it be the case that you posted twice the exact same performance numbers? I do not see any actual difference in your numbers.
-Markus


-----Urspr?ngliche Nachricht-----
Von: core-libs-dev [mailto:core-libs-dev-retn at openjdk.org] Im Auftrag von Shaojin Wen
Gesendet: Sonntag, 25. August 2024 06:34
An: core-libs-dev at openjdk.org
Betreff: Re: RFR: 8338930: StringConcatFactory static string concatenation strategy

On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Below are the performance numbers on a MacBook M1 Pro. When the number of parameters is greater than 16, the performance is significantly improved.

## Script

# baseline
git checkout 6644dd33f6f4b440105d84ef187a0ff6b1d60827
make test TEST="micro:java.lang.StringConcat."

# current
git checkout a2465a0e6011c4433833c5088ebcb5d56c6a5587
make test TEST="micro:java.lang.StringConcat."


## Performance Numbers

-# baseline
-Benchmark                                            (intValue)  Mode  Cnt     Score    Error  Units
-StringConcat.concat123String                               4711  avgt   15  1021.422 ?  5.979  ns/op
-StringConcat.concat23String                                4711  avgt   15    80.279 ?  0.338  ns/op
-StringConcat.concat23StringConst                           4711  avgt   15   103.502 ?  0.477  ns/op
-StringConcat.concat30Mix                                   4711  avgt   15   339.447 ? 14.675  ns/op

+# current
+Benchmark                                            (intValue)  Mode  Cnt     Score    Error  Units
+StringConcat.concat123String                               4711  avgt   15  1021.422 ?  5.979  ns/op
+StringConcat.concat23String                                4711  avgt   15    80.279 ?  0.338  ns/op
+StringConcat.concat23StringConst                           4711  avgt   15   103.502 ?  0.477  ns/op
+StringConcat.concat30Mix                                   4711  avgt   15   339.447 ? 14.675  ns/op


|   | baseline  | current | delta |
| --- | --- | --- | --- |
| StringConcat.concat123String | 1078.649 | 1021.422 | 5.60% |
| StringConcat.concat23String | 139.407 | 80.279 | 73.65% |
| StringConcat.concat23StringConst | 119.125 | 103.502 | 15.09% |
| StringConcat.concat30Mix | 425.278 | 339.447 | 25.29% |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308154069


From duke at openjdk.org  Sun Aug 25 07:52:07 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 07:52:07 GMT
Subject: RFR: 8338930: StringConcatFactory static string concatenation
 strategy
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <IcDopQCRbktco8XPzgbD1DOXwTK8auKBgXloivR3DqM=.68ce6f03-a63b-43a3-b0f7-2d188699d12c@github.com>

On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

The same data is used in the diff section above, I have updated it and attached the entire data file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308719175

From redestad at openjdk.org  Sun Aug 25 11:28:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 11:28:02 GMT
Subject: RFR: 8338930: StringConcatFactory static string concatenation
 strategy
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <PZvoB1Sx6onV5mLNEx3Pzf6ciDo9Onif5fEHR0P_SFc=.b87ec34a-0a09-4a45-81a5-0fb76316dd91@github.com>

On Thu, 22 Aug 2024 11:50:02 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

- Can we try to optimize the default generation shape further before we reach for this sort of specialization?
- How well-motivated is it to increase complexity to optimize huge expressions, which can be assumed to be rare and less likely to be part of the critical path?
- If we do this I think we need to have a separate control flag than `inlineThreshold`
- Perhaps `hardCoded` would better describe what's going on than `static`: we're hard-coding all the constants and the values derived from them into the concat bytecode. As a result the concatenator becomes `static`, but that's is a side-effect of hard-coding rather than injecting constants.
- Trivial optimizations such as passing `true` to `methodType` and using `MethodTypeDescImpl.ofValidated` could be split out to a separate PR to keep this patch cleaner and easier to review/discuss.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308789379

From duke at openjdk.org  Sun Aug 25 12:12:42 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 12:12:42 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v2]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
  
  This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/3bed7290..a016723f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=00-01

  Stats: 32 lines in 1 file changed: 9 ins; 13 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From duke at openjdk.org  Sun Aug 25 12:16:02 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 12:16:02 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy
In-Reply-To: <PZvoB1Sx6onV5mLNEx3Pzf6ciDo9Onif5fEHR0P_SFc=.b87ec34a-0a09-4a45-81a5-0fb76316dd91@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <PZvoB1Sx6onV5mLNEx3Pzf6ciDo9Onif5fEHR0P_SFc=.b87ec34a-0a09-4a45-81a5-0fb76316dd91@github.com>
Message-ID: <Ywi-GV-ynNYDuw1ZSsSyLs5t1SQCdv1iLFOZzMfWElw=.354fb17c-9406-4b64-8162-914e81c7d525@github.com>

On Sun, 25 Aug 2024 11:25:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> * Can we try to optimize the default generation shape further before we reach for this sort of specialization?

I am also thinking about this, such as the optimization of Integer/Long type parameters. Is this what you are talking about?

> * How well-motivated is it to increase complexity to optimize huge expressions, which can be assumed to be rare and less likely to be part of the critical path?

I agree with you that this is rare, but one thing to consider is that we don't want the new implementation to degrade in these scenarios.

> * If we do this I think we need to have a separate control flag than `inlineThreshold`

I also considered this, for example the new control flag could be named `reuseThreshold`


> * Trivial optimizations such as passing `true` to `methodType` and using `MethodTypeDescImpl.ofValidated` could be split out to a separate PR to keep this patch cleaner and easier to review/discuss.

You are right, I have created a separate PR https://github.com/openjdk/jdk/pull/20704

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308807925

From redestad at openjdk.org  Sun Aug 25 12:32:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 12:32:07 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy
In-Reply-To: <Ywi-GV-ynNYDuw1ZSsSyLs5t1SQCdv1iLFOZzMfWElw=.354fb17c-9406-4b64-8162-914e81c7d525@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <PZvoB1Sx6onV5mLNEx3Pzf6ciDo9Onif5fEHR0P_SFc=.b87ec34a-0a09-4a45-81a5-0fb76316dd91@github.com>
 <Ywi-GV-ynNYDuw1ZSsSyLs5t1SQCdv1iLFOZzMfWElw=.354fb17c-9406-4b64-8162-914e81c7d525@github.com>
Message-ID: <HU8EuHUrM4SG_mprZ80zrA13OAstrHHFpiAcpAM2pXM=.445dc411-9265-465e-b8db-30799864f34c@github.com>

On Sun, 25 Aug 2024 12:13:34 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> > * Can we try to optimize the default generation shape further before we reach for this sort of specialization?
> 
> I am also thinking about this, such as the optimization of Integer/Long type parameters. Is this what you are talking about?

I'm open to any ideas. What I'm reaching for here is whether there are ways to restructure the code for larger methods to help the JIT do certain optimizations, e.g. splitting methods apart a bit to facilitate inlining and constant folding. There might be some low-hanging improvements, which then might push out when hard-coding is worthwhile.

Adding more specializations like for `Integer` is a different, more risky approach since it'll generate more classes (and reduce sharing) in the now-default strategy. For a hard-coded strategy specialization it is more natural. Without an obvious path to apply such optimization to the hottest low-arity call sites then I'm not sure it's a worthwhile endeavor, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308813589

From liach at openjdk.org  Sun Aug 25 12:43:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Aug 2024 12:43:04 GMT
Subject: RFR: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <cJ4eu5IeBpighuiYGRStkwXDWd1X0w9CF9W3Nl__uAI=.fdd66806-c65a-4dd6-bfd0-f9e681640629@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

Since I am not responsible for the date time area, I would prefer @naotoj who's more familiar to review too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20368#pullrequestreview-2259239088

From duke at openjdk.org  Sun Aug 25 12:57:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 12:57:03 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v2]
In-Reply-To: <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>
Message-ID: <XCJkzVahwkqap4OcV_LfQc9-z-AWzME6-bkDS_cGxO4=.a93a266b-5dbc-4333-8981-e566c9f67f5a@github.com>

On Sun, 25 Aug 2024 12:12:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
>   
>   This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.

If the number of parameters is greater than 2, the probability of reuse may not be high. Using hard-coded constants can avoid the use of forceinline.

>From this PR, adding hard-coded constants only requires a small change, which may be a good solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308823147

From duke at openjdk.org  Sun Aug 25 13:12:33 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 13:12:33 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
Message-ID: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>

optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

-------------

Commit messages:
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

Changes: https://git.openjdk.org/jdk/pull/20704/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20704&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338936
  Stats: 34 lines in 1 file changed: 13 ins; 9 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20704.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20704/head:pull/20704

PR: https://git.openjdk.org/jdk/pull/20704

From redestad at openjdk.org  Sun Aug 25 13:12:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 13:12:33 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
Message-ID: <6vGts9u1O0dulnWIAUDGSADpCsl207-lhAPs2OHhO8o=.0ba89089-58f1-4dd2-be29-2678781c577a@github.com>

On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

Marked as reviewed by redestad (Reviewer).

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1200:

> 1198:         /**
> 1199:          * Construct the MethodType of the coder method, if there are no parameters it may be UTF16, return null.
> 1200:          * The first parameter is the initialized coder, Only parameter types that can be UTF16 are added.

Suggestion:

         * Construct the MethodType of the coder method. The first parameter is the initialized coder.
         * Only parameter types which can be UTF16 are added. Returns null if no such parameter exists.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20704#pullrequestreview-2259238024
PR Review Comment: https://git.openjdk.org/jdk/pull/20704#discussion_r1730327504

From redestad at openjdk.org  Sun Aug 25 13:12:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 13:12:33 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <6vGts9u1O0dulnWIAUDGSADpCsl207-lhAPs2OHhO8o=.0ba89089-58f1-4dd2-be29-2678781c577a@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <6vGts9u1O0dulnWIAUDGSADpCsl207-lhAPs2OHhO8o=.0ba89089-58f1-4dd2-be29-2678781c577a@github.com>
Message-ID: <lpGY6wfNKTKGcEpGd9__hXuiNXVjPfdjaN94YbW_a8A=.a137faaa-b790-4977-b601-8d5d7e0d6267@github.com>

On Sun, 25 Aug 2024 12:35:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1200:
> 
>> 1198:         /**
>> 1199:          * Construct the MethodType of the coder method, if there are no parameters it may be UTF16, return null.
>> 1200:          * The first parameter is the initialized coder, Only parameter types that can be UTF16 are added.
> 
> Suggestion:
> 
>          * Construct the MethodType of the coder method. The first parameter is the initialized coder.
>          * Only parameter types which can be UTF16 are added. Returns null if no such parameter exists.

Something to consider (for a follow up) is to not add the initial coder as an argument but test that in the outer method: No point calling the `coder` method if we already know that we're UTF-16.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20704#discussion_r1730329132

From duke at openjdk.org  Sun Aug 25 13:12:34 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 13:12:34 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <lpGY6wfNKTKGcEpGd9__hXuiNXVjPfdjaN94YbW_a8A=.a137faaa-b790-4977-b601-8d5d7e0d6267@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <6vGts9u1O0dulnWIAUDGSADpCsl207-lhAPs2OHhO8o=.0ba89089-58f1-4dd2-be29-2678781c577a@github.com>
 <lpGY6wfNKTKGcEpGd9__hXuiNXVjPfdjaN94YbW_a8A=.a137faaa-b790-4977-b601-8d5d7e0d6267@github.com>
Message-ID: <wk-RApm0uzq5jfv7OqJKioITz3YM4MqhxfLJH3Rw69E=.8a9285ef-83a5-40cd-bf73-540724be21d2@github.com>

On Sun, 25 Aug 2024 12:44:02 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1200:
>> 
>>> 1198:         /**
>>> 1199:          * Construct the MethodType of the coder method, if there are no parameters it may be UTF16, return null.
>>> 1200:          * The first parameter is the initialized coder, Only parameter types that can be UTF16 are added.
>> 
>> Suggestion:
>> 
>>          * Construct the MethodType of the coder method. The first parameter is the initialized coder.
>>          * Only parameter types which can be UTF16 are added. Returns null if no such parameter exists.
>
> Something to consider (for a follow up) is to not add the initial coder as an argument but test that in the outer method: No point calling the `coder` method if we already know that we're UTF-16.

If initCoder is UTF16, the coder method does not need to be generated. This is an optimization and may be a separate PR. Of course, if you agree, I can also put it here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20704#discussion_r1730334070

From redestad at openjdk.org  Sun Aug 25 13:13:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 13:13:03 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v2]
In-Reply-To: <XCJkzVahwkqap4OcV_LfQc9-z-AWzME6-bkDS_cGxO4=.a93a266b-5dbc-4333-8981-e566c9f67f5a@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>
 <XCJkzVahwkqap4OcV_LfQc9-z-AWzME6-bkDS_cGxO4=.a93a266b-5dbc-4333-8981-e566c9f67f5a@github.com>
Message-ID: <D5wXfLWl_ez8iaoqAlvkKPxZ10qpYjyYPjrjvUIJJdI=.c6cb404b-2ce9-45a2-ac03-a101ba14b3aa@github.com>

On Sun, 25 Aug 2024 12:54:08 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> If the number of parameters is greater than 2, the probability of reuse may not be high. Using hard-coded constants can avoid the use of forceinline.

I think this entirely depends on the application. Too low a threshold and many applications will see an increase in number of generated classes. And perhaps we shouldn't assume _any_ high arity concatenations are performance sensitive enough that generating a class-per-call-site is ever a reasonable default. A good tunable for some applications, perhaps.

> 
> From this PR, adding hard-coded constants only requires a small change, which may be a good solution.

It's good that layering this on top of the existing strategy is relatively straightforward, yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2308831173

From redestad at openjdk.org  Sun Aug 25 13:25:02 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 13:25:02 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <wk-RApm0uzq5jfv7OqJKioITz3YM4MqhxfLJH3Rw69E=.8a9285ef-83a5-40cd-bf73-540724be21d2@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <6vGts9u1O0dulnWIAUDGSADpCsl207-lhAPs2OHhO8o=.0ba89089-58f1-4dd2-be29-2678781c577a@github.com>
 <lpGY6wfNKTKGcEpGd9__hXuiNXVjPfdjaN94YbW_a8A=.a137faaa-b790-4977-b601-8d5d7e0d6267@github.com>
 <wk-RApm0uzq5jfv7OqJKioITz3YM4MqhxfLJH3Rw69E=.8a9285ef-83a5-40cd-bf73-540724be21d2@github.com>
Message-ID: <SEJHzE1jAqmnBUHWmwmDOGN1K88Qdz5bPnbe8SHNixc=.e29b283f-08ac-4380-bdc1-6bede4a6bf2b@github.com>

On Sun, 25 Aug 2024 13:03:23 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Something to consider (for a follow up) is to not add the initial coder as an argument but test that in the outer method: No point calling the `coder` method if we already know that we're UTF-16.
>
> If initCoder is UTF16, the coder method does not need to be generated. This is an optimization and may be a separate PR. Of course, if you agree, I can also put it here.

Right, if `initCoder` is always UTF16 (`-XX:-CompactStrings`) then we never need the `coder` method. Nor really if any of the constants have UTF-16 chars, but in those cases it might be more appropriate to inject the derived value and have a runtime test - as long as it get optimized away. Otherwise we might need to generate two different classes per shape.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20704#discussion_r1730342058

From lancea at openjdk.org  Sun Aug 25 13:39:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Aug 2024 13:39:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <04mDTpAYPyJc_PVg2TQq1Fmvf1p7PgfVJkHDcGETuhA=.723673dc-390e-4c1b-aebb-e9867fd9d665@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <04mDTpAYPyJc_PVg2TQq1Fmvf1p7PgfVJkHDcGETuhA=.723673dc-390e-4c1b-aebb-e9867fd9d665@github.com>
Message-ID: <RdZoRGPTtamByMOyg8p4Entv_jfHMnIURYQ73aHT8ks=.ea442115-c578-40f9-8517-2f58672aaa18@github.com>

On Sat, 24 Aug 2024 17:22:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`:
> 
> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637

I am not suggesting link to the CSR, what I was indicating the CSR provides more details  because of the proposed removal.

Comparing to `Thread::stop` is not quite the same, and  the verbiage you are pointing to above was added when the method was [degraded to throw a UOE](https://bugs.openjdk.org/browse/JDK-8277861), not  when it was [deprecated for removal](https://bugs.openjdk.org/browse/JDK-8277861)

The overall usage of ZipError is extremely minimal in the wild at best, from what I can tell was in a catch statement and was not documented to be thrown by any public  API, though was thrown by ZipFile's internal ZipEntryIterator::next

If this was a more heavily used Exception, it would probably warrant further consideration for additional documentation, I am not convinced it is needed here

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2308845720

From redestad at openjdk.org  Sun Aug 25 13:40:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 13:40:03 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <SEJHzE1jAqmnBUHWmwmDOGN1K88Qdz5bPnbe8SHNixc=.e29b283f-08ac-4380-bdc1-6bede4a6bf2b@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <6vGts9u1O0dulnWIAUDGSADpCsl207-lhAPs2OHhO8o=.0ba89089-58f1-4dd2-be29-2678781c577a@github.com>
 <lpGY6wfNKTKGcEpGd9__hXuiNXVjPfdjaN94YbW_a8A=.a137faaa-b790-4977-b601-8d5d7e0d6267@github.com>
 <wk-RApm0uzq5jfv7OqJKioITz3YM4MqhxfLJH3Rw69E=.8a9285ef-83a5-40cd-bf73-540724be21d2@github.com>
 <SEJHzE1jAqmnBUHWmwmDOGN1K88Qdz5bPnbe8SHNixc=.e29b283f-08ac-4380-bdc1-6bede4a6bf2b@github.com>
Message-ID: <kngamfS8qVReGsWuklFx72fdhzpUW9bb5o_3G6DtYa4=.420df695-8598-4926-897a-ef06574e4363@github.com>

On Sun, 25 Aug 2024 13:22:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> If initCoder is UTF16, the coder method does not need to be generated. This is an optimization and may be a separate PR. Of course, if you agree, I can also put it here.
>
> Right, if `initCoder` is always UTF16 (`-XX:-CompactStrings`) then we never need the `coder` method. Nor really if any of the constants have UTF-16 chars, but in those cases it might be more appropriate to inject the derived value and have a runtime test - as long as it get optimized away. Otherwise we might need to generate two different classes per shape.

If we're to pre-generate code for concats when linking JDK images (something that might be a big help for startup) then it'd be nice to be agnostic regarding `CompactStrings`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20704#discussion_r1730352516

From duke at openjdk.org  Sun Aug 25 13:44:29 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 13:44:29 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc
Message-ID: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>

Optimize ClassDesc related string concatenation, which will reduce object allocation during startup.

-------------

Commit messages:
 - Optimize the string concatenation related to ClassDesc during startup

Changes: https://git.openjdk.org/jdk/pull/20705/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338937
  Stats: 46 lines in 6 files changed: 35 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20705/head:pull/20705

PR: https://git.openjdk.org/jdk/pull/20705

From duke at openjdk.org  Sun Aug 25 14:29:16 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 14:29:16 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v3]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <gwIx0j2wmb3qrcgiSEz1_fxdJTGHtoiI7aUe2l6vgB8=.388fdfdb-3c9b-4666-8e5f-cc65ba7abe81@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add control flag `reuseThreshold`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/a016723f..432db40e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From alanb at openjdk.org  Sun Aug 25 15:00:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Aug 2024 15:00:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <TUBTQ0DEb3uxCS4KxE26mHQnGVOdjsMDS1lGqISZMQs=.bde7f5ee-a3e0-4564-abfa-760cda29547b@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
 <CXP90x_kG6QAqALKAtq7kv7NhIM4gAjq646Iln0Jhlg=.e66ac47f-90fc-4381-910c-711c433b3db9@github.com>
 <KFw8bJ-sY91r6fKxN2XxxkuxKmG4UOq0gMCiMEJgHMg=.4c3ba368-880a-4e73-a695-cbaa9ba776e5@github.com>
 <TUBTQ0DEb3uxCS4KxE26mHQnGVOdjsMDS1lGqISZMQs=.bde7f5ee-a3e0-4564-abfa-760cda29547b@github.com>
Message-ID: <IezhAykx47_tL-Wg2rIBcHdxkLTRD0FIHwBY4V7ap54=.0930703a-6ffb-420d-848c-6bca930d21a7@github.com>

On Fri, 23 Aug 2024 10:04:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> But, if you look at the actual functions that are affected, you can see that it is just a handful of calls that are all done at startup time. 

That is true for now but there 30-50 other places that will need attention once this effort is further along. Everywhere that deals with user editable configuration (conf tree) will change, as will everywhere that reads JDK internal files in the lib directory. It will be possible to abstract some of this but just to say that it a lot of it will be in Java code rather than native code. Also there will be specifically changes that goes with some of this, something for later if there is JEP that proposes builds to produce a static image.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2308884916

From duke at openjdk.org  Sun Aug 25 15:09:05 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 25 Aug 2024 15:09:05 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v3]
In-Reply-To: <gwIx0j2wmb3qrcgiSEz1_fxdJTGHtoiI7aUe2l6vgB8=.388fdfdb-3c9b-4666-8e5f-cc65ba7abe81@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <gwIx0j2wmb3qrcgiSEz1_fxdJTGHtoiI7aUe2l6vgB8=.388fdfdb-3c9b-4666-8e5f-cc65ba7abe81@github.com>
Message-ID: <mWd9nIggY1juMEW4YEAYWMJyWY1sJ5n6v58N9VL2oBM=.74f6e769-6a2b-4572-ac38-e8aec1736125@github.com>

On Sun, 25 Aug 2024 14:29:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add control flag `reuseThreshold`

As?the?`paramTypes` passed to?`MethodType?::methodType(?)` and?`MethodTypeDesc?::of(?)` are?guaranteed?valid and?aren?t mutated?afterwards, this?can?use `MethodType?::methodType?(?,?trusted?=?true)` and?`MethodTypeDescImpl?::ofValidated(?)`:

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1202:

> 1200:                 paramTypes[i + prefixArgs] = needStringOf(cl) ? CD_String : ConstantUtils.classDesc(cl);
> 1201:             }
> 1202:             return MethodTypeDesc.of(CD_int, paramTypes);

Suggestion:

            return MethodTypeDescImpl.ofValidated(CD_int, paramTypes);

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1219:

> 1217:                 }
> 1218:             }
> 1219:             return MethodTypeDesc.of(CD_int, paramTypes);

Suggestion:

            return MethodTypeDescImpl.ofValidated(CD_int, paramTypes.toArray(ConstantUtils.EMPTY_CLASSDESC));

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1234:

> 1232:                 paramTypes[i + 1] = needStringOf(cl) ? CD_String : ConstantUtils.classDesc(cl);
> 1233:             }
> 1234:             return MethodTypeDesc.of(CD_int, paramTypes);

Suggestion:

            return MethodTypeDescImpl.ofValidated(CD_int, paramTypes);

-------------

PR Review: https://git.openjdk.org/jdk/pull/20675#pullrequestreview-2259314494
PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1730377690
PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1730377709
PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1730377739

From duke at openjdk.org  Sun Aug 25 15:09:06 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 25 Aug 2024 15:09:06 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v2]
In-Reply-To: <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>
Message-ID: <coVPD3_h9PjLUZFEcNVPX44isAUrWaidEwQ6suS6tDU=.80c3a1a1-a9ca-4f1b-b1c0-c819c6ddd947@github.com>

On Sun, 25 Aug 2024 12:12:42 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
>   
>   This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:

> 1167:                 paramTypes[i] = cl;
> 1168:             }
> 1169:             return changed ? MethodType.methodType(args.returnType(), paramTypes) : args;

Suggestion:

            return changed ? MethodType.methodType(args.returnType(), paramTypes, true) : args;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20675#discussion_r1730375667

From alanb at openjdk.org  Sun Aug 25 15:17:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Aug 2024 15:17:04 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest
In-Reply-To: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
Message-ID: <tm5ZWrT-jISp4Uo7Rsky_ZQbfy7Mcq3LWFsqNePDES8=.b98e01e2-4c5a-46fa-9a91-89a10dd23e2c@github.com>

On Fri, 23 Aug 2024 10:45:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
> 
> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
> 
> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
> 
> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
> 
> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
> 
> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.

The change looks okay, I suspect the issue with handling malformed Class-Path values has been there for 20+ years but hasn't come up. For the bug report then it would be interesting to know if there is a plugin in the eco system that is creating the bad values or whether it's just a one-off.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 447:

> 445:                 loader = getLoader(url);
> 446:                 // If the loader defines a local class path then construct
> 447:                 // and add the URLs as the next URLs to be opened.

The change to URLClassLoad looks okay although I think the original comment was a bit clearer, no need to insert "then construct" here as this is just getting the class path URLs.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 453:

> 451:                 if (DEBUG) {
> 452:                     System.err.println("Failed to construct a loader or construct its" +
> 453:                             " local classpath for " + url + ", cause:" + e);

At some point we should probably get rid of the DEBUG stuff, it looks like it was left over from early JDK releases.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 482:

> 480: 
> 481:     // closes the given loader and ignores any IOException that may occur during close
> 482:     private static void closeLoaderIgnoreEx(final Loader loader) {

closeQuietly(Loader loader) would work too.

test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 78:

> 76: 
> 77:     /*
> 78:      * Creates a jar with a manifest which has a Class-Path entry value with malformed URLs.

I think you mean a "a JAR file" rather than "jar" here. Same nit in  testParsableClassPathEntry.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20691#pullrequestreview-2259319752
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730378354
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730378430
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730378528
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730379053

From lancea at openjdk.org  Sun Aug 25 16:12:01 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 25 Aug 2024 16:12:01 GMT
Subject: RFR: 8338931: ZipEntry.flags could be made internal to
 ZipOutputStream
In-Reply-To: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
References: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
Message-ID: <bnSWPlrS7J3N4xQCp_dq5RASMKBsG-rA1ZXKySvYV10=.dd0d7824-3c4f-45f2-8338-373916daccf4@github.com>

On Sat, 24 Aug 2024 10:49:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this refactoring PR which moves the `ZipEntry.flags` field to `ZipOutputStream.XEntry`.
> 
> Moving this field will save four bytes from the `ZipEntry` object size and also saves an unneccessary read in `ZipFile.getZipEntry`.
> 
> Testing:
> 
> This PR is a refactoring of existing code and does not update any tests. I added the label `noreg-cleanup` to the JBS issue.
> 
> The following runs clean:
> 
> 
> make test TEST="test/jdk/java/util/zip"
> make test TEST="test/jdk/java/util/jar"
> 
> 
> Performance:
> 
> The JMH benchmark `java.util.zip.ZipFileGetEntry.getEntryHit` show a small but consistent improvement (2-3%).

I need to spend some more time thinking about this, but I can ask what made you decide to look at this?

Changing the  field name from _flag_ -> _flags_ then becomes a bit confusing as for example its usage in initCEN and the name of CENFLG.  The field is also used via ZipInputStream (not via ZipEntry but  _flag_). So some thought needs to be given to the naming 

Similar comment for  ZipFileSystem as if we move forward, then we need to be consistent in naming otherwise it becomes (or can be) confusing for future maintainers.

Also the Zip Spec refers to the field as "general purpose bit flag" and the  zlib repository includes a minzip, which also references this field as _flag_  which might be another reason to keep the field name as is regardless of it moving to XEntry

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20702#issuecomment-2308908970

From duke at openjdk.org  Sun Aug 25 17:04:03 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 25 Aug 2024 17:04:03 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc
In-Reply-To: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
Message-ID: <Hz_8xEGVPSxSbTwmz6LDIcrZy1LlKK3tcZ95-WTFEkU=.1fc06198-f7dc-4537-962d-7458a791b0b7@github.com>

On Sun, 25 Aug 2024 13:36:34 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Optimize ClassDesc related string concatenation, which will reduce object allocation during startup.

src/java.base/share/classes/java/lang/StringConcatHelper.java line 787:

> 785:     }
> 786: 
> 787:     static String concat(String prefix, String value, String suffix) {

`Class?::descriptorString()` can?probably also?make?use of?this?method and?`String?::concat?(String)`:

if (isArray()) {
	return "[".concat(componentType.descriptorString());
} else if (isHidden()) {
	// unchanged
} else {
	String name = getName().replace('.', '/');
	return StringConcatHelper.concat("L", name, ";");
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20705#discussion_r1730395340

From redestad at openjdk.org  Sun Aug 25 18:11:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Sun, 25 Aug 2024 18:11:05 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
Message-ID: <niozr8sklTO859cgwxwTDgJC9FNgEXIWR-HolGFU0wI=.3cd6fc1b-1bb1-4f62-9f8d-139bba9a502c@github.com>

On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20704#pullrequestreview-2259349847

From eirbjo at openjdk.org  Sun Aug 25 19:29:01 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 25 Aug 2024 19:29:01 GMT
Subject: RFR: 8338931: ZipEntry.flags could be made internal to
 ZipOutputStream
In-Reply-To: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
References: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
Message-ID: <gW8-wb0WFhYt2qmvCccsd3uR6GtUSo8q6BAAUyXMP0o=.0166366e-cdea-414b-a61f-dade7b8d01c9@github.com>

On Sat, 24 Aug 2024 10:49:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this refactoring PR which moves the `ZipEntry.flags` field to `ZipOutputStream.XEntry`.
> 
> Moving this field will save four bytes from the `ZipEntry` object size and also saves an unneccessary read in `ZipFile.getZipEntry`.
> 
> Testing:
> 
> This PR is a refactoring of existing code and does not update any tests. I added the label `noreg-cleanup` to the JBS issue.
> 
> The following runs clean:
> 
> 
> make test TEST="test/jdk/java/util/zip"
> make test TEST="test/jdk/java/util/jar"
> 
> 
> Performance:
> 
> The JMH benchmark `java.util.zip.ZipFileGetEntry.getEntryHit` show a small but consistent improvement (2-3%).

Sorry, the renaming was just an accident, It was ?flags? in my head, but that was wrong.

Will revert the rename once I?m in front of a keyboard again in a few days.


The reason I?m looking at this is that ZipEntry is 88 bytes, and the allocation cost is significant when iterating entries. So it would be beneficial to move unused or optional parts out of the common lookup/enumeration code paths. This seemed like a small but obvious win.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20702#issuecomment-2308965369

From liach at openjdk.org  Sun Aug 25 20:16:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Aug 2024 20:16:02 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
Message-ID: <6BfWQLGnq1fyfKJaQ74x5hvQpPDNk2W99oj5UfGsDlM=.e75d0c01-66d3-4b03-bc8b-a3cf84a240eb@github.com>

On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

@wenshao Can you change all `MethodTypeDesc.of` and the `CONSTRUCTOR_METHOD_TYPE` static final fields in inlined strategy to be optimized too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20704#issuecomment-2308978740

From duke at openjdk.org  Sun Aug 25 21:10:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 21:10:03 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc
In-Reply-To: <Hz_8xEGVPSxSbTwmz6LDIcrZy1LlKK3tcZ95-WTFEkU=.1fc06198-f7dc-4537-962d-7458a791b0b7@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
 <Hz_8xEGVPSxSbTwmz6LDIcrZy1LlKK3tcZ95-WTFEkU=.1fc06198-f7dc-4537-962d-7458a791b0b7@github.com>
Message-ID: <ApIRtDOQJY3Ma2Mnjdut_8xTj6LJGMJhwaDeaRaZYBs=.55b7e14d-6760-4161-a31f-f8955f75a6ed@github.com>

On Sun, 25 Aug 2024 16:55:23 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Optimize ClassDesc related string concatenation, which will reduce object allocation during startup.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 787:
> 
>> 785:     }
>> 786: 
>> 787:     static String concat(String prefix, String value, String suffix) {
> 
> `Class?::descriptorString()` can?probably also?make?use of?this?method and?`String?::concat?(String)`:
> 
> if (isArray()) {
> 	return "[".concat(componentType.descriptorString());
> } else if (isHidden()) {
> 	// unchanged
> } else {
> 	String name = getName().replace('.', '/');
> 	return StringConcatHelper.concat("L", name, ";");
> }

In this case, there are too many locations under the java.lang package to change, and a new PR may be more appropriate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20705#discussion_r1730430947

From duke at openjdk.org  Sun Aug 25 21:32:02 2024
From: duke at openjdk.org (ExE Boss)
Date: Sun, 25 Aug 2024 21:32:02 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc
In-Reply-To: <ApIRtDOQJY3Ma2Mnjdut_8xTj6LJGMJhwaDeaRaZYBs=.55b7e14d-6760-4161-a31f-f8955f75a6ed@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
 <Hz_8xEGVPSxSbTwmz6LDIcrZy1LlKK3tcZ95-WTFEkU=.1fc06198-f7dc-4537-962d-7458a791b0b7@github.com>
 <ApIRtDOQJY3Ma2Mnjdut_8xTj6LJGMJhwaDeaRaZYBs=.55b7e14d-6760-4161-a31f-f8955f75a6ed@github.com>
Message-ID: <-fuXxE0pHV8Yj7mj2T_1y2CpIOXo8j0mXQAC0GRHVXU=.eb317b32-4b43-41d7-b21c-68cf13ff5942@github.com>

On Sun, 25 Aug 2024 21:07:16 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 787:
>> 
>>> 785:     }
>>> 786: 
>>> 787:     static String concat(String prefix, String value, String suffix) {
>> 
>> `Class?::descriptorString()` can?probably also?make?use of?this?method and?`String?::concat?(String)`:
>> 
>> if (isArray()) {
>> 	return "[".concat(componentType.descriptorString());
>> } else if (isHidden()) {
>> 	// unchanged
>> } else {
>> 	String name = getName().replace('.', '/');
>> 	return StringConcatHelper.concat("L", name, ";");
>> }
>
> In this case, there are too many locations under the java.lang package to change, and a new PR may be more appropriate.

Well, `Class?::descriptorString()` is?referenced?from the?`ReferenceClassDescImpl` creation?code in?`ConstantUtils`:
https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L89-L91

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20705#discussion_r1730433878

From duke at openjdk.org  Sun Aug 25 21:40:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 21:40:14 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc [v2]
In-Reply-To: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
Message-ID: <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>

> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  use MethodTypeDescImpl.ofValidated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20704/files
  - new: https://git.openjdk.org/jdk/pull/20704/files/d8b60139..727ec217

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20704&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20704&range=00-01

  Stats: 27 lines in 1 file changed: 1 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/20704.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20704/head:pull/20704

PR: https://git.openjdk.org/jdk/pull/20704

From duke at openjdk.org  Sun Aug 25 21:40:14 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 21:40:14 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <6BfWQLGnq1fyfKJaQ74x5hvQpPDNk2W99oj5UfGsDlM=.e75d0c01-66d3-4b03-bc8b-a3cf84a240eb@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <6BfWQLGnq1fyfKJaQ74x5hvQpPDNk2W99oj5UfGsDlM=.e75d0c01-66d3-4b03-bc8b-a3cf84a240eb@github.com>
Message-ID: <JuScY9Xs5l_qPN9QE8YTSmPCmwuuDTVeG89GW3yJBJg=.1481d000-3782-493b-87ee-705b366225ad@github.com>

On Sun, 25 Aug 2024 20:13:11 GMT, Chen Liang <liach at openjdk.org> wrote:

> @wenshao Can you change all `MethodTypeDesc.of` and the `CONSTRUCTOR_METHOD_TYPE` static final fields in inlined strategy to be optimized too?

CONSTRUCTOR_METHOD_TYPE The current strategy is optimization:


MethodType CONSTRUCTOR_METHOD_TYPE = MethodType.methodType(void.class, String[].class);

-> static MethodType methodType(Class<?> rtype, Class<?> ptype0) {
-> makeImpl(rtype, new Class<?>[]{ ptype0 }, true);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20704#issuecomment-2309003257

From duke at openjdk.org  Sun Aug 25 21:44:02 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 25 Aug 2024 21:44:02 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc
In-Reply-To: <-fuXxE0pHV8Yj7mj2T_1y2CpIOXo8j0mXQAC0GRHVXU=.eb317b32-4b43-41d7-b21c-68cf13ff5942@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
 <Hz_8xEGVPSxSbTwmz6LDIcrZy1LlKK3tcZ95-WTFEkU=.1fc06198-f7dc-4537-962d-7458a791b0b7@github.com>
 <ApIRtDOQJY3Ma2Mnjdut_8xTj6LJGMJhwaDeaRaZYBs=.55b7e14d-6760-4161-a31f-f8955f75a6ed@github.com>
 <-fuXxE0pHV8Yj7mj2T_1y2CpIOXo8j0mXQAC0GRHVXU=.eb317b32-4b43-41d7-b21c-68cf13ff5942@github.com>
Message-ID: <3kyW1twmZRxE9JK7IjXGMExzaeRnd3oNAV09RiKvIKQ=.0863b4f5-edd7-4c2b-aca2-bc6e222f42c6@github.com>

On Sun, 25 Aug 2024 21:29:17 GMT, ExE Boss <duke at openjdk.org> wrote:

>> In this case, there are too many locations under the java.lang package to change, and a new PR may be more appropriate.
>
> Well, `Class?::descriptorString()` is?referenced?from the?`ReferenceClassDescImpl` creation?code in?`ConstantUtils`:
> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L89-L91

I plan to change all of these in another PR https://github.com/wenshao/jdk/commit/b500348cde84e10dc968c7503b8c1dac9131f146

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20705#discussion_r1730435430

From liach at openjdk.org  Sun Aug 25 22:04:03 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Aug 2024 22:04:03 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc [v2]
In-Reply-To: <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
Message-ID: <dZHTJGNtYx3YFpST4WFIxoGRht2LEWsbXxKuONP_s-E=.232cdf60-4961-4f8f-b31c-b3cc2cd43ea4@github.com>

On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use MethodTypeDescImpl.ofValidated

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20704#pullrequestreview-2259381318

From dholmes at openjdk.org  Mon Aug 26 01:46:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Aug 2024 01:46:16 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <EYbuvur4hnPbqb-Fk6T5mdOuC71ILmqHrlZUDV6Pk3Y=.1f2ef4bd-dbdf-4aa4-a688-d034c832a0e5@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Still good for me. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2259495896

From dholmes at openjdk.org  Mon Aug 26 02:10:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Aug 2024 02:10:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2309162391

From kbarrett at openjdk.org  Mon Aug 26 02:52:06 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 26 Aug 2024 02:52:06 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <E1EB-N_nMpnlwWpP1LM13yVh3VIg_mzaGXQOJeEwuUA=.88131db9-0520-455e-b518-55041cc3b058@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Still good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2259597625

From jpai at openjdk.org  Mon Aug 26 03:47:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Aug 2024 03:47:49 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
Message-ID: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
> 
> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
> 
> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
> 
> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
> 
> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
> 
> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - revert to old code comment
 - use "JAR file" consistently in test's code comments
 - rename closeLoaderIgnoreEx to closeQuietly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20691/files
  - new: https://git.openjdk.org/jdk/pull/20691/files/ad2272cf..b5bf8412

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20691&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20691&range=00-01

  Stats: 22 lines in 2 files changed: 0 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20691/head:pull/20691

PR: https://git.openjdk.org/jdk/pull/20691

From jpai at openjdk.org  Mon Aug 26 05:20:07 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Aug 2024 05:20:07 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <tm5ZWrT-jISp4Uo7Rsky_ZQbfy7Mcq3LWFsqNePDES8=.b98e01e2-4c5a-46fa-9a91-89a10dd23e2c@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <tm5ZWrT-jISp4Uo7Rsky_ZQbfy7Mcq3LWFsqNePDES8=.b98e01e2-4c5a-46fa-9a91-89a10dd23e2c@github.com>
Message-ID: <loOPzDTdzMwegdj1nnY6L_ALuSPq902nTYfJlI0me5s=.642357ef-b2b2-44e9-a8a8-e2665405dc4b@github.com>

On Sun, 25 Aug 2024 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert to old code comment
>>  - use "JAR file" consistently in test's code comments
>>  - rename closeLoaderIgnoreEx to closeQuietly
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 447:
> 
>> 445:                 loader = getLoader(url);
>> 446:                 // If the loader defines a local class path then construct
>> 447:                 // and add the URLs as the next URLs to be opened.
> 
> The change to URLClassLoad looks okay although I think the original comment was a bit clearer, no need to insert "then construct" here as this is just getting the class path URLs.

Hello Alan, I've reverted the change to this code comment in the latest update to this PR.

> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 453:
> 
>> 451:                 if (DEBUG) {
>> 452:                     System.err.println("Failed to construct a loader or construct its" +
>> 453:                             " local classpath for " + url + ", cause:" + e);
> 
> At some point we should probably get rid of the DEBUG stuff, it looks like it was left over from early JDK releases.

The debug logs are currently enabled through the `sun.misc.URLClassPath.debug` system property. Do you mean we should completely get rid of the `sun.misc.URLClassPath.debug` system property in future?

> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 482:
> 
>> 480: 
>> 481:     // closes the given loader and ignores any IOException that may occur during close
>> 482:     private static void closeLoaderIgnoreEx(final Loader loader) {
> 
> closeQuietly(Loader loader) would work too.

I had considered `safeClose(...)` but that didn't sound right. But what you suggest is more precise. I've updated the PR to use this suggestion.

> test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 78:
> 
>> 76: 
>> 77:     /*
>> 78:      * Creates a jar with a manifest which has a Class-Path entry value with malformed URLs.
> 
> I think you mean a "a JAR file" rather than "jar" here. Same nit in  testParsableClassPathEntry.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730676789
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730677519
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730677963
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1730678041

From jpai at openjdk.org  Mon Aug 26 05:37:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Aug 2024 05:37:03 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <tm5ZWrT-jISp4Uo7Rsky_ZQbfy7Mcq3LWFsqNePDES8=.b98e01e2-4c5a-46fa-9a91-89a10dd23e2c@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <tm5ZWrT-jISp4Uo7Rsky_ZQbfy7Mcq3LWFsqNePDES8=.b98e01e2-4c5a-46fa-9a91-89a10dd23e2c@github.com>
Message-ID: <IF8iOQZUA0-ITMY4djX9gNnhQeHFIChGntMUegPpwLY=.c47417b2-daf1-4f2d-b17d-edc3fefdf6d9@github.com>

On Sun, 25 Aug 2024 15:14:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>  For the bug report then it would be interesting to know if there is a plugin in the eco system that is creating the bad values or whether it's just a one-off.

I ran a test against the corpus. Of the 900K odd artifacts, only 2 jar files exhibited the issue where they had a `Class-Path` value which was malformed (resulting in a `MalformedURIException`).

Of those 2, one was due to what appears to be a user error - the Maven jar plugin allows for a `classpathPrefix` attribute which can be configured to use a custom prefix for each of the entries that will be added as a value to the `Class-Path` attribute (imagine prefixing each entry with `lib/`). In this case, it appears that this value was configured with an absolute path (`C:/Users/foo/.m2/repository/....`). As for the other jar with the malformed Class-Path, it's not clear how it was generated.

As for the specific project which reported this issue, this appears to be an isolated test specific utility which seems to be generating that malformed entry in one of the test jar files. It looks like it has been this way for several years. It's unclear to me what changed in that project recently which might have exposed this leak.

So this looks like a very rare case and isn't something that is generated generically by some plugin. When the `URLClassPath` detects such malformed `Class-Path` entries in a jar, then it ignores that jar. So if such entries were more common, then I think we would have seen complaints that would have said that `foo.jar` (which consists of a malformed `Class-Path` in its manifest) isn't being used to serve resources even when it is part of the classpath.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2309355016

From alanb at openjdk.org  Mon Aug 26 07:09:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Aug 2024 07:09:07 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
Message-ID: <cGAwRzv6Tnjo08tyalmyX8A96rp0InB_JD50b8n7cxU=.c19bcca9-3801-4442-8cf4-ba66ea5f9281@github.com>

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert to old code comment
>  - use "JAR file" consistently in test's code comments
>  - rename closeLoaderIgnoreEx to closeQuietly

> I ran a test against the corpus. Of the 900K odd artifacts, only 2 jar files exhibited the issue where they had a `Class-Path` value which was malformed (resulting in a `MalformedURIException`).
> 
> :
> 
> So this looks like a very rare case and isn't something that is generated generically by some plugin. When the `URLClassPath` detects such malformed `Class-Path` entries in a jar, then it ignores that jar. So if such entries were more common, then I think we would have seen complaints that would have said that `foo.jar` (which consists of a malformed `Class-Path` in its manifest) isn't being used to serve resources even when it is part of the classpath.

Great analysis, thank you!  I'm was mostly curious why a 25+ year old issue was only coming up now and was concerned there may be a broken plugin in the eco system that was generating these bad attribute values. Separately, I've often wondered how many plugins are putting file paths into the value by mistake, this has historically been an area of confusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2309490563

From mcimadamore at openjdk.org  Mon Aug 26 09:20:18 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Aug 2024 09:20:18 GMT
Subject: Integrated: 8331671: Implement JEP 472: Prepare to Restrict the Use of
 JNI
In-Reply-To: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
References: <CZGbki5iFdCGPPagE-ya-_L8Nkgf7OunywApOsxC548=.2cee82fa-a5d2-4165-b012-30982a85030a@github.com>
Message-ID: <3nep7-Z8_feW39di9cTU1O07lgFQD4WmSHQia-UUS7c=.18fb2776-9f8a-47c8-be58-8cd1dd30d45f@github.com>

On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting the use of JNI in the following ways:
> 
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibrary` are now restricted methods
> * binding a JNI `native` method declaration to a native implementation is now considered a restricted operation
> 
> This PR slightly changes the way in which the JDK deals with restricted methods, even for FFM API calls. In Java 22, the single `--enable-native-access` was used both to specify a set of modules for which native access should be allowed *and* to specify whether illegal native access (that is, native access occurring from a module not specified by `--enable-native-access`) should be treated as an error or a warning. More specifically, an error is only issued if the `--enable-native-access flag` is used at least once.
> 
> Here, a new flag is introduced, namely `illegal-native-access=allow/warn/deny`, which is used to specify what should happen when access to a restricted method and/or functionality is found outside the set of modules specified with `--enable-native-access`. The default policy is `warn`, but users can select `allow` to suppress the warnings, or `deny` to cause `IllegalCallerException` to be thrown. This aligns the treatment of restricted methods with other mechanisms, such as `--illegal-access` and the more recent `--sun-misc-unsafe-memory-access`.
> 
> Some changes were required in the package-info javadoc for `java.lang.foreign`, to reflect the changes in the command line flags described above.

This pull request has now been integrated.

Changeset: 20d8f58c
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20d8f58c92009a46dfb91b951e7d87b4cb8e8b41
Stats:     532 lines in 107 files changed: 341 ins; 52 del; 139 mod

8331671: Implement JEP 472: Prepare to Restrict the Use of JNI

Reviewed-by: jpai, prr, ihse, kcr, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/19213

From alanb at openjdk.org  Mon Aug 26 09:27:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Aug 2024 09:27:02 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
Message-ID: <LVIBK8Yjq3UOdjC2KQL2WN59fql5heQl7TM23xy6oBU=.c5e925e9-62bf-4583-84e1-5da972c718d7@github.com>

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert to old code comment
>  - use "JAR file" consistently in test's code comments
>  - rename closeLoaderIgnoreEx to closeQuietly

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20691#pullrequestreview-2260229143

From redestad at openjdk.org  Mon Aug 26 09:33:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 09:33:04 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc [v2]
In-Reply-To: <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
Message-ID: <6hxBkQEv9LUeOP7PXqvjBE091aFyNd83tXacAd1yVRo=.aa654bc6-bcbd-4821-90ee-9a0a5b4b6afb@github.com>

On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use MethodTypeDescImpl.ofValidated

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20704#pullrequestreview-2260241974

From ihse at openjdk.org  Mon Aug 26 09:39:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Aug 2024 09:39:04 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <IezhAykx47_tL-Wg2rIBcHdxkLTRD0FIHwBY4V7ap54=.0930703a-6ffb-420d-848c-6bca930d21a7@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <G7II3YG61YbM0s105q7Wz2yaI6MReyvSqLLeo-Rwm5o=.31effaba-651b-47f7-ba86-bd305a5fc176@github.com>
 <CXP90x_kG6QAqALKAtq7kv7NhIM4gAjq646Iln0Jhlg=.e66ac47f-90fc-4381-910c-711c433b3db9@github.com>
 <KFw8bJ-sY91r6fKxN2XxxkuxKmG4UOq0gMCiMEJgHMg=.4c3ba368-880a-4e73-a695-cbaa9ba776e5@github.com>
 <TUBTQ0DEb3uxCS4KxE26mHQnGVOdjsMDS1lGqISZMQs=.bde7f5ee-a3e0-4564-abfa-760cda29547b@github.com>
 <IezhAykx47_tL-Wg2rIBcHdxkLTRD0FIHwBY4V7ap54=.0930703a-6ffb-420d-848c-6bca930d21a7@github.com>
Message-ID: <FqTN5Bpm4HJQg8Z2G1xhloCFgnIGiJae4xYqFZxD60E=.68585beb-c8df-4b59-8602-198bff8f2be1@github.com>

On Sun, 25 Aug 2024 14:57:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> That is true for now but there 30-50 other places that will need attention once this effort is further along. Everywhere that deals with user editable configuration (conf tree) will change, as will everywhere that reads JDK internal files in the lib directory. 

Well, yes and no. What you are talking about is the Hermetic Java project as a whole. This is about making the build smarter and more efficient at producing static libraries.

While static libraries are a sine qua non for Hermetic Java, it is also produced by other reasons. (For instance, the GraalVM and the Mobile Project). It is true that Hermetic Java was what actually got me to prioritize getting static builds to work properly, but the fact is that it has been a sore point for a long time, and the fact that we need to build all object files twice is actually putting a noticable effect on the Oracle CI system. 

So please don't confuse the cleanup of static builds with the eventual goals of Hermetic Java. The runtime changes needed to read config files from a single binary will need to stand on it's own. The changes in this PR is good for us, regardless of however Hermetic Java proceeds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2309780980

From ihse at openjdk.org  Mon Aug 26 09:42:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 Aug 2024 09:42:04 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
Message-ID: <4zUGEcC6eLmdq0wAqDCgAjsU17u6-sQNv8KZVQ8pCKc=.f8801e0b-8351-4af9-9825-70ccfa63847a@github.com>

On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs.

Seriously? I challenge you do prove there is any effect at all. :-/

Also, there is not a "handful" of builders of static libraries. Our internal CI system builds static libraries all the time, and I for one would be glad to use these resources on more productive stuff than building all object files twice. 

Also, the intention is to enable static builds by default on GHA, once the entire process of making static builds "dirt cheap" is finished, to avoid regressions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2309786734

From redestad at openjdk.org  Mon Aug 26 10:07:04 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 10:07:04 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy
In-Reply-To: <000001daf6b0$05723a20$1056ae60$@eu>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <000001daf6b0$05723a20$1056ae60$@eu>
Message-ID: <1Vj8QDqLSTHUOH58JsH-V8CNmDiyNZXJaMr4SYeGb98=.e0f0a369-ed7f-460c-9ca6-e6b30ced6509@github.com>

On Sun, 25 Aug 2024 22:03:56 GMT, Markus Karg <markus at headcrashing.eu> wrote:

> Could it be the case that you posted twice the exact same performance numbers? I do not see any actual difference in your numbers.

He did, then updated the numbers and posted this comment:

> The same data is used in the diff section above, I have updated it and attached the entire data file.

Editing a GitHub comment does not generate a new e-mail to the mailing list, unfortunately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2309836015

From mullan at openjdk.org  Mon Aug 26 11:10:07 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 26 Aug 2024 11:10:07 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <ghMPpv2Iku2kSGGWlHa4vJ-FIQS0drMp-jLNPTAjyVg=.a13f4f98-37b0-4fed-958a-66f59432b22b@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

The change to j2secmod_md.c looks fine to me.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20153#pullrequestreview-2260416114

From pminborg at openjdk.org  Mon Aug 26 11:52:27 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 11:52:27 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill
Message-ID: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>

The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).

Also, smaller segments can be handled directly by Java code rather than transitioning to native code.

Here is how the `MemorySegment::fill` performance is improved by this PR:

![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)

Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.

It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

-------------

Commit messages:
 - Reduce kick-in size and add test
 - Initial implementation

Changes: https://git.openjdk.org/jdk/pull/20712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338967
  Stats: 235 lines in 3 files changed: 231 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From pminborg at openjdk.org  Mon Aug 26 11:56:41 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 11:56:41 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v2]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <r70htL7Hs-hfBnnA3YfNtHulpwUGc-lNSIL-re3FCOI=.9e8b1f37-4455-4144-9fb5-44d880c19ba1@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/4d8268d1..da88ef77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From pminborg at openjdk.org  Mon Aug 26 11:59:44 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 11:59:44 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v3]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <mzNPEEJo7vfiKdHxn-1gSIcjQg0aY_AUoICNIj1U2qg=.b5084aa7-98cc-44be-a9c7-ef77fed4007b@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add a comment about the old switch type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/da88ef77..81ed8cea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From pminborg at openjdk.org  Mon Aug 26 12:11:29 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 12:11:29 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/81ed8cea..b28f97fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From pminborg at openjdk.org  Mon Aug 26 12:11:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 12:11:30 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v3]
In-Reply-To: <mzNPEEJo7vfiKdHxn-1gSIcjQg0aY_AUoICNIj1U2qg=.b5084aa7-98cc-44be-a9c7-ef77fed4007b@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <mzNPEEJo7vfiKdHxn-1gSIcjQg0aY_AUoICNIj1U2qg=.b5084aa7-98cc-44be-a9c7-ef77fed4007b@github.com>
Message-ID: <br_ie4DQ6EdixgstAeC8m83rZ2FzCEiwwlfMpy52pQU=.1089a5cc-1274-4a6b-82c9-110d48cb5f1f@github.com>

On Mon, 26 Aug 2024 11:59:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about the old switch type

Here is what it looks like for Windows x64:

![image](https://github.com/user-attachments/assets/53b6530c-76b7-47f1-ae02-124d16351d45)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2310048420

From jwaters at openjdk.org  Mon Aug 26 12:27:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Aug 2024 12:27:07 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <fnjW4VmORyCWuxXw_qVVAetQQPFd8swSAFzEmUO4AHY=.a866a36d-b2eb-4bfb-b642-43176cd2f679@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Awesome! Will wait a while before integrating so objections, if any, can be raised. If no objections are raised by tomorrow morning I'll proceed with integration

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2310083308

From duke at openjdk.org  Mon Aug 26 12:45:03 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 26 Aug 2024 12:45:03 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v3]
In-Reply-To: <br_ie4DQ6EdixgstAeC8m83rZ2FzCEiwwlfMpy52pQU=.1089a5cc-1274-4a6b-82c9-110d48cb5f1f@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <mzNPEEJo7vfiKdHxn-1gSIcjQg0aY_AUoICNIj1U2qg=.b5084aa7-98cc-44be-a9c7-ef77fed4007b@github.com>
 <br_ie4DQ6EdixgstAeC8m83rZ2FzCEiwwlfMpy52pQU=.1089a5cc-1274-4a6b-82c9-110d48cb5f1f@github.com>
Message-ID: <vKJrpNmfapvRgzxWWg849PnvyZgV6hv7FDyqRLG57VY=.d8a43fd2-ecb6-49b7-943b-d5c602899452@github.com>

On Mon, 26 Aug 2024 12:07:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a comment about the old switch type
>
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/53b6530c-76b7-47f1-ae02-124d16351d45)

Hi @minborg as https://github.com/openjdk/jdk/pull/16760  has shown, handling small chunks in Java can be beneficial, but AFAIK Unsafe::setMemory has been intrinsified already at https://github.com/openjdk/jdk/pull/18555, so I'm surprised that should provide some benefit now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2310121894

From duke at openjdk.org  Mon Aug 26 12:55:04 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 26 Aug 2024 12:55:04 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
Message-ID: <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>

On Mon, 26 Aug 2024 12:11:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 200:

> 198:             switch ((int) length) {
> 199:                 case 0 : checkReadOnly(false); checkValidState(); break; // Explicit tests
> 200:                 case 1 : set(JAVA_BYTE, 0, value); break;

beware using a switch, because if this code if is too big to be inlined (or we're unlucky) will die due to branch-mispredict in case the different "small fills" are unstable/unpredictable.
Having a test which feed different fill sizes per each iteration + counting branch misses, will reveal if the improvement is worthy even with such cases

test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java line 86:

> 84:     @Benchmark
> 85:     public void buffer_fill() {
> 86:         // Hopefully, the creation of the intermediate array will be optimized away.

This maybe won't....why not making the byte array a static final?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731197802
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731199814

From pminborg at openjdk.org  Mon Aug 26 13:34:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 13:34:06 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
 <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>
Message-ID: <z36Rd17ZsMy6BYpR54PUVWTZuGEHYpqJQDSkS6rbA0Y=.14c91a11-6887-4741-93fc-40de74140ad3@github.com>

On Mon, 26 Aug 2024 12:50:53 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 200:
> 
>> 198:             switch ((int) length) {
>> 199:                 case 0 : checkReadOnly(false); checkValidState(); break; // Explicit tests
>> 200:                 case 1 : set(JAVA_BYTE, 0, value); break;
> 
> beware using a switch, because if this code if is too big to be inlined (or we're unlucky) will die due to branch-mispredict in case the different "small fills" are unstable/unpredictable.
> Having a test which feed different fill sizes per each iteration + counting branch misses, will reveal if the improvement is worthy even with such cases

It is true, that this is a compromise where we give up inline space, code-cache space, and added complexity against the prospect of better small-size performance. Depending on the workload, this may or may not pay off. In the (presumably common) case where we allocate/fill small segments of constant sizes, this is likely a win. Writing a dynamic performance test sounds like a good idea.

> test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java line 86:
> 
>> 84:     @Benchmark
>> 85:     public void buffer_fill() {
>> 86:         // Hopefully, the creation of the intermediate array will be optimized away.
> 
> This maybe won't....why not making the byte array a static final?

The size of the array varies with the length of the array. It seams that escape analysis works here though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731249923
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731252199

From redestad at openjdk.org  Mon Aug 26 13:35:31 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 13:35:31 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622 and
 JDK-8331932
Message-ID: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>

#14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 

One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.

-------------

Commit messages:
 - Inline InterningCache
 - Make Locale and BaseLocale lazily initialized and more efficient

Changes: https://git.openjdk.org/jdk/pull/20713/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20713&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338897
  Stats: 37 lines in 2 files changed: 12 ins; 16 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20713/head:pull/20713

PR: https://git.openjdk.org/jdk/pull/20713

From pminborg at openjdk.org  Mon Aug 26 13:37:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 13:37:04 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v3]
In-Reply-To: <br_ie4DQ6EdixgstAeC8m83rZ2FzCEiwwlfMpy52pQU=.1089a5cc-1274-4a6b-82c9-110d48cb5f1f@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <mzNPEEJo7vfiKdHxn-1gSIcjQg0aY_AUoICNIj1U2qg=.b5084aa7-98cc-44be-a9c7-ef77fed4007b@github.com>
 <br_ie4DQ6EdixgstAeC8m83rZ2FzCEiwwlfMpy52pQU=.1089a5cc-1274-4a6b-82c9-110d48cb5f1f@github.com>
Message-ID: <Sr4mvIHHvZ0GN1SOgXRSRHegLmEFN8dh19B_ex0XA8U=.783e429b-fefe-41c5-881a-a4ba608f26cb@github.com>

On Mon, 26 Aug 2024 12:07:02 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a comment about the old switch type
>
> Here is what it looks like for Windows x64:
> 
> ![image](https://github.com/user-attachments/assets/53b6530c-76b7-47f1-ae02-124d16351d45)

> Hi @minborg as #16760 has shown, handling small chunks in Java can be beneficial, but AFAIK Unsafe::setMemory has been intrinsified already at #18555, so I'm surprised that should provide some benefit now.

I think the cost of transitioning to native code is what gives us this opportunity. So, there is always a fairly constant performance hit to transition to native code. Once native, the actual filling performance is way better in native code. The cut-off size lies appears to be close to 8 bytes and hence, this PR handles 0 <= length < 7 specifically.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2310232722

From redestad at openjdk.org  Mon Aug 26 13:38:05 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 13:38:05 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them [v2]
In-Reply-To: <3qM_SkQMOTg_QQKqeKIroBZStsWM__vRhC9dzRLT0xM=.d1cad66f-9ed5-4c81-a409-64f623d9e8d3@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
 <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
 <3qM_SkQMOTg_QQKqeKIroBZStsWM__vRhC9dzRLT0xM=.d1cad66f-9ed5-4c81-a409-64f623d9e8d3@github.com>
Message-ID: <hqUhgMoSLFUjxejz74xfpHQd2F1MSM1JNiIEH1JZCzg=.7329ebed-b43a-4ef9-9592-1113893cab6a@github.com>

On Sun, 25 Aug 2024 02:08:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>
> Marked as reviewed by liach (Reviewer).

Thanks @liach 

Perhaps @lahodaj or @vicente-romero-oracle could take a look at this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20693#issuecomment-2310234998

From redestad at openjdk.org  Mon Aug 26 13:45:37 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 13:45:37 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
Message-ID: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>

Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.

-------------

Commit messages:
 - Avoid bootstrapped switches in the classfile API to reduce risk of bootstrap circularity

Changes: https://git.openjdk.org/jdk/pull/20714/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338979
  Stats: 29 lines in 2 files changed: 12 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20714.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20714/head:pull/20714

PR: https://git.openjdk.org/jdk/pull/20714

From liach at openjdk.org  Mon Aug 26 13:45:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 13:45:37 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
In-Reply-To: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
Message-ID: <Qde4DDOV7C9NTD_9iZ3Egp9JEhZ5cUvL9NLAZKC8_Ps=.54045ec9-c634-4dce-b3ed-aa3f88c6a5ec@github.com>

On Mon, 26 Aug 2024 13:39:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 1:

> 1: /*

You can update copyright year in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20714#discussion_r1731268857

From liach at openjdk.org  Mon Aug 26 13:49:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 13:49:04 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622
 and JDK-8331932
In-Reply-To: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
Message-ID: <-0JcXuxdAuEIn-aXIuLICOU566cjmRiqsdD0CEi-fl8=.db2d9551-7721-474c-ad57-cc46e0e9629e@github.com>

On Mon, 26 Aug 2024 13:30:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
> 
> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.

I personally prefer declaring `LocaleCache` class final as it's not abstract. Waiting for a i18n/locale reviewer too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20713#pullrequestreview-2260737772

From redestad at openjdk.org  Mon Aug 26 13:52:35 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 13:52:35 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
Message-ID: <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>

> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20714/files
  - new: https://git.openjdk.org/jdk/pull/20714/files/43429cc0..8244c4a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20714&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20714&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20714.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20714/head:pull/20714

PR: https://git.openjdk.org/jdk/pull/20714

From liach at openjdk.org  Mon Aug 26 13:52:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 13:52:35 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
 <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
Message-ID: <svh8oRkXXoD30dQfyz44JocB1LPmUQkdMOV5zPpn3zI=.3a2356aa-87ec-49d9-83a4-6421700ae01c@github.com>

On Mon, 26 Aug 2024 13:49:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Thanks for this early bootstrap cleanup. The options cleanup is especially useful if we want to convert jli code gen to maual stack maps.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20714#pullrequestreview-2260740085

From coleenp at openjdk.org  Mon Aug 26 14:00:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 26 Aug 2024 14:00:09 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
Message-ID: <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>

On Sat, 24 Aug 2024 10:51:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.

MethodData does a lot of deallocations from metaspace because it's allocated racily.  It might be using Metaspace wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2310284365

From redestad at openjdk.org  Mon Aug 26 14:00:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 14:00:22 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622
 and JDK-8331932 [v2]
In-Reply-To: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
Message-ID: <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>

> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
> 
> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20713/files
  - new: https://git.openjdk.org/jdk/pull/20713/files/791a3c39..b87da2d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20713&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20713&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20713.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20713/head:pull/20713

PR: https://git.openjdk.org/jdk/pull/20713

From liach at openjdk.org  Mon Aug 26 14:00:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 14:00:22 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622
 and JDK-8331932 [v2]
In-Reply-To: <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
 <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
Message-ID: <NCWGfZmzMgwkVDzPFM4Avjkn5oR_i-z91sdmtnYoVzA=.df362e45-8dcc-45ef-b411-d54e51cb204a@github.com>

On Mon, 26 Aug 2024 13:57:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
>> 
>> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20713#pullrequestreview-2260759254

From redestad at openjdk.org  Mon Aug 26 14:09:18 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 14:09:18 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622
 and JDK-8331932 [v2]
In-Reply-To: <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
 <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
Message-ID: <nXILBqx3ydAOOjta_zWOi8wznEM_3Z8pPCAGZ1ztZBM=.10d8b25e-e8d7-4a30-891e-bda94ef65459@github.com>

On Mon, 26 Aug 2024 14:00:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
>> 
>> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final

@shipilev - mind testing this on your setup? I suspect there are other regressions not related to #14404 that has happened between 23-b13 and current RC, but it's an open question if I should leave JDK-8338897 open or close it with this PR. None of the code in Locale/BaseLocale gets executed a lot in the HelloStream tests, but a small dependency reduction like this might help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20713#issuecomment-2310305847

From pminborg at openjdk.org  Mon Aug 26 14:28:06 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 14:28:06 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <z36Rd17ZsMy6BYpR54PUVWTZuGEHYpqJQDSkS6rbA0Y=.14c91a11-6887-4741-93fc-40de74140ad3@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
 <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>
 <z36Rd17ZsMy6BYpR54PUVWTZuGEHYpqJQDSkS6rbA0Y=.14c91a11-6887-4741-93fc-40de74140ad3@github.com>
Message-ID: <zsHSE3lkpApXBCGzdiWJ2wF_pFcTvXAE3ek2qhYZ4Lk=.157480e7-1441-424a-86ab-6cbf4fbf159a@github.com>

On Mon, 26 Aug 2024 13:29:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 200:
>> 
>>> 198:             switch ((int) length) {
>>> 199:                 case 0 : checkReadOnly(false); checkValidState(); break; // Explicit tests
>>> 200:                 case 1 : set(JAVA_BYTE, 0, value); break;
>> 
>> beware using a switch, because if this code if is too big to be inlined (or we're unlucky) will die due to branch-mispredict in case the different "small fills" are unstable/unpredictable.
>> Having a test which feed different fill sizes per each iteration + counting branch misses, will reveal if the improvement is worthy even with such cases
>
> It is true, that this is a compromise where we give up inline space, code-cache space, and introduce added complexity against the prospect of better small-size performance. Depending on the workload, this may or may not pay off. In the (presumably common) case where we allocate/fill small segments of constant sizes, this is likely a win. Writing a dynamic performance test sounds like a good idea.

Here is a benchmark that fills segments of various random sizes:



@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)
@Fork(value = 3)
public class TestFill {

    private static final int SIZE = 16;
    private static final int[] INDICES = new Random(42).ints(0, 8)
            .limit(SIZE)
            .toArray();


    private MemorySegment[] segments;

    @Setup
    public void setup() {
        segments = IntStream.of(INDICES)
                .mapToObj(i -> MemorySegment.ofArray(new byte[i]))
                .toArray(MemorySegment[]::new);
    }

    @Benchmark
    public void heap_segment_fill() {
        for (int i = 0; i < SIZE; i++) {
            segments[i].fill((byte) 0);
        }
    }

}


This produces the following on my Mac M1:


Benchmark                   Mode  Cnt   Score   Error  Units
TestFill.heap_segment_fill  avgt   30  59.054 ? 3.723  ns/op


On average, an operation will take 59/16 = ~3 ns per operation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731331461

From asotona at openjdk.org  Mon Aug 26 14:32:07 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Aug 2024 14:32:07 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
 <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
Message-ID: <KskdrLZbz6H2w3gKkV8C3Boh1nBshzW2W9dSYkVIn9c=.1fcfb4b2-02b7-42e5-9bc0-9be2e6773f1a@github.com>

On Mon, 26 Aug 2024 13:52:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

It looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20714#pullrequestreview-2260837459

From redestad at openjdk.org  Mon Aug 26 14:32:07 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 14:32:07 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
 <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
Message-ID: <Qynb2HcWyTICpZgObL3mHjkvyfOvt6Ue7z5SfYcUQKQ=.3c9f1624-df21-4e9b-b62c-30e5b8c71ce7@github.com>

On Mon, 26 Aug 2024 13:52:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20714#issuecomment-2310357369

From redestad at openjdk.org  Mon Aug 26 14:32:08 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 14:32:08 GMT
Subject: Integrated: 8338979: Avoid bootstrapped switches in the classfile API
In-Reply-To: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
Message-ID: <uTKGtLqs7aleAariJ790ujWWe1l5JjA1K8LgMnq-Bms=.cccc4288-7ae0-489f-a7de-10c4c27c21ce@github.com>

On Mon, 26 Aug 2024 13:39:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.

This pull request has now been integrated.

Changeset: e63418ee
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e63418ee017def80689c88671e5d124b2d453fda
Stats:     30 lines in 2 files changed: 12 ins; 0 del; 18 mod

8338979: Avoid bootstrapped switches in the classfile API

Reviewed-by: liach, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20714

From jlahoda at openjdk.org  Mon Aug 26 14:41:08 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 26 Aug 2024 14:41:08 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them [v2]
In-Reply-To: <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
 <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
Message-ID: <BStBNxO3unpthZ7J1RultLWpF2i8Ci89WWpKZDlIboE=.bd04646b-0996-418b-a7b0-e9a99eadb8be@github.com>

On Sat, 24 Aug 2024 21:16:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
>> 
>> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Looks reasonable to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20693#pullrequestreview-2260865210

From pminborg at openjdk.org  Mon Aug 26 14:58:16 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 Aug 2024 14:58:16 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
 <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
Message-ID: <ORLiQ3rPFbVdYixvB6eJBr0H_guwWDDXcAesEBhb-JY=.439780f7-1c26-4f3d-896c-0ad465915743@github.com>

On Mon, 26 Aug 2024 13:52:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Noticed these on a few startup tests in code generating proxies. Desugaring switch expressions reduce risk of bootstrap circularity from any future changes to switch bootstrapping (which itself depends on the classfile API). It's also a tiny improvement to startup performance.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 86:

> 84:         var amo = attributeMapperOption;
> 85:         for (var o : options) {
> 86:             if (o instanceof StackMapsOption oo) {

Just out of curiosity, will this be slower than the switch statement?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20714#discussion_r1731374834

From liach at openjdk.org  Mon Aug 26 15:03:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 15:03:07 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <ORLiQ3rPFbVdYixvB6eJBr0H_guwWDDXcAesEBhb-JY=.439780f7-1c26-4f3d-896c-0ad465915743@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
 <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
 <ORLiQ3rPFbVdYixvB6eJBr0H_guwWDDXcAesEBhb-JY=.439780f7-1c26-4f3d-896c-0ad465915743@github.com>
Message-ID: <oS46Lg96U6c8ybhq-JJUTq6L-OQvXAIYfFDHMidEXlA=.c157400d-4026-46cb-95a8-cf0f5c507c87@github.com>

On Mon, 26 Aug 2024 14:54:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 86:
> 
>> 84:         var amo = attributeMapperOption;
>> 85:         for (var o : options) {
>> 86:             if (o instanceof StackMapsOption oo) {
> 
> Just out of curiosity, will this be slower than the switch statement?

It may after `SwitchBootstraps` is improved; but this code will be relied on by `SwitchBootstraps` to generate switches, so it won't be able to use pattern matching switches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20714#discussion_r1731382984

From michaelm at openjdk.org  Mon Aug 26 15:20:03 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 Aug 2024 15:20:03 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
Message-ID: <kQIR8QqMLUs5XaspTRHu37ZHZsLXoZUmMRBmhEl0RTU=.bf8a36bd-efc8-4c44-b85b-cee61816a034@github.com>

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert to old code comment
>  - use "JAR file" consistently in test's code comments
>  - rename closeLoaderIgnoreEx to closeQuietly

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 470:

> 468:                 continue;
> 469:             }
> 470:             if (loaderClassPathURLs != null) {

I'm missing something here. Why does the compiler not complain that `loaderClassPathURLs` might not be initialized, when it's accessed here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1731407899

From cushon at openjdk.org  Mon Aug 26 15:24:04 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 26 Aug 2024 15:24:04 GMT
Subject: RFR: 8328995: Launcher can't open jar files where the offset of
 the manifest is >4GB [v9]
In-Reply-To: <e-jbo8BLE-HfkyYs1_CRLhKV_fKoWTuSgm4TFThgFbM=.8603d046-120c-4e73-9bd4-a21c605789a3@github.com>
References: <bgsm1_QUL0EbnTCEdpLZq2KV5kJJ2vB-A_E6uBOFi3c=.f322218f-d68e-428b-b518-bb51dfc470b7@github.com>
 <e-jbo8BLE-HfkyYs1_CRLhKV_fKoWTuSgm4TFThgFbM=.8603d046-120c-4e73-9bd4-a21c605789a3@github.com>
Message-ID: <WtONf9jtVc00zHLkIDPe0zlf266SCAWKG4QCetzcBw8=.9c9108b1-5524-49eb-83b7-45953edc37d8@github.com>

On Fri, 19 Jul 2024 15:36:10 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a zip64 bug in the launcher that is prevent it from reading the manifest of jars where the 'relative offset of local header' field in the central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the offset is too large to be stored in the central directory it is stored in a 'Zip64 Extended Information Extra Field'.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use /* instead of /** comments

bridgekeeper please keep this open for now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18479#issuecomment-2310474453

From dfuchs at openjdk.org  Mon Aug 26 15:30:06 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 26 Aug 2024 15:30:06 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <kQIR8QqMLUs5XaspTRHu37ZHZsLXoZUmMRBmhEl0RTU=.bf8a36bd-efc8-4c44-b85b-cee61816a034@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
 <kQIR8QqMLUs5XaspTRHu37ZHZsLXoZUmMRBmhEl0RTU=.bf8a36bd-efc8-4c44-b85b-cee61816a034@github.com>
Message-ID: <isHW_YWuFaeVVoFUu3GCSxuGRyaiOFr7FqZ75pi4Kvg=.cedab666-dee0-4d26-babd-9c4eb4b0176f@github.com>

On Mon, 26 Aug 2024 15:17:18 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - revert to old code comment
>>  - use "JAR file" consistently in test's code comments
>>  - rename closeLoaderIgnoreEx to closeQuietly
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 470:
> 
>> 468:                 continue;
>> 469:             }
>> 470:             if (loaderClassPathURLs != null) {
> 
> I'm missing something here. Why does the compiler not complain that `loaderClassPathURLs` might not be initialized, when it's accessed here?

Because we would not reach here - since it's either assigned at line 447 or we continue at line 457, 468, or exit throwing an uncaught exception?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1731421835

From liach at openjdk.org  Mon Aug 26 15:38:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 15:38:04 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <n4jjZGZqaOsPK9V3KNwCvvQwzSLoyIOW6x1uC0xSzK4=.d20bc20e-42e6-4038-bafb-53f64b592e67@github.com>

On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

How about this:

/**
 * A legacy error for invalid input ZIP format.
 *
 * @deprecated
 * Use {@link ZipException} instead. Code catching this error from the JDK 8 and earlier should update
 * to catch {@code InternalError} instead.
 */

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2310500577

From duke at openjdk.org  Mon Aug 26 15:38:19 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 26 Aug 2024 15:38:19 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
Message-ID: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>

The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm

Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
-- | -- | -- | --
MathBench.tanhDouble | 70900 | 95618 | 1.35x

-------------

Commit messages:
 - Fix bug in NaN path
 - 8338694: x86_64 intrinsic for tanh using libm

Changes: https://git.openjdk.org/jdk/pull/20657/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338694
  Stats: 565 lines in 25 files changed: 556 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From redestad at openjdk.org  Mon Aug 26 15:39:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 15:39:09 GMT
Subject: RFR: 8338979: Avoid bootstrapped switches in the classfile API
 [v2]
In-Reply-To: <oS46Lg96U6c8ybhq-JJUTq6L-OQvXAIYfFDHMidEXlA=.c157400d-4026-46cb-95a8-cf0f5c507c87@github.com>
References: <SJ84gHY9UQ_CwoJJ-QVHk56-_wnn2k-QpcgVSYCBEnM=.331ec517-9933-492c-bcce-5bb144adf897@github.com>
 <WwSOl6Lnt6QBG0O8Sxi5rNi24xsxlgUvQu1-M3gCI5Y=.d6495180-cc40-4b95-876d-fc19eb92d711@github.com>
 <ORLiQ3rPFbVdYixvB6eJBr0H_guwWDDXcAesEBhb-JY=.439780f7-1c26-4f3d-896c-0ad465915743@github.com>
 <oS46Lg96U6c8ybhq-JJUTq6L-OQvXAIYfFDHMidEXlA=.c157400d-4026-46cb-95a8-cf0f5c507c87@github.com>
Message-ID: <dkAEe4B6mKEMcWVf91wmoHib28BsWYu_a4pRab0gvug=.d95d4709-6c7a-4a99-aad8-21a63cda2950@github.com>

On Mon, 26 Aug 2024 15:00:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java line 86:
>> 
>>> 84:         var amo = attributeMapperOption;
>>> 85:         for (var o : options) {
>>> 86:             if (o instanceof StackMapsOption oo) {
>> 
>> Just out of curiosity, will this be slower than the switch statement?
>
> It may after `SwitchBootstraps` is improved; but this code will be relied on by `SwitchBootstraps` to generate switches, so it won't be able to use pattern matching switches.

I don't think (throughput) performance matters here, based on patterns in JDK internal code. We use either `ClassFile.of()` which retrieves a pre-initialized singleton (creating which doesn't touch this method) or create a private static final like in `ProxyGenerator`:

    private static final ClassFile CF_CONTEXT =
            ClassFile.of(ClassFile.StackMapsOption.DROP_STACK_MAPS);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20714#discussion_r1731433796

From michaelm at openjdk.org  Mon Aug 26 15:40:04 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 Aug 2024 15:40:04 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <isHW_YWuFaeVVoFUu3GCSxuGRyaiOFr7FqZ75pi4Kvg=.cedab666-dee0-4d26-babd-9c4eb4b0176f@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
 <kQIR8QqMLUs5XaspTRHu37ZHZsLXoZUmMRBmhEl0RTU=.bf8a36bd-efc8-4c44-b85b-cee61816a034@github.com>
 <isHW_YWuFaeVVoFUu3GCSxuGRyaiOFr7FqZ75pi4Kvg=.cedab666-dee0-4d26-babd-9c4eb4b0176f@github.com>
Message-ID: <sW7-QPBBAx2wDWcn56-NT3-Bw0KJrUNcq07k5GUpKNo=.d6bac870-7f57-4caf-81b7-bcd8d90174f2@github.com>

On Mon, 26 Aug 2024 15:27:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 470:
>> 
>>> 468:                 continue;
>>> 469:             }
>>> 470:             if (loaderClassPathURLs != null) {
>> 
>> I'm missing something here. Why does the compiler not complain that `loaderClassPathURLs` might not be initialized, when it's accessed here?
>
> Because we would not reach here - since it's either assigned at line 447 or we continue at line 457, 468, or exit throwing an uncaught exception?

Is the if statement at line 470 redundant then? Presumably the code can reach here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1731430476

From jpai at openjdk.org  Mon Aug 26 15:40:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Aug 2024 15:40:04 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <sW7-QPBBAx2wDWcn56-NT3-Bw0KJrUNcq07k5GUpKNo=.d6bac870-7f57-4caf-81b7-bcd8d90174f2@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
 <kQIR8QqMLUs5XaspTRHu37ZHZsLXoZUmMRBmhEl0RTU=.bf8a36bd-efc8-4c44-b85b-cee61816a034@github.com>
 <isHW_YWuFaeVVoFUu3GCSxuGRyaiOFr7FqZ75pi4Kvg=.cedab666-dee0-4d26-babd-9c4eb4b0176f@github.com>
 <sW7-QPBBAx2wDWcn56-NT3-Bw0KJrUNcq07k5GUpKNo=.d6bac870-7f57-4caf-81b7-bcd8d90174f2@github.com>
Message-ID: <Iuq5P2Z3a52o1AuG5fGnQYHIG2l1bjBUbDRfJZxKRsI=.d6ccaecb-de43-49ec-82d8-0484a6fe703b@github.com>

On Mon, 26 Aug 2024 15:33:58 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Because we would not reach here - since it's either assigned at line 447 or we continue at line 457, 468, or exit throwing an uncaught exception?
>
> Is the if statement at line 470 redundant then? Presumably the code can reach here.

Hello Michael,
> Is the if statement at line 470 redundant then?

`Loader.getClassPath()` can return null (and it does for some implementations of Loader). So the null check would still be needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1731433502

From darcy at openjdk.org  Mon Aug 26 15:50:03 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Aug 2024 15:50:03 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <WDToV3EsXlAGIbz6og4wnktMZIQZ7GxL8IGJvTM8EJA=.5df48925-fca6-4d7f-b241-60d870e355d6@github.com>

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

This PR doesn't include any additional tests. It is often appropriate to add more regression testing when introducing a new implementation of a method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2310523202

From michaelm at openjdk.org  Mon Aug 26 15:51:02 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 Aug 2024 15:51:02 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <Iuq5P2Z3a52o1AuG5fGnQYHIG2l1bjBUbDRfJZxKRsI=.d6ccaecb-de43-49ec-82d8-0484a6fe703b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
 <kQIR8QqMLUs5XaspTRHu37ZHZsLXoZUmMRBmhEl0RTU=.bf8a36bd-efc8-4c44-b85b-cee61816a034@github.com>
 <isHW_YWuFaeVVoFUu3GCSxuGRyaiOFr7FqZ75pi4Kvg=.cedab666-dee0-4d26-babd-9c4eb4b0176f@github.com>
 <sW7-QPBBAx2wDWcn56-NT3-Bw0KJrUNcq07k5GUpKNo=.d6bac870-7f57-4caf-81b7-bcd8d90174f2@github.com>
 <Iuq5P2Z3a52o1AuG5fGnQYHIG2l1bjBUbDRfJZxKRsI=.d6ccaecb-de43-49ec-82d8-0484a6fe703b@github.com>
Message-ID: <VjGWf5E4HCYGpgCxN36KZVJNPV2jCDqJRtpy4m8Eqpo=.37bbbe17-b163-4d8c-9811-214d381acc57@github.com>

On Mon, 26 Aug 2024 15:36:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Is the if statement at line 470 redundant then? Presumably the code can reach here.
>
> Hello Michael,
>> Is the if statement at line 470 redundant then?
> 
> `Loader.getClassPath()` can return null (and it does for some implementations of Loader). So the null check would still be needed.

What if `getLoader(url)` throws an exception so `Loader.getClassPath()` is not called? Okay, I see Daniel's point, that in that case, the code is not reached.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1731446869

From jpai at openjdk.org  Mon Aug 26 15:58:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Aug 2024 15:58:04 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <fnjW4VmORyCWuxXw_qVVAetQQPFd8swSAFzEmUO4AHY=.a866a36d-b2eb-4bfb-b642-43176cd2f679@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
 <fnjW4VmORyCWuxXw_qVVAetQQPFd8swSAFzEmUO4AHY=.a866a36d-b2eb-4bfb-b642-43176cd2f679@github.com>
Message-ID: <ZPC49YSKWDOkTMyry2U2e4BP2VbvKQYDFk0pSDYa-k0=.44345071-759a-4dfe-a512-36134511c615@github.com>

On Mon, 26 Aug 2024 12:24:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> If no objections are raised by tomorrow morning I'll proceed with integration

I've run this PR against latest mainline in our CI for tier1, tier2 and tier3 and there were no failures. So yes, I think you can go ahead with the integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2310538487

From redestad at openjdk.org  Mon Aug 26 16:01:09 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 16:01:09 GMT
Subject: RFR: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them [v2]
In-Reply-To: <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
 <lMW2iEmHHa0AZxndUrOaZH8FJoH4SqrZXmi-21GBcw4=.46fc8462-1aea-45bc-b950-4921e978a005@github.com>
Message-ID: <8OkiNQHWbHISh-JCZyKjDdcqPd_siQm5T4vFxUJkaLA=.d09be70d-2780-4838-b765-3f3abcbf15af@github.com>

On Sat, 24 Aug 2024 21:16:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
>> 
>> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.
>
> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20693#issuecomment-2310541373

From redestad at openjdk.org  Mon Aug 26 16:01:10 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 16:01:10 GMT
Subject: Integrated: 8338906: Avoid passing EnumDescs and extra classes to type
 switch methods that don't use them
In-Reply-To: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
References: <zT1gtrngv02hdoiMWWPKorSUZeacVcoLBEMZUcarlSs=.2572f771-77ee-4423-83e3-ca9dcb4a3398@github.com>
Message-ID: <L_xZ_oxERKBUyKoAMUy4kQMtl7Szm9aYFDpT1M3XOmU=.e6c6def3-7058-460a-a371-3153c3760833@github.com>

On Fri, 23 Aug 2024 12:34:17 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are only passed into bootstraps when needed. Benchmarking shows that in many cases these are not needed, and avoiding passing them (via binding in the lists via `MethodHandle::insertArguments`) avoids some auxiliary MH combinator generation during bootstrap. 
> 
> Additional cleanups and refactoring further reduce bootstrap overhead and number of classes loaded.

This pull request has now been integrated.

Changeset: 3f00da84
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f00da84b3e6fb001e7d56acb198292b28d40c8b
Stats:     95 lines in 1 file changed: 44 ins; 10 del; 41 mod

8338906: Avoid passing EnumDescs and extra classes to type switch methods that don't use them

Reviewed-by: liach, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/20693

From michaelm at openjdk.org  Mon Aug 26 16:03:04 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 26 Aug 2024 16:03:04 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
Message-ID: <73wv3qfqY1abJdDSOty4RIuvjBJ6LO1QYj9bBjVa5H4=.18b4fe2a-e047-4882-b3a1-0e8ce005b981@github.com>

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert to old code comment
>  - use "JAR file" consistently in test's code comments
>  - rename closeLoaderIgnoreEx to closeQuietly

LGTM

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20691#pullrequestreview-2261044090

From liach at openjdk.org  Mon Aug 26 19:05:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 19:05:10 GMT
Subject: RFR: 8334714: Class-File API leaves preview [v2]
In-Reply-To: <v6SYBNZ5TY8V6VXo4jaz5z5YWndy-8T7arwHOYTA23c=.af3a2596-62cb-4f76-a1c0-cc975e943351@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <tUuGZJ-ew3yGJQegl5cMRNAW2pNIt58giQFClim8-_A=.91f26752-6182-418b-a589-c71547320a74@github.com>
 <UkrRpUjfQwP22i52rmaQTTQ0d5P2TMY8m5C4Qi37zas=.ea566484-00d8-48f8-b1f5-673656cc861c@github.com>
 <7827jz-pO-ruBBF5FI8AoXRez_yWrFt25Cr6tMgmUDM=.88e10cca-c90c-4a93-8a3a-503491413411@github.com>
 <v6SYBNZ5TY8V6VXo4jaz5z5YWndy-8T7arwHOYTA23c=.af3a2596-62cb-4f76-a1c0-cc975e943351@github.com>
Message-ID: <9nKJtghqH1bWDla1-rp0Jm02gsruqWloECon0HFUp1I=.06f67fe2-7459-49f3-baaf-41de31488eb6@github.com>

On Sat, 24 Aug 2024 13:53:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> If Hotspot now parses these files incorrectly, it might be worth to just throw UnsupportedClassVersionError for oak class files?

I was informed in offline discussion that this is unlikely to be changed and this change is unlikely to be backported unless for security purposes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2310872682

From duke at openjdk.org  Mon Aug 26 20:19:03 2024
From: duke at openjdk.org (duke)
Date: Mon, 26 Aug 2024 20:19:03 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc [v2]
In-Reply-To: <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
Message-ID: <yHVG2nnhWuQOae5OtYrMVhkC5YhlC8Jv2NdGMs3Q6KI=.4884545c-9030-41af-9670-972b6ed00ade@github.com>

On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use MethodTypeDescImpl.ofValidated

@wenshao 
Your change (at version 727ec217981936384d5d55f5df51b118a615992c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20704#issuecomment-2311008092

From liach at openjdk.org  Mon Aug 26 20:29:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Aug 2024 20:29:07 GMT
Subject: RFR: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc [v2]
In-Reply-To: <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
 <nAc6he5fYbHugu345CTYsJfSZKG1k9u9DK3hCxq3Xo4=.817fd4e7-2e15-4f31-803d-4d5f4766b615@github.com>
Message-ID: <uyGGqHYGUX5DrKPFfXaWJ1JXTYjedyZd--13dj4Y3CU=.de5d2bb6-4ffa-4c84-b9ed-5e7c485e1499@github.com>

On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use MethodTypeDescImpl.ofValidated

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20704#issuecomment-2311022732

From duke at openjdk.org  Mon Aug 26 20:29:08 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 26 Aug 2024 20:29:08 GMT
Subject: Integrated: 8338936: StringConcatFactory optimize the construction of
 MethodType and MethodTypeDesc
In-Reply-To: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
References: <MyRomfFiff0HXcdTTwz9BfCweg8-_7743Qp3ZURu3Lw=.476f4e3b-66c1-47a4-af54-c2731b3a3ae2@github.com>
Message-ID: <c3OXqmiBY6e_Rq_moEMDN4jTWKHJcxSTkDr1-n1pX-U=.210238c7-0f00-46a2-8e79-6c698f77e138@github.com>

On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> optimize the construction of MethodType and MethodTypeDesc to reduce memory allocate

This pull request has now been integrated.

Changeset: 5ecbecfb
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ecbecfbcac681e9e6750be37ca4bc2591db21e6
Stats:     61 lines in 1 file changed: 14 ins; 9 del; 38 mod

8338936: StringConcatFactory optimize the construction of MethodType and MethodTypeDesc

Reviewed-by: redestad, liach

-------------

PR: https://git.openjdk.org/jdk/pull/20704

From duke at openjdk.org  Mon Aug 26 20:51:35 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 26 Aug 2024 20:51:35 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v4]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <1zGW--8KhsTjLWnq8-rnqVvkqGaeQpnVHadyvLewaUU=.cc4f7ca6-ab0c-4d40-b536-546b686d015c@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - optimize for CompactStrings is off
 - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
 - add control flag `reuseThreshold`
 - Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
   
   This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.
 - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
 - revert code style
 - from suggest
 - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - support staticConcat

-------------

Changes: https://git.openjdk.org/jdk/pull/20675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=03
  Stats: 133 lines in 3 files changed: 82 ins; 2 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From duke at openjdk.org  Mon Aug 26 20:59:04 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 26 Aug 2024 20:59:04 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v2]
In-Reply-To: <D5wXfLWl_ez8iaoqAlvkKPxZ10qpYjyYPjrjvUIJJdI=.c6cb404b-2ce9-45a2-ac03-a101ba14b3aa@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <c0FM40vtZhOhgYBsCwzFz_-hlxkDJDyfDO0z3BYe3gw=.0cec75d6-a0ba-4cc4-8285-3d0cd8d0ae98@github.com>
 <XCJkzVahwkqap4OcV_LfQc9-z-AWzME6-bkDS_cGxO4=.a93a266b-5dbc-4333-8981-e566c9f67f5a@github.com>
 <D5wXfLWl_ez8iaoqAlvkKPxZ10qpYjyYPjrjvUIJJdI=.c6cb404b-2ce9-45a2-ac03-a101ba14b3aa@github.com>
Message-ID: <qtPEoYkoVYEkn25qYlEY-A-5tjURv1Zk6PGLH0LRPGs=.96fb7ff0-3bf6-43ce-9600-f4d10741585d@github.com>

On Sun, 25 Aug 2024 13:10:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > If the number of parameters is greater than 2, the probability of reuse may not be high. Using hard-coded constants can avoid the use of forceinline.
> 
> I think this entirely depends on the application. Too low a threshold and many applications will see an increase in number of generated classes. And perhaps we shouldn't assume _any_ high arity concatenations are performance sensitive enough that generating a class-per-call-site is ever a reasonable default. A good tunable for some applications, perhaps.
> 
> > From this PR, adding hard-coded constants only requires a small change, which may be a good solution.
> 
> It's good that layering this on top of the existing strategy is relatively straightforward, yes.

Support hardcoded constants so that we can use a smaller inlineThreshold, maybe the default values ??of reuseThreshold and inlineThreshold can be set to 8.

I also added optimizations for CompactString, when CompactString is turned off, no coder method is generated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311080376

From duke at openjdk.org  Mon Aug 26 21:23:04 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 26 Aug 2024 21:23:04 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v4]
In-Reply-To: <1zGW--8KhsTjLWnq8-rnqVvkqGaeQpnVHadyvLewaUU=.cc4f7ca6-ab0c-4d40-b536-546b686d015c@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <1zGW--8KhsTjLWnq8-rnqVvkqGaeQpnVHadyvLewaUU=.cc4f7ca6-ab0c-4d40-b536-546b686d015c@github.com>
Message-ID: <xmJ4E5zDoi_2Lrwzt6aMsEzidmidXvn_taXK02fDPnE=.7cfa4f09-38cc-4632-bd3d-423178de9cf6@github.com>

On Mon, 26 Aug 2024 20:51:35 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - optimize for CompactStrings is off
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - add control flag `reuseThreshold`
>  - Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
>    
>    This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.
>  - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
>  - revert code style
>  - from suggest
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - support staticConcat

Below are the performance numbers I ran on a MacBook M1 Pro. The numbers show that when constants are hard-coded, performance is good even without forceinline. The default values ??of reuseThreshold and inlineThreshold can even be aggressively set to 4.


# fetch current version
git checkout a9fa264afd9fa625ef29357a7ca8559ce9c5fea4

# default non-args
make test TEST="micro:java.lang.StringConcat.concat6String"

# reuseThreshold=4 inlineThreshold=4
make test TEST="micro:java.lang.StringConcat.concat6String" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.reuseThreshold=4 -Djava.lang.invoke.StringConcat.inlineThreshold=4"

# reuseThreshold=8 inlineThreshold=4
make test TEST="micro:java.lang.StringConcat.concat6String" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.reuseThreshold=8 -Djava.lang.invoke.StringConcat.inlineThreshold=4"



# default non-args
Benchmark                   (intValue)  Mode  Cnt   Score   Error  Units
StringConcat.concat6String        4711  avgt   15  19.329 ? 0.476  ns/op

# reuseThreshold=4 inlineThreshold=4
Benchmark                   (intValue)  Mode  Cnt   Score   Error  Units
StringConcat.concat6String        4711  avgt   15  19.256 ? 0.296  ns/op

# reuseThreshold=8 inlineThreshold=4
Benchmark                   (intValue)  Mode  Cnt   Score   Error  Units
StringConcat.concat6String        4711  avgt   15  24.714 ? 0.176  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311118543

From redestad at openjdk.org  Mon Aug 26 21:38:06 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 21:38:06 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v4]
In-Reply-To: <1zGW--8KhsTjLWnq8-rnqVvkqGaeQpnVHadyvLewaUU=.cc4f7ca6-ab0c-4d40-b536-546b686d015c@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <1zGW--8KhsTjLWnq8-rnqVvkqGaeQpnVHadyvLewaUU=.cc4f7ca6-ab0c-4d40-b536-546b686d015c@github.com>
Message-ID: <N_LB40r4568qQLgehCeA-ixnO4Yyc4FxtVTrJLodcvI=.e6716deb-a050-40b1-bd25-95c78cdf6de6@github.com>

On Mon, 26 Aug 2024 20:51:35 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - optimize for CompactStrings is off
>  - Merge remote-tracking branch 'upstream/master' into optim_concat_factory_202408
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>  - add control flag `reuseThreshold`
>  - Revert "Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation"
>    
>    This reverts commit 3bed7290f5cb987e86407f698fb0598f19d65628.
>  - Optimize the construction of MethodType and MethodTypeDesc to reduce memory allocation
>  - revert code style
>  - from suggest
>  - Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - support staticConcat

I'm not too keen on `reuseThreshold` (perhaps `cacheThreshold`?) being enabled by default until we can get some tuning data from real world usage here. Does it harm applications by increasing number of generated classes by a large amount? Does the improved performance at each call-site matter, or is it more important to share common concat classes to reduce startup/warmup overheads? I'd be more at ease if we initially added this feature as an opt-in (`reuseThreshold` set to some value above 100) and then do a tuning pass at a future time.

Disabling the generation of the `coder` methods if running with `-XX:-CompactStrings` is probably fine. Perhaps this should be split out to a separate PR. It adds some concerns regarding code pre-generation (might be best to always use the coder-checking `+CompactStrings` form when pre-generating to avoid bugs)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311141871

From mcimadamore at openjdk.org  Mon Aug 26 21:41:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Aug 2024 21:41:02 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <zsHSE3lkpApXBCGzdiWJ2wF_pFcTvXAE3ek2qhYZ4Lk=.157480e7-1441-424a-86ab-6cbf4fbf159a@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
 <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>
 <z36Rd17ZsMy6BYpR54PUVWTZuGEHYpqJQDSkS6rbA0Y=.14c91a11-6887-4741-93fc-40de74140ad3@github.com>
 <zsHSE3lkpApXBCGzdiWJ2wF_pFcTvXAE3ek2qhYZ4Lk=.157480e7-1441-424a-86ab-6cbf4fbf159a@github.com>
Message-ID: <kVd-TgVaiECIXjnVb3uqm4PM3QrYht_Vp8jF4Lp5MQ8=.96de5719-add5-4339-bdad-40a08c410ab2@github.com>

On Mon, 26 Aug 2024 14:25:31 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> It is true, that this is a compromise where we give up inline space, code-cache space, and introduce added complexity against the prospect of better small-size performance. Depending on the workload, this may or may not pay off. In the (presumably common) case where we allocate/fill small segments of constant sizes, this is likely a win. Writing a dynamic performance test sounds like a good idea.
>
> Here is a benchmark that fills segments of various random sizes:
> 
> 
> 
> @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)
> @Fork(value = 3)
> public class TestFill {
> 
>     private static final int SIZE = 16;
>     private static final int[] INDICES = new Random(42).ints(0, 8)
>             .limit(SIZE)
>             .toArray();
> 
> 
>     private MemorySegment[] segments;
> 
>     @Setup
>     public void setup() {
>         segments = IntStream.of(INDICES)
>                 .mapToObj(i -> MemorySegment.ofArray(new byte[i]))
>                 .toArray(MemorySegment[]::new);
>     }
> 
>     @Benchmark
>     public void heap_segment_fill() {
>         for (int i = 0; i < SIZE; i++) {
>             segments[i].fill((byte) 0);
>         }
>     }
> 
> }
> 
> 
> This produces the following on my Mac M1:
> 
> 
> Benchmark                   Mode  Cnt   Score   Error  Units
> TestFill.heap_segment_fill  avgt   30  59.054 ? 3.723  ns/op
> 
> 
> On average, an operation will take 59/16 = ~3 ns per operation (including looping).
> 
> A test with the same size for every benchmark looks like this on my machine:
> 
> 
> Benchmark                   (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
> TestFill.heap_segment_fill            0  avgt   30  1.112 ? 0.027  ns/op
> TestFill.heap_segment_fill            1  avgt   30  1.602 ? 0.060  ns/op
> TestFill.heap_segment_fill            2  avgt   30  1.583 ? 0.004  ns/op
> TestFill.heap_segment_fill            3  avgt   30  1.909 ? 0.055  ns/op
> TestFill.heap_segment_fill            4  avgt   30  1.605 ? 0.059  ns/op
> TestFill.heap_segment_fill            5  avgt   30  1.900 ? 0.064  ns/op
> TestFill.heap_segment_fill            6  avgt   30  1.891 ? 0.038  ns/op
> TestFill.heap_segment_fill            7  avgt   30  2.237 ? 0.091  ns/op

As discussed offline, can't we use a stable array of functions or something like that which can be populated lazily? That way you can access the function you want in a single array access, and we could put all these helper methods somewhere else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1731855496

From darcy at openjdk.org  Mon Aug 26 22:16:04 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Aug 2024 22:16:04 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <3hk6EiDY3Qxq_sjSBoL7SBsk_5_FsuRa7iZ0caxSs8s=.6db958ed-8f74-49d1-b949-a7da94357592@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

Some general impressions of the API change in the `java.lang` classes. I don't think the change as-is, especially the new constant fields, are a great fit for the current API and I think those constant would look worse in a future where there was an "UnsignedInt" value class, so similar fuller platform support.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20507#issuecomment-2311195882

From duke at openjdk.org  Mon Aug 26 22:25:49 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 26 Aug 2024 22:25:49 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v5]
In-Reply-To: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
Message-ID: <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>

> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
> 
> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - reuseThreshold -> cacheThreshold
 - Revert "optimize for CompactStrings is off"
   
   This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20675/files
  - new: https://git.openjdk.org/jdk/pull/20675/files/a9fa264a..871f67fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20675&range=03-04

  Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20675/head:pull/20675

PR: https://git.openjdk.org/jdk/pull/20675

From duke at openjdk.org  Mon Aug 26 22:32:03 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 26 Aug 2024 22:32:03 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v5]
In-Reply-To: <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
Message-ID: <92Evpzfyy-7akPXhMfWmr2Y3UypsJEX4UYNaIXCE4oA=.3c372cd6-fb06-4892-af7a-14a870dc1545@github.com>

On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - reuseThreshold -> cacheThreshold
>  - Revert "optimize for CompactStrings is off"
>    
>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.

reuseThreshold has been changed to cacheThreshold, which is consistent with inlineThreshold, so that the performance of all scenarios is good when the default parameters are used.

The current value of 16 may be appropriate, because when the number of parameters reaches 16, the probability of reuse is very low. At this time, caching is an additional overhead, and it takes longer to reach peak performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311217448

From psandoz at openjdk.org  Mon Aug 26 22:44:03 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 26 Aug 2024 22:44:03 GMT
Subject: RFR: 8338728: Misc issues in memory layout javadoc [v2]
In-Reply-To: <CqqWAiXYveYtkmMYnoqD5ux-oUHni7bhLlI_fCl6eLY=.65a0d4e1-abc3-4c06-9c86-4e686d6ff85b@github.com>
References: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>
 <CqqWAiXYveYtkmMYnoqD5ux-oUHni7bhLlI_fCl6eLY=.65a0d4e1-abc3-4c06-9c86-4e686d6ff85b@github.com>
Message-ID: <D48b58KJyd0widD-AJyGOMfFmhRb1EYK3xmz78ugQB0=.32662388-6a98-44e5-a18a-629294deaaa8@github.com>

On Wed, 21 Aug 2024 13:24:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes two minor issues in the `MemoryLayout` javadoc:
>> * the section describing dereference path talks about `P` and `P'` but then only uses `P` in the code;
>> * the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is wrong, as the division returns a negative number for F < 0, which is incorrect
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Clarify javadoc for var handles with dereference path elements
>   * Add test where dereference path element is last element in path

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20659#pullrequestreview-2261775558

From psandoz at openjdk.org  Mon Aug 26 22:52:02 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 26 Aug 2024 22:52:02 GMT
Subject: RFR: 8338731: MemoryLayout::offsetHandle can return a negative
 offset
In-Reply-To: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
References: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
Message-ID: <VLI0RsMqEBZzwxWMgW-uz6Z1RpjR-X_g8Meja798EgU=.b2d69933-618e-4547-b022-572b3e0e8417@github.com>

On Wed, 21 Aug 2024 13:26:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.
> 
> In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.
> 
> The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20662#pullrequestreview-2261784414

From sviswanathan at openjdk.org  Mon Aug 26 23:15:11 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 26 Aug 2024 23:15:11 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <T8PSaIWEe2ywQsBrn1BSoirmIGnIe7jBP_XSOkjWgLQ=.48b2900b-d326-47b1-a73e-f2352e73140f@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/x86/assembler_x86.cpp line 3454:

> 3452: 
> 3453: void Assembler::evmovdquw(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
> 3454:   assert(VM_Version::supports_avx512vlbw(), "");

vl not needed for 512 bit.

src/hotspot/cpu/x86/assembler_x86.cpp line 4583:

> 4581: void Assembler::evpcmpgtb(KRegister kdst, XMMRegister nds, Address src, int vector_len) {
> 4582:   assert(VM_Version::supports_avx512vlbw(), "");
> 4583:   assert(vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl(), "");

The check for supports_avx512vlbw() at previous line in this function need to be changed to supports_avx512bw(). 
If it helps, the vl check is already happening in vex_prefix() if we use the higher bank registers for length < 512 bit.

src/hotspot/cpu/x86/assembler_x86.cpp line 4596:

> 4594: void Assembler::evpcmpgtb(KRegister kdst, KRegister mask, XMMRegister nds, Address src, int vector_len) {
> 4595:   assert(VM_Version::supports_avx512vlbw(), "");
> 4596:   assert(vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl(), "");

The check for supports_avx512vlbw() at previous line in this function need to be changed to supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 4611:

> 4609: void Assembler::evpcmpub(KRegister kdst, XMMRegister nds, XMMRegister src, ComparisonPredicate vcc, int vector_len) {
> 4610:   assert(vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl(), "");
> 4611:   assert(VM_Version::supports_avx512vlbw(), "");

I think you meant this to be supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 4620:

> 4618: void Assembler::evpcmpuw(KRegister kdst, XMMRegister nds, XMMRegister src, ComparisonPredicate vcc, int vector_len) {
> 4619:   assert(vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl(), "");
> 4620:   assert(VM_Version::supports_avx512vlbw(), "");

The check for supports_avx512vlbw() in this function need to be changed to supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 4645:

> 4643: void Assembler::evpcmpuw(KRegister kdst, XMMRegister nds, Address src, ComparisonPredicate vcc, int vector_len) {
> 4644:   assert(VM_Version::supports_avx512vlbw(), "");
> 4645:   assert(vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl(), "");

The check for supports_avx512vlbw() at previous line in this function need to be changed to supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 4672:

> 4670: void Assembler::evpcmpeqb(KRegister kdst, KRegister mask, XMMRegister nds, Address src, int vector_len) {
> 4671:   assert(VM_Version::supports_avx512vlbw(), "");
> 4672:   assert(vector_len == Assembler::AVX_512bit || VM_Version::supports_avx512vl(), "");

The check for supports_avx512vlbw() at previous line in this function need to be changed to supports_avx512bw().

src/hotspot/cpu/x86/assembler_x86.cpp line 8191:

> 8189: void Assembler::vpminub(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8190:   assert(UseAVX > 0 && (vector_len == Assembler::AVX_512bit || (!needs_evex(dst, nds, src) || VM_Version::supports_avx512vl())), "");
> 8191:   assert(!needs_evex(dst, nds, src) || VM_Version::supports_avx512bw(), "");

It will be good to keep the assert similar to vpaddsb for new vmin/vmax instructions.

src/hotspot/cpu/x86/assembler_x86.cpp line 8311:

> 8309: }
> 8310: 
> 8311: void Assembler::evpminud(XMMRegister dst, KRegister mask, XMMRegister nds, Address src, bool merge, int vector_len) {

assert(VM_Version::supports_evex(), "") check missing.

src/hotspot/cpu/x86/assembler_x86.cpp line 8340:

> 8338: 
> 8339: void Assembler::evpminuq(XMMRegister dst, KRegister mask, XMMRegister nds, Address src, bool merge, int vector_len) {
> 8340:   assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), "");

assert(VM_Version::supports_evex(), "") check missing.

src/hotspot/cpu/x86/assembler_x86.cpp line 8402:

> 8400: void Assembler::vpmaxuw(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8401:   assert(vector_len == AVX_128bit ? VM_Version::supports_avx() :
> 8402:         (vector_len == AVX_256bit ? VM_Version::supports_avx2() : VM_Version::supports_avx512bw()), "");

Why support_avx() check here only and not in other newly added  v* integral instructions? For avx1 platforms, integral vector width supported is only 128bit.

src/hotspot/cpu/x86/assembler_x86.cpp line 8478:

> 8476: 
> 8477: void Assembler::evpmaxud(XMMRegister dst, KRegister mask, XMMRegister nds, Address src, bool merge, int vector_len) {
> 8478:   assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), "");

assert(VM_Version::supports_evex(), "") is  missing.

src/hotspot/cpu/x86/assembler_x86.cpp line 8506:

> 8504: 
> 8505: void Assembler::evpmaxuq(XMMRegister dst, KRegister mask, XMMRegister nds, Address src, bool merge, int vector_len) {
> 8506:   assert(vector_len == AVX_512bit || VM_Version::supports_avx512vl(), "");

assert(VM_Version::supports_evex(), "") is missing.

src/hotspot/cpu/x86/assembler_x86.cpp line 10229:

> 10227:   InstructionMark im(this);
> 10228:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10229:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10256:

> 10254:   InstructionMark im(this);
> 10255:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10256:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10283:

> 10281:   InstructionMark im(this);
> 10282:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10283:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10310:

> 10308:   InstructionMark im(this);
> 10309:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10310:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10337:

> 10335:   InstructionMark im(this);
> 10336:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10337:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10364:

> 10362:   InstructionMark im(this);
> 10363:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10364:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10391:

> 10389:   InstructionMark im(this);
> 10390:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10391:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 10419:

> 10417:   InstructionMark im(this);
> 10418:   assert(VM_Version::supports_avx512bw() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");
> 10419:   InstructionAttr attributes(vector_len, /* vex_w */ true,/* legacy_mode */ false, /* no_mask_reg */ false,/* uses_vl */ true);

vex_w could be false here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731912227
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731608860
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731609177
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731917735
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731612730
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731726012
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731726337
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731748671
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731769490
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731771330
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731823750
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731870793
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731870288
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731888852
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731889468
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731890265
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731909994
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731910246
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731910516
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731910755
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1731911129

From redestad at openjdk.org  Mon Aug 26 23:28:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 26 Aug 2024 23:28:03 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v5]
In-Reply-To: <92Evpzfyy-7akPXhMfWmr2Y3UypsJEX4UYNaIXCE4oA=.3c372cd6-fb06-4892-af7a-14a870dc1545@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
 <92Evpzfyy-7akPXhMfWmr2Y3UypsJEX4UYNaIXCE4oA=.3c372cd6-fb06-4892-af7a-14a870dc1545@github.com>
Message-ID: <7dvDXCNF2cr47qAwgXR0QhtoYHtaXm2M_26IIbqPZsg=.9abe7cc9-2489-4637-a857-43a384680528@github.com>

On Mon, 26 Aug 2024 22:29:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> At this time, caching is an additional overhead, and it takes longer to reach peak performance.

Can you elaborate on this line of thinking?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311280698

From duke at openjdk.org  Tue Aug 27 00:00:04 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 00:00:04 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v5]
In-Reply-To: <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
Message-ID: <MzzH1tydFtKCWlqcSPV5wDqMLOKO1DhXS9m0bQ6H7P0=.3c21f178-5fe0-477c-9f36-471109698707@github.com>

On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - reuseThreshold -> cacheThreshold
>  - Revert "optimize for CompactStrings is off"
>    
>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.

Below are the performance numbers of different JVM startup options running on MacBook M1 Pro.

`reuseThreshold=4 inlineThreshold=4` performs better in the first round of warm-up.


make test TEST="micro:java.lang.StringConcat.concat6String" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.reuseThreshold=8 -Djava.lang.invoke.StringConcat.inlineThreshold=8"

# Run progress: 0.00% complete, ETA 00:00:30
# Fork: 1 of 3
# Warmup Iteration   1: 21.933 ns/op
# Warmup Iteration   2: 21.426 ns/op
# Warmup Iteration   3: 19.380 ns/op
# Warmup Iteration   4: 19.363 ns/op
# Warmup Iteration   5: 20.380 ns/op
# Warmup Iteration   6: 20.261 ns/op
# Warmup Iteration   7: 19.596 ns/op
# Warmup Iteration   8: 20.263 ns/op
# Warmup Iteration   9: 18.877 ns/op
# Warmup Iteration  10: 19.192 ns/op
Iteration   1: 20.233 ns/op
Iteration   2: 18.969 ns/op
Iteration   3: 19.928 ns/op
Iteration   4: 19.917 ns/op
Iteration   5: 18.987 ns/op

# Run progress: 33.33% complete, ETA 00:00:20
# Fork: 2 of 3
# Warmup Iteration   1: 23.175 ns/op
# Warmup Iteration   2: 20.118 ns/op
# Warmup Iteration   3: 20.792 ns/op
# Warmup Iteration   4: 21.484 ns/op
# Warmup Iteration   5: 21.586 ns/op
# Warmup Iteration   6: 20.314 ns/op
# Warmup Iteration   7: 20.115 ns/op
# Warmup Iteration   8: 21.828 ns/op
# Warmup Iteration   9: 21.962 ns/op
# Warmup Iteration  10: 20.389 ns/op
Iteration   1: 20.517 ns/op
Iteration   2: 20.657 ns/op
Iteration   3: 20.371 ns/op
Iteration   4: 20.880 ns/op
Iteration   5: 20.377 ns/op

# Run progress: 66.67% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 23.821 ns/op
# Warmup Iteration   2: 20.281 ns/op
# Warmup Iteration   3: 21.580 ns/op
# Warmup Iteration   4: 20.035 ns/op
# Warmup Iteration   5: 19.159 ns/op
# Warmup Iteration   6: 19.914 ns/op
# Warmup Iteration   7: 18.688 ns/op
# Warmup Iteration   8: 18.882 ns/op
# Warmup Iteration   9: 19.639 ns/op
# Warmup Iteration  10: 18.985 ns/op
Iteration   1: 19.548 ns/op
Iteration   2: 19.060 ns/op
Iteration   3: 19.083 ns/op
Iteration   4: 20.074 ns/op
Iteration   5: 18.899 ns/op




make test TEST="micro:java.lang.StringConcat.concat6String" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.reuseThreshold=4 -Djava.lang.invoke.StringConcat.inlineThreshold=4"

Running test 'micro:java.lang.StringConcat.concat6String'
# reuseThreshold=4 inlineThreshold=4

# Run progress: 0.00% complete, ETA 00:00:30
# Fork: 1 of 3
# Warmup Iteration   1: 22.131 ns/op
# Warmup Iteration   2: 20.265 ns/op
# Warmup Iteration   3: 20.431 ns/op
# Warmup Iteration   4: 19.408 ns/op
# Warmup Iteration   5: 20.723 ns/op
# Warmup Iteration   6: 20.073 ns/op
# Warmup Iteration   7: 19.341 ns/op
# Warmup Iteration   8: 20.285 ns/op
# Warmup Iteration   9: 19.997 ns/op
# Warmup Iteration  10: 19.217 ns/op
Iteration   1: 19.142 ns/op
Iteration   2: 20.158 ns/op
Iteration   3: 19.185 ns/op
Iteration   4: 19.236 ns/op
Iteration   5: 19.227 ns/op

# Run progress: 33.33% complete, ETA 00:00:20
# Fork: 2 of 3
# Warmup Iteration   1: 22.016 ns/op
# Warmup Iteration   2: 20.012 ns/op
# Warmup Iteration   3: 19.158 ns/op
# Warmup Iteration   4: 18.986 ns/op
# Warmup Iteration   5: 19.255 ns/op
# Warmup Iteration   6: 19.056 ns/op
# Warmup Iteration   7: 19.062 ns/op
# Warmup Iteration   8: 19.120 ns/op
# Warmup Iteration   9: 18.993 ns/op
# Warmup Iteration  10: 19.956 ns/op
Iteration   1: 19.190 ns/op
Iteration   2: 19.010 ns/op
Iteration   3: 19.534 ns/op
Iteration   4: 18.810 ns/op
Iteration   5: 20.023 ns/op

# Run progress: 66.67% complete, ETA 00:00:10
# Fork: 3 of 3
# Warmup Iteration   1: 22.407 ns/op
# Warmup Iteration   2: 19.742 ns/op
# Warmup Iteration   3: 20.294 ns/op
# Warmup Iteration   4: 20.348 ns/op
# Warmup Iteration   5: 19.787 ns/op
# Warmup Iteration   6: 19.931 ns/op
# Warmup Iteration   7: 19.206 ns/op
# Warmup Iteration   8: 19.205 ns/op
# Warmup Iteration   9: 20.156 ns/op
# Warmup Iteration  10: 19.244 ns/op
Iteration   1: 19.890 ns/op
Iteration   2: 19.013 ns/op
Iteration   3: 18.983 ns/op
Iteration   4: 18.966 ns/op
Iteration   5: 19.143 ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311311154

From jiangli at openjdk.org  Tue Aug 27 00:44:04 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 27 Aug 2024 00:44:04 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <5_BKiz0spEIxGN2mZJHiAoaSOWOdnH8kf5POgG9sQ9g=.9339d838-9f04-4d28-93b8-647ad90e805a@github.com>
Message-ID: <rWZgfNP73bXEAaokhO5OFp6ISIwjvac3oCSZwjY5Nrc=.ca5c1d36-083e-4f5c-a564-ac988528408b@github.com>

On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> I compared the extracted changes in this PR with the related parts in https://github.com/openjdk/jdk/pull/19478. They look ok. My concern (as discussed in https://github.com/openjdk/jdk/pull/19478#issuecomment-2278421931) is  that these runtime changes for static JDK can't be tested even they are relatively simple, without the the actual linking change. Any timeline for the static linking changes?

> @jianglizhou
> 
> > [...] these runtime changes for static JDK can't be tested [...]
> 
> Yes, they can. This is just a pure refactoring of existing code. I have deliberately kept out addition of the new places where static linking exceptions are needed in the code.

Hi @magicus, perhaps the answer is both `yes` and `no`. Since your `src/hotspot/share/runtime/linkType.cpp` change removes the needs of requiring `#ifdef STATIC_BUILD` macro from various affected JDK source files to handle the differences between dynamic linking and static linking. From that sense, it's probably `yes` (can be tested as before) as `linkType.cpp` still uses `#ifdef STATIC_BUILD`, and the dynamic v.s. static differences are still determined at build time and not at runtime, as @dholmes-ora and @TheShermanTanker have pointed out. In theory, things (especially the dynamic case) could be tested as before since the fundamental is unchanged. That's different from the changes in https://github.com/openjdk/leyden/tree/hermetic-java-runtime, which does the actual runtime checks.

Since the mainline doesn't have the needed build changes to have the ability to link a `javastatic` binary, from that point of view all the `static` cases in the PR cannot be tested yet. We could test them by integrating into https://github.com/openjdk/leyden/tree/hermetic-java-runtime and downstream codebase (with full hermetic Java support) after the PR is approved/submitted in the mainline. That might help.

To ease some of @dholmes-ora's concern (and my concern as well) that the initial change could affect all Java instances, perhaps providing the build support for statically linking `javastatic` should be done as an immediate follow-up step (I'm continually nudging you toward that direction :-)). We have multiple goals to achieve in the build system for just the static-Java-only part and we probably want to consider adding the support in following sequence:

1) Capability of building a fully statically linked `javastatic` executable

2) Allow linking both `java` (with dynamic linking support) and `javatatic` using the same set of `.o` object files
? ? - Eliminate the needs of `#ifdef STATIC_BUILD` macro. Your `linkType.cpp` change seems to be able to limit the macro usage within one file and just conditionally compile the single file only. So that helps.
? ? - May involve spec changes for `JNI_OnLoad` and friends to use `JNI_OnLoad_<lib_name>` naming for dynamic linking support. The needed spec change for the static linking case (built in library support) has already been done in the past by others.

3) General solution for duplicating symbol issue - `objcopy` for symbol hiding

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2311351447

From redestad at openjdk.org  Tue Aug 27 00:51:03 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 27 Aug 2024 00:51:03 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v5]
In-Reply-To: <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
Message-ID: <7PhL0s9FgHvSp_XWNvD17_T3AULIpWv9a20YHJfxk7Y=.470a3980-dcc8-4320-9a4d-cfc9e406ba90@github.com>

On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - reuseThreshold -> cacheThreshold
>  - Revert "optimize for CompactStrings is off"
>    
>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.

So the code shape from inlining hard-coded constants is smaller thus there might be a warmup benefit? OK, looks somewhat insignificant. 

What happens if you run something more realistic at scale with many string concats expressions across a larger application - what happens then? You'd be generating a new class at every call site above `cacheThreshold`, so every time we encounter an expression that would have been a cache hit we instead increase application footprint slightly. And each freshly spun class will have to be interpreted many times before being JIT compiled. So that potential warmup win you notice on the `StringConcat` might quickly turn into a loss, since we'd do more or less the same work over and over.

I remain unconvinced that this `cacheThreshold` should be anything but an opt-in feature. It might be great for many smaller apps that have a known small number of concatenations and want to reach for that potential win. But in the meantime I think we should treat the performance difference between the now-default translation and this static hard-coded translation as a bug and work towards getting the same performance out of the former instead of selecting a default that might have severe downsides at scale.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311358786

From duke at openjdk.org  Tue Aug 27 01:05:07 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 01:05:07 GMT
Subject: RFR: 8338930: StringConcatFactory hardCoded string concatenation
 strategy [v5]
In-Reply-To: <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
References: <Bc8Dv_7QidQlwdDXXCSr3nWJgmaBWLJfji9BV90GjSw=.0a7758c7-0280-45d4-9508-5254265147c5@github.com>
 <ORSNjMPr6Joz-e3aJORgKwdFSa47L2QVadS0I-gA2nE=.79f65d07-873d-477d-b9bc-6ad3565d565d@github.com>
Message-ID: <3ACws2mAV6OmLR7ryHrBEYAn9y7RXN23JACR0XQ_J0g=.89081499-f169-4333-b752-a56ec6792fa1@github.com>

On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> This is a follow-up to PR #20273, which improves performance when the number of parameters exceeds 20.
>> 
>> When the number of parameters is large, the possibility of reuse will be lower, so we can use the static concat method and write the length and coder directly into the bytecode to solve the performance regression problem.
>
> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - reuseThreshold -> cacheThreshold
>  - Revert "optimize for CompactStrings is off"
>    
>    This reverts commit a9fa264afd9fa625ef29357a7ca8559ce9c5fea4.

Another point is that when the parameters are large, using hard coding eliminates the need for forceinline. Without forceinline, C2 has more optimization strategy options.

All these advantages are not very strong, but adding hard-coded constants is also simple.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311372610

From duke at openjdk.org  Tue Aug 27 03:31:12 2024
From: duke at openjdk.org (duke)
Date: Tue, 27 Aug 2024 03:31:12 GMT
Subject: Withdrawn: 8335478: Add notes for Error handling in Method.invoke and
 Constructor.newInstance
In-Reply-To: <nJCs2bRcBBf_Q5t45yc5mh18f79cpKw262C0cjFP_Vk=.cbdaa9d2-9669-4bcb-bdc1-7054264b1d9a@github.com>
References: <nJCs2bRcBBf_Q5t45yc5mh18f79cpKw262C0cjFP_Vk=.cbdaa9d2-9669-4bcb-bdc1-7054264b1d9a@github.com>
Message-ID: <QxO07yKSONErzWSAn7jO3HqGk74AAsDo4UFAsTgByEc=.6c18c579-c976-40c3-8d85-d29a2702ab9b@github.com>

On Mon, 1 Jul 2024 21:48:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> `Method.invoke` and `Constructor.newInstance` wraps `Error` in `InvocationTargetException`, which is bug-prone for users. Worse, this is only ambiguously mentioned in the API specification.
> 
> This patch proposes to explicitly mention that `InvocationTargetException` wraps any throwable, and adds an API notes section describing the risk of not handling `InvocationTargetException` (and thereby ignoring the wrapped errors), to advise against future user errors.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19980

From jpai at openjdk.org  Tue Aug 27 04:17:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Aug 2024 04:17:03 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <cGAwRzv6Tnjo08tyalmyX8A96rp0InB_JD50b8n7cxU=.c19bcca9-3801-4442-8cf4-ba66ea5f9281@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
 <cGAwRzv6Tnjo08tyalmyX8A96rp0InB_JD50b8n7cxU=.c19bcca9-3801-4442-8cf4-ba66ea5f9281@github.com>
Message-ID: <wqffksgg7ZyI-SG91R_BiImMmSv84jyuMjDEj5xT_ac=.339da4a0-39c5-499d-bb46-023cede6ba4e@github.com>

On Mon, 26 Aug 2024 07:06:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Separately, I've often wondered how many plugins are putting file paths into the value by mistake, this has historically been an area of confusion.

You are right - the values that get used in a `Class-Path` entry keeps coming up for discussion frequently. I remember there was one around 3-4 years back (but I can't find that mail thread now). I went back and checked the documentation to see if that can be improved. The current specification of this attribute at https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html#class-path-attribute is very extensive and I think very clear (and that's a good thing). However, I think that page isn't visited very often or found easily. The tutorial for creating manifest files and adding `Class-Path` entry, I think, is the more commonly visited one https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html (at least that's the one I usually find in search results). I wonder if that tutorial page can be improved a bit or at least point to the specification page of the `Class-Path` attribute.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2311534675

From jwaters at openjdk.org  Tue Aug 27 04:18:11 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Aug 2024 04:18:11 GMT
Subject: RFR: 8336289: Obliterate most references to _snprintf in the
 Windows JDK [v5]
In-Reply-To: <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
 <_LI2j7i2WUtuzSXitbNtJVWRcmQFfOKASpJZ9P-iV_k=.467c12a0-ac63-4c22-8e8d-f4ea4b1c8f9c@github.com>
Message-ID: <CrhoD4l9pqLEP8TAsocgoRqSkOtpXO5P4rnHIkf371U=.64f0a4c4-efef-43ce-829c-33306afa59cc@github.com>

On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nu
 ll terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>> 
>> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)
>
> 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into snprintf
>  - Change copyright years and formatting
>  - Revert Standard Integer type rewrite
>  - USe os::snprintf in HotSpot
>  - Obliterate most references to _snprintf in the Windows JDK

Thanks everyone for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20153#issuecomment-2311533460

From jwaters at openjdk.org  Tue Aug 27 04:18:12 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 27 Aug 2024 04:18:12 GMT
Subject: Integrated: 8336289: Obliterate most references to _snprintf in the
 Windows JDK
In-Reply-To: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
References: <bRXIg7-ZDVwrMLZxIYD1hBnr53CxibSNo860Qwu0dNI=.3504bfe2-f361-4cb3-b203-a5eaf8d1df61@github.com>
Message-ID: <RAahIg8ZI7xMqJcs6m5biQO1vtThdbjL2WzyDDm4qb4=.8515a022-9ec2-4d3c-933a-e32a45145adc@github.com>

On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> snprintf has been available for all officially and unofficially supported compilers for Windows, Visual Studio since version 2015 and gcc since, well, forever. snprintf is conforming to C99 since the start when compiling using gcc, and 2015 when using Visual Studio. Since it conforms to C99 and provides better semantics than _snprintf, and is not compiler specific, we should use it in most places where we currently use _snprintf. This makes JDK code where this is used more robust due to the null terminating guarantee of snprintf. Since most of the changes are extremely simple, I've included all of them hoping to get this all done in one shot. The only places _snprintf is not replaced is places where I'm not sure whether the code is ours or not (As in, imported source code for external libraries). Note that the existing checks in place for the size of the characters written still work, as the return value of snprintf works mostly the same as _snprintf. The only difference is the nul
 l terminating character at the end and the returning of the number of written characters if the buffer was terminated early, as seen here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
> 
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for awt and jdk.accessibility, 1 for java.base, 1 for security, 1 for jdk.management(?)

This pull request has now been integrated.

Changeset: cd9e241f
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd9e241f0ec10c7b31d36cbfb994bc20d81a0517
Stats:     70 lines in 12 files changed: 0 ins; 16 del; 54 mod

8336289: Obliterate most references to _snprintf in the Windows JDK

Reviewed-by: kbarrett, dholmes, jpai, mullan, djelinski, prr

-------------

PR: https://git.openjdk.org/jdk/pull/20153

From Hempushpa.Sahu at ibm.com  Tue Aug 27 05:28:32 2024
From: Hempushpa.Sahu at ibm.com (Hempushpa Sahu)
Date: Tue, 27 Aug 2024 05:28:32 +0000
Subject: Namespace Prefix Issue in XML to XSL Transformation
Message-ID: <SA1PR15MB52849997884D00D57E8880DC9D942@SA1PR15MB5284.namprd15.prod.outlook.com>

Problem Description :
XSLT transformation creating unique namespace prefixes.

Analysis & Observation :
When upgrading from Java 8 to Java 17, the XSLT transformation is generating a new namespace prefix for every XML element, even when the namespace value matches that of the parent element. This leads to large XML file transformations exceeding the file size and memory limits on our systems.

The behaviour in OpenJDK has remained consistent since JDK 8; however, the namespace prefix issue is not something we find acceptable.

Our investigation into the OpenJDK code led us to defect https://bugs.openjdk.org/browse/JDK-8167179, which addressed the namespace prefix issue in the OpenJDK 8 release. Despite this, we are still able to reproduce the issue in OpenJDK versions 8, 11, 17, and 22.


Releases:
OpenJDK 8, 11, 17 & 22 the issue is seen.

Next steps:
Please review and suggest if the above understanding is right. And please suggest solution to resolve the issue.

NOTE:
Please find the attachment with below files-
XML file - sourceFile.xml
XSL file - ie_si_to_spe.xsl
Current output - sourceFile-test-transform.xml
Expected output - sourceFile-expected-transform.xml

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240827/8d2e2297/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TransformationIssue_Data.zip
Type: application/x-zip-compressed
Size: 2296 bytes
Desc: TransformationIssue_Data.zip
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240827/8d2e2297/TransformationIssue_Data-0001.zip>

From jbhateja at openjdk.org  Tue Aug 27 05:29:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Aug 2024 05:29:04 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 305:

> 303: #define __ _masm->
> 304: 
> 305: address StubGenerator::generate_libmTanh() {

Please add the link to original source references from where algorithm is ported / disassembled.

src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 437:

> 435:   __ mulpd(xmm1, xmm1);
> 436:   __ movdqu(xmm4, ExternalAddress(pv + 32), r11 /*rscratch*/);
> 437:   __ mulpd(xmm2, xmm1);

I would encourage either you add detailed comments or give meaningful names to the registers to ease the review process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1732140581
PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1732144262

From cstein at openjdk.org  Tue Aug 27 06:51:05 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 27 Aug 2024 06:51:05 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
Message-ID: <V4b8-DpgvhG14E5XU57p0OStnViXduBUKNkx2QWm2SY=.eef9b845-894f-4a6e-b123-332d819c1b65@github.com>

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert to old code comment
>  - use "JAR file" consistently in test's code comments
>  - rename closeLoaderIgnoreEx to closeQuietly

Simplify test data provision by replacing `MethodSource` with `ValueSource`.

> `@ValueSource` is one of the simplest possible sources. It lets you specify a single array of literal values and can only be used for providing a single argument per parameterized test invocation.

Find more details about "[Sources of Arguments](https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests-sources)" in JUnit's User-Guide.

test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 38:

> 36: import org.junit.jupiter.params.ParameterizedTest;
> 37: import org.junit.jupiter.params.provider.Arguments;
> 38: import org.junit.jupiter.params.provider.MethodSource;

Suggestion:

import org.junit.jupiter.params.provider.ValueSource;

test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 75:

> 73:                 Arguments.of("lib4.jar C:\\bar\\foo\\world/hello.jar")
> 74:         );
> 75:     }

Suggestion:

test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 84:

> 82:      */
> 83:     @ParameterizedTest
> 84:     @MethodSource("malformedClassPaths")

Suggestion:

    @ValueSource(strings={
        "C:\\foo\\bar\\hello/world.jar lib2.jar",
        "C:/hello/world/foo.jar",
        "lib4.jar C:\\bar\\foo\\world/hello.jar"
    })

test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 114:

> 112:                 Arguments.of("lib10.jar")
> 113:         );
> 114:     }

Suggestion:

test/jdk/java/net/URLClassLoader/JarLoaderCloseTest.java line 124:

> 122:      */
> 123:     @ParameterizedTest
> 124:     @MethodSource("missingButParsableClassPaths")

Suggestion:

    @ValueSource(strings={"/home/me/hello/world.jar lib9.jar", "lib10.jar"})

-------------

Changes requested by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20691#pullrequestreview-2262297032
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1732237021
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1732236791
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1732236240
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1732237567
PR Review Comment: https://git.openjdk.org/jdk/pull/20691#discussion_r1732238441

From vklang at openjdk.org  Tue Aug 27 07:07:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 27 Aug 2024 07:07:35 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely long
 delays
Message-ID: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>

Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

-------------

Commit messages:
 - Addressing 8323703 by capping max STPE delay to 146 years

Changes: https://git.openjdk.org/jdk/pull/20653/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338765
  Stats: 24 lines in 1 file changed: 5 ins; 18 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20653/head:pull/20653

PR: https://git.openjdk.org/jdk/pull/20653

From vklang at openjdk.org  Tue Aug 27 07:07:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 27 Aug 2024 07:07:35 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
Message-ID: <gXE3nqrwdmtyMRaUb7bRH5hYp0V5zGYyW2mNqr_mJYE=.a47ff031-742f-40c5-87a3-5f1e9037e18e@github.com>

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

@AlanBateman Do you think we could use the https://bugs.openjdk.org/browse/JDK-8338104 reproducer? ? 

@DougLea Any thoughts on this change? Do we need to amend some documentation / specification?

@AlanBateman @DougLea I created a new JBS issue for this PR so that we can link any pre-existing issues to that one as duplicates. See https://bugs.openjdk.org/browse/JDK-8338765

Possible duplicates:

https://bugs.openjdk.org/browse/JDK-8323703
https://bugs.openjdk.org/browse/JDK-8067227
https://bugs.openjdk.org/browse/JDK-8338104

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2299542801
PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2302934168
PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2304147360

From dl at openjdk.org  Tue Aug 27 07:07:35 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 27 Aug 2024 07:07:35 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
Message-ID: <rS-rioeSi3NWa17FkFsX5n-YE1bGxyNjVgcQbt3NhCA=.7288a0eb-3c3d-4ebf-81f8-288d47bd6e1c@github.com>

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

I think this is the most straightforward  way to address. It doesn't need doc change -- there are other cases where bounded but multi-year ceilings are internally used without the need explicit mention.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2299594504

From alanb at openjdk.org  Tue Aug 27 07:07:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Aug 2024 07:07:35 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <gXE3nqrwdmtyMRaUb7bRH5hYp0V5zGYyW2mNqr_mJYE=.a47ff031-742f-40c5-87a3-5f1e9037e18e@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
 <gXE3nqrwdmtyMRaUb7bRH5hYp0V5zGYyW2mNqr_mJYE=.a47ff031-742f-40c5-87a3-5f1e9037e18e@github.com>
Message-ID: <F2tdVsm3lRWESyB0KtX1WChO-mdifMg4T-5EYYXsUmk=.8c22a0c4-f722-4651-8551-5da949c528cd@github.com>

On Thu, 22 Aug 2024 09:01:43 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Possible duplicates:

Yes, a long standing issue. Cap the value at 146 years seems fine, and avoids us needing to put in workarounds at use-sites.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2304192165

From alanb at openjdk.org  Tue Aug 27 07:07:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Aug 2024 07:07:35 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
Message-ID: <uQcxPb06COeTwMsIZ2Oj8UAqH670yLcQcofxA6UzZ50=.7a9f34b3-0a75-45c1-9a30-9ab6da2e9bef@github.com>

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java line 533:

> 531:      */
> 532:     long triggerTime(long delay) {
> 533:         return System.nanoTime() + Math.min(delay, MAX_NANOS);

The hi-res time source could have any long value so I'm wondering if it's okay for triggerTime to be negative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20653#discussion_r1724870783

From dl at openjdk.org  Tue Aug 27 07:07:36 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 27 Aug 2024 07:07:36 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <uQcxPb06COeTwMsIZ2Oj8UAqH670yLcQcofxA6UzZ50=.7a9f34b3-0a75-45c1-9a30-9ab6da2e9bef@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
 <uQcxPb06COeTwMsIZ2Oj8UAqH670yLcQcofxA6UzZ50=.7a9f34b3-0a75-45c1-9a30-9ab6da2e9bef@github.com>
Message-ID: <Ihbl-WLg63nn6LpZNbvDhdK2QtuPHRQikCz8WL3RUM4=.657e4098-bc50-4408-8521-49771f528a57@github.com>

On Wed, 21 Aug 2024 11:10:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.
>
> src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java line 533:
> 
>> 531:      */
>> 532:     long triggerTime(long delay) {
>> 533:         return System.nanoTime() + Math.min(delay, MAX_NANOS);
> 
> The hi-res time source could have any long value so I'm wondering if it's okay for triggerTime to be negative.

System.nanoTime can be negative anyway (and only checked by subtraction). So this should be OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20653#discussion_r1725256010

From alanb at openjdk.org  Tue Aug 27 07:12:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Aug 2024 07:12:05 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
Message-ID: <iJ7ZeCQ5zdE68um0bmmaNEmz8YCCJnW184f58I4GCcI=.b6da5d16-2333-434a-b185-796206083193@github.com>

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20653#pullrequestreview-2262355443

From alanb at openjdk.org  Tue Aug 27 07:27:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Aug 2024 07:27:03 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <wqffksgg7ZyI-SG91R_BiImMmSv84jyuMjDEj5xT_ac=.339da4a0-39c5-499d-bb46-023cede6ba4e@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
 <cGAwRzv6Tnjo08tyalmyX8A96rp0InB_JD50b8n7cxU=.c19bcca9-3801-4442-8cf4-ba66ea5f9281@github.com>
 <wqffksgg7ZyI-SG91R_BiImMmSv84jyuMjDEj5xT_ac=.339da4a0-39c5-499d-bb46-023cede6ba4e@github.com>
Message-ID: <YuD_TTBSjGTajhgPmcrJYiKEL_E1qcZXQvgqTfpUdOQ=.f6429d15-5466-4ed9-a5b2-ce2fd2366c7c@github.com>

On Tue, 27 Aug 2024 04:14:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The current specification of this attribute at https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html#class-path-attribute is very extensive and I think very clear (and that's a good thing). However, I think that page isn't visited very often or found easily. 

We significantly re-worded the Class-Path section a few releases back but the eco system continues to put file paths, photos of cats, and other problematic values into this attribute.

> The tutorial for creating manifest files and adding `Class-Path` entry, I think, is the more commonly visited one https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html (at least that's the one I usually find in search results). I wonder if that tutorial page can be improved a bit or at least point to the specification page of the `Class-Path` attribute.

This page mentions applets so this is a very old tutorial. We may be able to get it cleaned up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2311761855

From jpai at openjdk.org  Tue Aug 27 08:38:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Aug 2024 08:38:23 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v3]
In-Reply-To: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
Message-ID: <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
> 
> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
> 
> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
> 
> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
> 
> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
> 
> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Christian's suggestion - string ValueSource(s) instead of MethodSource

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20691/files
  - new: https://git.openjdk.org/jdk/pull/20691/files/b5bf8412..7a26807d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20691&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20691&range=01-02

  Stats: 27 lines in 1 file changed: 7 ins; 17 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20691.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20691/head:pull/20691

PR: https://git.openjdk.org/jdk/pull/20691

From jpai at openjdk.org  Tue Aug 27 08:38:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Aug 2024 08:38:23 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v2]
In-Reply-To: <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <p6KHqkEou3f6EDdvuzcJWj3GrGhS00WOeUuBzqhtzYg=.6f9d58fa-5ebb-4dbf-8976-0060b7c8cc5b@github.com>
Message-ID: <K3FLIvDiiDxSaT7LAgYev86Dmb-6O6-eYZ0wVCSm8Cg=.82669d40-0ed5-4820-81c2-da50b5d05425@github.com>

On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - revert to old code comment
>  - use "JAR file" consistently in test's code comments
>  - rename closeLoaderIgnoreEx to closeQuietly

For the relatively small number of test method params used in this test, I liked Christian's review suggestion of using `@ValueSource(strings={...})` instead of the `@MethodSource` - much less code and the values are closer to the test method. So I've updated this PR with only that change.

The test continues to pass with this change. Requesting a re-review of the PR, please.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2311903811

From pminborg at openjdk.org  Tue Aug 27 09:41:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 Aug 2024 09:41:11 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings with
 known lengths
Message-ID: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>

This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.

-------------

Commit messages:
 - Add copyright year
 - Add MemorySegment::getString overload

Changes: https://git.openjdk.org/jdk/pull/20725/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20725&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333843
  Stats: 132 lines in 4 files changed: 114 ins; 9 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20725/head:pull/20725

PR: https://git.openjdk.org/jdk/pull/20725

From sgehwolf at openjdk.org  Tue Aug 27 09:48:50 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Aug 2024 09:48:50 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v35]
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: <FFSS1M7GS20RauKkiCEdkpNH5rS2F4HSSMpJRYOxobs=.70675ea3-3c6f-44e5-9aef-984a361dd3a0@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 140 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - 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
 - ... and 130 more: https://git.openjdk.org/jdk/compare/aefdbdc7...59997873

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=34
  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 pminborg at openjdk.org  Tue Aug 27 09:50:03 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 Aug 2024 09:50:03 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <kVd-TgVaiECIXjnVb3uqm4PM3QrYht_Vp8jF4Lp5MQ8=.96de5719-add5-4339-bdad-40a08c410ab2@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
 <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>
 <z36Rd17ZsMy6BYpR54PUVWTZuGEHYpqJQDSkS6rbA0Y=.14c91a11-6887-4741-93fc-40de74140ad3@github.com>
 <zsHSE3lkpApXBCGzdiWJ2wF_pFcTvXAE3ek2qhYZ4Lk=.157480e7-1441-424a-86ab-6cbf4fbf159a@github.com>
 <kVd-TgVaiECIXjnVb3uqm4PM3QrYht_Vp8jF4Lp5MQ8=.96de5719-add5-4339-bdad-40a08c410ab2@github.com>
Message-ID: <WgKV13znHYuTDPWyYuORIl-yOVuohxjr9h5-U5aieqQ=.78db046b-9b8f-491f-8fdc-3e77189c1474@github.com>

On Mon, 26 Aug 2024 21:38:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Here is a benchmark that fills segments of various random sizes:
>> 
>> 
>> 
>> @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)
>> @Fork(value = 3)
>> public class TestFill {
>> 
>>     private static final int SIZE = 16;
>>     private static final int[] INDICES = new Random(42).ints(0, 8)
>>             .limit(SIZE)
>>             .toArray();
>> 
>> 
>>     private MemorySegment[] segments;
>> 
>>     @Setup
>>     public void setup() {
>>         segments = IntStream.of(INDICES)
>>                 .mapToObj(i -> MemorySegment.ofArray(new byte[i]))
>>                 .toArray(MemorySegment[]::new);
>>     }
>> 
>>     @Benchmark
>>     public void heap_segment_fill() {
>>         for (int i = 0; i < SIZE; i++) {
>>             segments[i].fill((byte) 0);
>>         }
>>     }
>> 
>> }
>> 
>> 
>> This produces the following on my Mac M1:
>> 
>> 
>> Benchmark                   Mode  Cnt   Score   Error  Units
>> TestFill.heap_segment_fill  avgt   30  59.054 ? 3.723  ns/op
>> 
>> 
>> On average, an operation will take 59/16 = ~3 ns per operation (including looping).
>> 
>> A test with the same size for every benchmark looks like this on my machine:
>> 
>> 
>> Benchmark                   (ELEM_SIZE)  Mode  Cnt  Score   Error  Units
>> TestFill.heap_segment_fill            0  avgt   30  1.112 ? 0.027  ns/op
>> TestFill.heap_segment_fill            1  avgt   30  1.602 ? 0.060  ns/op
>> TestFill.heap_segment_fill            2  avgt   30  1.583 ? 0.004  ns/op
>> TestFill.heap_segment_fill            3  avgt   30  1.909 ? 0.055  ns/op
>> TestFill.heap_segment_fill            4  avgt   30  1.605 ? 0.059  ns/op
>> TestFill.heap_segment_fill            5  avgt   30  1.900 ? 0.064  ns/op
>> TestFill.heap_segment_fill            6  avgt   30  1.891 ? 0.038  ns/op
>> TestFill.heap_segment_fill            7  avgt   30  2.237 ? 0.091  ns/op
>
> As discussed offline, can't we use a stable array of functions or something like that which can be populated lazily? That way you can access the function you want in a single array access, and we could put all these helper methods somewhere else.

Unfortunately, a stable array of functions/MethodHandles didn't work from a performance perspective.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1732503991

From jbhateja at openjdk.org  Tue Aug 27 09:58:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Aug 2024 09:58:44 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v6]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <SbWS4YOn-u1WfNT4AwWVAvEGa1z_YDsX2DnQ9M0wWDE=.39687e9e-d72c-4151-a835-7645b5670c83@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/6cb1a46d..408a8694

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=04-05

  Stats: 112 lines in 7 files changed: 91 ins; 14 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Tue Aug 27 10:04:04 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Aug 2024 10:04:04 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v5]
In-Reply-To: <2_P1qPMS46tgh4RUSuitcjXYnd0koS_BxfRRRmj79EY=.c3baeeaa-87f7-47d4-bc70-ae2afd9de745@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7e5pWnvjqk-dQYNeaZjFzXcd5WlzniZPl5T4l1rKQGE=.0882bcd4-e307-4a29-aa41-5496ee029a60@github.com>
 <2_P1qPMS46tgh4RUSuitcjXYnd0koS_BxfRRRmj79EY=.c3baeeaa-87f7-47d4-bc70-ae2afd9de745@github.com>
Message-ID: <o9QRuL3k5660Spm1MKq48zexkgYGaDFiJVbslQIHmlE=.c2b31e20-d5b3-41da-9a23-5f11acb137ef@github.com>

On Fri, 23 Aug 2024 22:29:46 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> API changes look good. (Note at the moment we are not proposing to change how shuffles works - as you point out the two vector `selectFrom` and `rearrange` differ in the index representation.)
> 
> IIUC if the more direct two-table instruction is not available you fall back to calling two single arg rearranges with a blend, as a lowering transformation, similar to the fallback Java expression.
> 
> The float/double conversion bothers me, not suggesting we do something about it here, noting down for any future conversation on shuffles. Ideally we would want the equivalent integral vector (int or long) to represent the index, tricky to express in the API, or alternative treat as a bitwise no-op conversion (there is also impact on `toShuffle` too).

Thanks @PaulSandoz, 

> IIUC if the more direct two-table instruction is not available you fall back to calling two single arg rearranges with a blend, as > a lowering transformation, similar to the fallback Java expression.

Idea here is to be performant as much as possible and save additional boxing penalties incurred due to failed intrinsification if target does not directly support two vector permutation but does supports its constituents. I have now unwrapped and optimized the fallback implementation to directly operates over index vector lanes instead going through intermediate shuffle.

> 
> The float/double conversion bothers me, not suggesting we do something about it here, noting down for any future conversation on shuffles. 

I Agree.

> Ideally we would want the equivalent integral vector (int or long) to represent the index, tricky to express in the API, or alternative treat as a bitwise no-op conversion (there is also impact on `toShuffle` too).
 
Since floating-point index vector may carry special values like NaN, POSITIVE_INFINITY and NEGATIVE_INFINITY,  thus with default wrapping semantics, its necessary to convert this into integral vector followed by wrapping normalization to valid two vector index range,  through existing sequence we are bypassing partial wrapping (part to toShuffle) altogether which may save few instruction.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2312089987

From pminborg at openjdk.org  Tue Aug 27 10:38:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 Aug 2024 10:38:46 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into fill-performance
 - Fix typo
 - Add a comment about the old switch type
 - Remove unused import
 - Reduce kick-in size and add test
 - Initial implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/b28f97fa..6fb6eefa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=03-04

  Stats: 1722 lines in 197 files changed: 1151 ins; 181 del; 390 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From pminborg at openjdk.org  Tue Aug 27 10:46:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 Aug 2024 10:46:30 GMT
Subject: RFR: 8338489: Typo in MemorySegment doc
Message-ID: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>

This trivial PR proposes to fix a typo in the `MemorySegment` docs.

-------------

Commit messages:
 - Fix typo in MemorySegment docs

Changes: https://git.openjdk.org/jdk/pull/20727/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20727&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338489
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20727/head:pull/20727

PR: https://git.openjdk.org/jdk/pull/20727

From aph at openjdk.org  Tue Aug 27 10:57:08 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 27 Aug 2024 10:57:08 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
Message-ID: <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>

On Tue, 27 Aug 2024 05:24:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
>> 
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 437:
> 
>> 435:   __ mulpd(xmm1, xmm1);
>> 436:   __ movdqu(xmm4, ExternalAddress(pv + 32), r11 /*rscratch*/);
>> 437:   __ mulpd(xmm2, xmm1);
> 
> I would encourage either you add detailed comments or give meaningful names to the registers to ease the review process.

I agree, this is all rather obscure. Ideally the same names that are used in wherever this comes from.

Where does the algorithm come from? What are its accuracy guarantees?

In addition, given the rarity of hyperbolic tangents in Java applications, do we need this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1732613573

From jbhateja at openjdk.org  Tue Aug 27 11:13:09 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 27 Aug 2024 11:13:09 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <Ze9z13FjRDM1rVQY4obG-9WHoTFTFZ7e3JzcD89kbxs=.9c6c5d29-6733-4047-a1a9-d97a7542f0b9@github.com>

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Hi @vamsi-parasa ,  Kindly also add a JMH micro benchmark, I did a first run and see around 4% performance drop with attached micro on Sapphire Rapids.
[test.txt](https://github.com/user-attachments/files/16761142/test.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2312254535

From aturbanov at openjdk.org  Tue Aug 27 11:21:03 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 Aug 2024 11:21:03 GMT
Subject: RFR: 8338765: ScheuledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
Message-ID: <wjI7M-0DEzQCx1iFRZM2f3KQmOKNM_zC_jvxrWC98p4=.05c22cb6-057d-4c24-a2db-7b77e2bcb824@github.com>

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

There is now typo in interface name. `ScheuledThreadPoolExecutor` -> `ScheduledThreadPoolExecutor`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2312284071

From duke at openjdk.org  Tue Aug 27 11:52:38 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 11:52:38 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc [v2]
In-Reply-To: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
Message-ID: <nIvIudehimoc0Tm2mCLMQeRCj0WpoFiK9ErqGZ2FquA=.075a8fa5-d82b-4de2-887d-eca6271fef55@github.com>

> The string concatenation of java.base module is implemented based on StringBuilder, which will result in extra object allocation and slow performance. We can solve this problem by using String.concat method and StringConcatHelper to provide concat method.
> 
> for example, 
> 
> * use "+"
> 
> class ClassDesc {
>     default String displayName() {
>         c.displayName() + "[]".repeat(depth)
>     }
> }
> 
> 
> bytecode:
> 
> 106: new           #40                 // class java/lang/StringBuilder
> 109: dup
> 110: invokespecial #42                 // Method java/lang/StringBuilder."<init>":()V
> 113: aload_2
> 114: invokeinterface #195,  1          // InterfaceMethod displayName:()Ljava/lang/String;
> 119: invokevirtual #50                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
> 122: ldc           #198                // String []
> 124: iload_1
> 125: invokevirtual #200                // Method java/lang/String.repeat:(I)Ljava/lang/String;
> 128: invokevirtual #50                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
> 131: invokevirtual #53                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
> 134: areturn
> 
> 
> * use String#concat
> 
> c.displayName().concat("[]".repeat(depth))
> 
> 
> bytecode:
> 
> 112: ldc           #198                // String []
> 114: iload_1
> 115: invokevirtual #200                // Method java/lang/String.repeat:(I)Ljava/lang/String;
> 118: invokevirtual #86                 // Method java/lang/String.concat:(Ljava/lang/String;)Ljava/lang/String;

Shaojin Wen has updated the pull request incrementally with three additional commits since the last revision:

 - more concat
 - Suggestions from @ExE-Boss
 - concat Object value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20705/files
  - new: https://git.openjdk.org/jdk/pull/20705/files/16ec24a8..ea8c814e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20705&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20705&range=00-01

  Stats: 25 lines in 6 files changed: 7 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20705/head:pull/20705

PR: https://git.openjdk.org/jdk/pull/20705

From duke at openjdk.org  Tue Aug 27 11:52:39 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 11:52:39 GMT
Subject: RFR: 8338937: Optimize the string concatenation of ClassDesc [v2]
In-Reply-To: <3kyW1twmZRxE9JK7IjXGMExzaeRnd3oNAV09RiKvIKQ=.0863b4f5-edd7-4c2b-aca2-bc6e222f42c6@github.com>
References: <aket7BwbH4xv6vqRvqPrw5ySkHkBv9k2STEipZVYzX8=.1f607753-7475-4bc2-825b-fd36ff17746c@github.com>
 <Hz_8xEGVPSxSbTwmz6LDIcrZy1LlKK3tcZ95-WTFEkU=.1fc06198-f7dc-4537-962d-7458a791b0b7@github.com>
 <ApIRtDOQJY3Ma2Mnjdut_8xTj6LJGMJhwaDeaRaZYBs=.55b7e14d-6760-4161-a31f-f8955f75a6ed@github.com>
 <-fuXxE0pHV8Yj7mj2T_1y2CpIOXo8j0mXQAC0GRHVXU=.eb317b32-4b43-41d7-b21c-68cf13ff5942@github.com>
 <3kyW1twmZRxE9JK7IjXGMExzaeRnd3oNAV09RiKvIKQ=.0863b4f5-edd7-4c2b-aca2-bc6e222f42c6@github.com>
Message-ID: <1IOnKRB-pRBFdw3-XsIsMcKi9QUA58MeT7y_rdCqx7s=.862d3934-74f8-46f9-8cb3-cb942b8d0561@github.com>

On Sun, 25 Aug 2024 21:41:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Well, `Class?::descriptorString()` is?referenced?from the?`ReferenceClassDescImpl` creation?code in?`ConstantUtils`:
>> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java#L89-L91
>
> I plan to change all of these in another PR https://github.com/wenshao/jdk/commit/b500348cde84e10dc968c7503b8c1dac9131f146

I've accepted your suggestion and don't want to change too much at once.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20705#discussion_r1732150678

From vklang at openjdk.org  Tue Aug 27 12:14:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 27 Aug 2024 12:14:03 GMT
Subject: RFR: 8338765: ScheduledThreadPoolExecutor struggles with extremely
 long delays
In-Reply-To: <wjI7M-0DEzQCx1iFRZM2f3KQmOKNM_zC_jvxrWC98p4=.05c22cb6-057d-4c24-a2db-7b77e2bcb824@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
 <wjI7M-0DEzQCx1iFRZM2f3KQmOKNM_zC_jvxrWC98p4=.05c22cb6-057d-4c24-a2db-7b77e2bcb824@github.com>
Message-ID: <1E08IeMUEqK3eUUM3BdsbvvTc-tNtpfKax0GiNBCqew=.ec9cc741-c771-4d13-896d-68ba42362d51@github.com>

On Tue, 27 Aug 2024 11:18:43 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.
>
> There is now typo in interface name. `ScheuledThreadPoolExecutor` -> `ScheduledThreadPoolExecutor`

Thanks, @turbanoff?now fixed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20653#issuecomment-2312393513

From duke at openjdk.org  Tue Aug 27 13:00:07 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 27 Aug 2024 13:00:07 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v4]
In-Reply-To: <WgKV13znHYuTDPWyYuORIl-yOVuohxjr9h5-U5aieqQ=.78db046b-9b8f-491f-8fdc-3e77189c1474@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <8qWAJ5QP_CqSuW7WE_TeVRp3UY0vPUzcwJEgTwO12Tc=.43da5458-1b8f-43ea-a3dd-158dcb12a552@github.com>
 <7a8rMGnMYjk-vaxG-YGlYmxXA0JyfX2QJ3QMTRcLC2M=.4e935d4d-d023-4907-8dcc-bc6889104b12@github.com>
 <z36Rd17ZsMy6BYpR54PUVWTZuGEHYpqJQDSkS6rbA0Y=.14c91a11-6887-4741-93fc-40de74140ad3@github.com>
 <zsHSE3lkpApXBCGzdiWJ2wF_pFcTvXAE3ek2qhYZ4Lk=.157480e7-1441-424a-86ab-6cbf4fbf159a@github.com>
 <kVd-TgVaiECIXjnVb3uqm4PM3QrYht_Vp8jF4Lp5MQ8=.96de5719-add5-4339-bdad-40a08c410ab2@github.com>
 <WgKV13znHYuTDPWyYuORIl-yOVuohxjr9h5-U5aieqQ=.78db046b-9b8f-491f-8fdc-3e77189c1474@github.com>
Message-ID: <SwqvqgCF4fiq2eD_b3adXkmySLr2LWWgZbv8mt2-LWk=.83732a78-b7ea-4f7c-baeb-e332313fbc5c@github.com>

On Tue, 27 Aug 2024 09:47:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> As discussed offline, can't we use a stable array of functions or something like that which can be populated lazily? That way you can access the function you want in a single array access, and we could put all these helper methods somewhere else.
>
> Unfortunately, a stable array of functions/MethodHandles didn't work from a performance perspective.

> Here is a benchmark that fills segments of various random sizes:

without proper branch misses perf counters is difficult to say if it is actually messing up with the Apple MX branch pred...

For my Ryzen this is the test which mess up with the branch prediction (which is fairly good in AMD); clearly not inlining `fill` is a trick to make `MemorySegment::fill` inlined and still makes the branch predictor targets "stable" for our purposes


import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.CompilerControl;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Param;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;

import java.lang.foreign.MemorySegment;
import java.util.Random;
import java.util.concurrent.TimeUnit;

@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)
@Fork(value = 3)
public class TestFill {

    @Param({"false", "true"})
    private boolean shuffle;
    private MemorySegment[] segments;
    @Param({ "1024", "128000"})
    private int samples;
    private byte[] segmentSequence;

    @Setup
    public void setup() {
        segments = new MemorySegment[8];
        // still allocates 8 different arrays
        for (int i = 0; i < 8; i++) {
            // we always pay the most of the cost here, for fun
            byte[] a = shuffle? new byte[i + 1] : new byte[8];
            segments[i] = MemorySegment.ofArray(a);
        }
        segmentSequence = new byte[samples];
        var rnd = new Random(42);
        for(int i = 0; i < samples; i++) {
            // if shuffle == false always fall into the "worst" case of populating 8 bytes
            segmentSequence[i] = (byte) rnd.nextInt(0, 8);
        }
    }

    @Benchmark
    public void heap_segment_fill() {
        var segments = this.segments;
        for (int nextIndex : segmentSequence) {
            fill(segments[nextIndex]);
        }
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public void fill(MemorySegment segment) {
        segment.fill((byte) 0);
    }

}


With

# JMH version: 1.34
# VM version: JDK 21, Java HotSpot(TM) 64-Bit Server VM, 21+35-LTS-2513

I got:



Which means that despite is not that optimized on JDK 21 still this benchmark mess up enough with the branch predictor that will hit badly as the perf counters shows


Benchmark                                           (samples)  (shuffle)  Mode  Cnt         Score         Error      Units
TestFill.heap_segment_fill                               1024      false  avgt   30     10296.595 ?      19.694      ns/op
TestFill.heap_segment_fill:CPI                           1024      false  avgt    3         0.200 ?       0.006  clks/insn
TestFill.heap_segment_fill:IPC                           1024      false  avgt    3         5.006 ?       0.152  insns/clk
TestFill.heap_segment_fill:L1-dcache-load-misses         1024      false  avgt    3         7.839 ?      35.541       #/op
TestFill.heap_segment_fill:L1-dcache-loads               1024      false  avgt    3     90908.364 ?   19714.476       #/op
TestFill.heap_segment_fill:L1-icache-load-misses         1024      false  avgt    3         0.458 ?       1.347       #/op
TestFill.heap_segment_fill:L1-icache-loads               1024      false  avgt    3        70.000 ?     287.459       #/op
TestFill.heap_segment_fill:branch-misses                 1024      false  avgt    3         8.666 ?      10.013       #/op
TestFill.heap_segment_fill:branches                      1024      false  avgt    3     49674.054 ?    9931.580       #/op
TestFill.heap_segment_fill:cycles                        1024      false  avgt    3     46501.496 ?    8694.782       #/op
TestFill.heap_segment_fill:dTLB-load-misses              1024      false  avgt    3         0.186 ?       0.549       #/op
TestFill.heap_segment_fill:dTLB-loads                    1024      false  avgt    3         1.426 ?       4.003       #/op
TestFill.heap_segment_fill:iTLB-load-misses              1024      false  avgt    3         0.126 ?       0.405       #/op
TestFill.heap_segment_fill:iTLB-loads                    1024      false  avgt    3         0.249 ?       0.869       #/op
TestFill.heap_segment_fill:instructions                  1024      false  avgt    3    232778.290 ?   47179.208       #/op
TestFill.heap_segment_fill:stalled-cycles-frontend       1024      false  avgt    3       257.566 ?     778.186       #/op
TestFill.heap_segment_fill                               1024       true  avgt   30     11003.331 ?      70.467      ns/op
TestFill.heap_segment_fill:CPI                           1024       true  avgt    3         0.208 ?       0.047  clks/insn
TestFill.heap_segment_fill:IPC                           1024       true  avgt    3         4.813 ?       1.077  insns/clk
TestFill.heap_segment_fill:L1-dcache-load-misses         1024       true  avgt    3         8.734 ?       1.782       #/op
TestFill.heap_segment_fill:L1-dcache-loads               1024       true  avgt    3     94231.271 ?    4742.906       #/op
TestFill.heap_segment_fill:L1-icache-load-misses         1024       true  avgt    3         0.506 ?       2.508       #/op
TestFill.heap_segment_fill:L1-icache-loads               1024       true  avgt    3        83.470 ?     216.408       #/op
TestFill.heap_segment_fill:branch-misses                 1024       true  avgt    3         8.894 ?       8.807       #/op
TestFill.heap_segment_fill:branches                      1024       true  avgt    3     50686.259 ?     404.635       #/op
TestFill.heap_segment_fill:cycles                        1024       true  avgt    3     49969.876 ?   11319.276       #/op
TestFill.heap_segment_fill:dTLB-load-misses              1024       true  avgt    3         0.187 ?       0.655       #/op
TestFill.heap_segment_fill:dTLB-loads                    1024       true  avgt    3         1.587 ?       3.060       #/op
TestFill.heap_segment_fill:iTLB-load-misses              1024       true  avgt    3         0.123 ?       0.660       #/op
TestFill.heap_segment_fill:iTLB-loads                    1024       true  avgt    3         0.293 ?       1.287       #/op
TestFill.heap_segment_fill:instructions                  1024       true  avgt    3    240463.595 ?     976.383       #/op
TestFill.heap_segment_fill:stalled-cycles-frontend       1024       true  avgt    3       255.006 ?     988.846       #/op
TestFill.heap_segment_fill                             128000      false  avgt   30   1259362.873 ?    5934.195      ns/op
TestFill.heap_segment_fill:CPI                         128000      false  avgt    3         0.201 ?       0.025  clks/insn
TestFill.heap_segment_fill:IPC                         128000      false  avgt    3         4.982 ?       0.626  insns/clk
TestFill.heap_segment_fill:L1-dcache-load-misses       128000      false  avgt    3      2872.859 ?    7141.312       #/op
TestFill.heap_segment_fill:L1-dcache-loads             128000      false  avgt    3  10657359.179 ? 1907105.367       #/op
TestFill.heap_segment_fill:L1-icache-load-misses       128000      false  avgt    3        60.908 ?      97.434       #/op
TestFill.heap_segment_fill:L1-icache-loads             128000      false  avgt    3      8853.079 ?    8185.081       #/op
TestFill.heap_segment_fill:branch-misses               128000      false  avgt    3       881.014 ?    3001.249       #/op
TestFill.heap_segment_fill:branches                    128000      false  avgt    3   6252293.868 ?  150888.746       #/op
TestFill.heap_segment_fill:cycles                      128000      false  avgt    3   5728074.407 ?  820865.748       #/op
TestFill.heap_segment_fill:dTLB-load-misses            128000      false  avgt    3        24.925 ?     164.673       #/op
TestFill.heap_segment_fill:dTLB-loads                  128000      false  avgt    3       249.671 ?     987.855       #/op
TestFill.heap_segment_fill:iTLB-load-misses            128000      false  avgt    3        14.258 ?      47.128       #/op
TestFill.heap_segment_fill:iTLB-loads                  128000      false  avgt    3        34.156 ?     248.858       #/op
TestFill.heap_segment_fill:instructions                128000      false  avgt    3  28538131.024 ?  526036.510       #/op
TestFill.heap_segment_fill:stalled-cycles-frontend     128000      false  avgt    3     27932.797 ?   27039.568       #/op
TestFill.heap_segment_fill                             128000       true  avgt   30   1857275.169 ?    4604.437      ns/op
TestFill.heap_segment_fill:CPI                         128000       true  avgt    3         0.288 ?       0.009  clks/insn
TestFill.heap_segment_fill:IPC                         128000       true  avgt    3         3.472 ?       0.109  insns/clk
TestFill.heap_segment_fill:L1-dcache-load-misses       128000       true  avgt    3      3433.246 ?   15336.162       #/op
TestFill.heap_segment_fill:L1-dcache-loads             128000       true  avgt    3  12940291.898 ? 4889405.663       #/op
TestFill.heap_segment_fill:L1-icache-load-misses       128000       true  avgt    3        73.450 ?     231.916       #/op
TestFill.heap_segment_fill:L1-icache-loads             128000       true  avgt    3     13483.446 ?   42337.545       #/op
TestFill.heap_segment_fill:branch-misses               128000       true  avgt    3     86493.970 ?    8740.093       #/op
TestFill.heap_segment_fill:branches                    128000       true  avgt    3   6320125.417 ?  998773.918       #/op
TestFill.heap_segment_fill:cycles                      128000       true  avgt    3   8406053.515 ? 1319703.106       #/op
TestFill.heap_segment_fill:dTLB-load-misses            128000       true  avgt    3        34.833 ?     105.768       #/op
TestFill.heap_segment_fill:dTLB-loads                  128000       true  avgt    3       307.842 ?     754.292       #/op
TestFill.heap_segment_fill:iTLB-load-misses            128000       true  avgt    3        23.104 ?      51.968       #/op
TestFill.heap_segment_fill:iTLB-loads                  128000       true  avgt    3        55.073 ?     241.755       #/op
TestFill.heap_segment_fill:instructions                128000       true  avgt    3  29183047.682 ? 4280293.555       #/op
TestFill.heap_segment_fill:stalled-cycles-frontend     128000       true  avgt    3    707884.732 ?  176201.245       #/op


And -prof perfasm correcly show for samples = 128000 and shuffle = true shows

....[Hottest Region 1]..............................................................................
libjvm.so, Unsafe_SetMemory0 (82 bytes) 

Which are likely the branches at https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/hotspot/share/utilities/copy.cpp#L216-L244

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1732802685

From vklang at openjdk.org  Tue Aug 27 13:26:07 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 27 Aug 2024 13:26:07 GMT
Subject: Integrated: 8338765: ScheduledThreadPoolExecutor struggles with
 extremely long delays
In-Reply-To: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
References: <VRpRVL_7gxKzCproAPAC4iJz10A4Suke5rVfqSvcOe8=.61bdc287-c192-4bf4-84c9-eb5790aea251@github.com>
Message-ID: <zljf93yxNtqC0MRErciIKmF_8gPig_5TIWDsjFnhrFQ=.e682967c-bacb-4970-9fbd-db6b93a35095@github.com>

On Tue, 20 Aug 2024 18:52:23 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Unfortunately there is no good, deterministic reproducer which can be used as a regression test at this point in time.

This pull request has now been integrated.

Changeset: 414d23cb
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/414d23cb8f3c2765ac6ba2da930f2cfe7a9ad419
Stats:     24 lines in 1 file changed: 5 ins; 18 del; 1 mod

8338765: ScheduledThreadPoolExecutor struggles with extremely long delays

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20653

From ihse at openjdk.org  Tue Aug 27 13:50:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Aug 2024 13:50:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <4zUGEcC6eLmdq0wAqDCgAjsU17u6-sQNv8KZVQ8pCKc=.f8801e0b-8351-4af9-9825-70ccfa63847a@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
 <4zUGEcC6eLmdq0wAqDCgAjsU17u6-sQNv8KZVQ8pCKc=.f8801e0b-8351-4af9-9825-70ccfa63847a@github.com>
Message-ID: <AjvXrq0vcaZfPl3zBTXCSeB9JorVOByxZ-jQiqFu--I=.88e457cf-83e8-428e-a695-49c17ab5c101@github.com>

On Mon, 26 Aug 2024 09:39:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.
>
>> but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs.
> 
> Seriously? I challenge you do prove there is any effect at all. :-/
> 
> Also, there is not a "handful" of builders of static libraries. Our internal CI system builds static libraries all the time, and I for one would be glad to use these resources on more productive stuff than building all object files twice. 
> 
> Also, the intention is to enable static builds by default on GHA, once the entire process of making static builds "dirt cheap" is finished, to avoid regressions.

> Hi @magicus, perhaps the answer is both yes and no. [...] Since the mainline doesn't have the needed build changes to have the ability to link a javastatic binary, from that point of view all the static cases in the PR cannot be tested yet. 

I don't think that is correct. This PR just modifies the existing places where static and dynamic libraries are handled differently. These have been put in place by prior users of static libraries (mobile, graal), and do not require the Hermetic Java "javastatic" launcher to test.

I honestly thought this part was going to be a no-brainer, a simple preparation for future things to come. I'm surprised that it seems to be so controversial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2312613235

From mark.reinhold at oracle.com  Tue Aug 27 13:57:44 2024
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Tue, 27 Aug 2024 13:57:44 +0000
Subject: New candidate JEP: 484: Class-File API
Message-ID: <20240827135742.4415C7785D5@eggemoggin.niobe.net>

https://openjdk.org/jeps/484

  Summary: Provide a standard API for parsing, generating, and
  transforming Java class files.

- Mark

From ihse at openjdk.org  Tue Aug 27 13:58:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Aug 2024 13:58:07 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.

Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 

In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.

What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2312637272

From adam.sotona at oracle.com  Tue Aug 27 14:08:54 2024
From: adam.sotona at oracle.com (Adam Sotona)
Date: Tue, 27 Aug 2024 14:08:54 +0000
Subject: New candidate JEP: 484: Class-File API
In-Reply-To: <20240827135742.4415C7785D5@eggemoggin.niobe.net>
References: <20240827135742.4415C7785D5@eggemoggin.niobe.net>
Message-ID: <DS0PR10MB6847167D255BD8C3B92E51B18C942@DS0PR10MB6847.namprd10.prod.outlook.com>

Thank you!

Adam

From: Mark Reinhold <mark.reinhold at oracle.com>
Date: Tuesday, 27 August 2024 at 15:57
To: Adam Sotona <adam.sotona at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>, jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: New candidate JEP: 484: Class-File API
https://openjdk.org/jeps/484

  Summary: Provide a standard API for parsing, generating, and
  transforming Java class files.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240827/0ca39f34/attachment.htm>

From mcimadamore at openjdk.org  Tue Aug 27 14:11:06 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 27 Aug 2024 14:11:06 GMT
Subject: RFR: 8338489: Typo in MemorySegment doc
In-Reply-To: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
References: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
Message-ID: <LdV_zzB2vgi1t44hGUUD4rHo01v719LqBzzGNr7IjmU=.930b7439-7a5a-4394-b90e-ab1d0caf1fcf@github.com>

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to fix a typo in the `MemorySegment` docs.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263492007

From rriggs at openjdk.org  Tue Aug 27 14:11:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Aug 2024 14:11:05 GMT
Subject: RFR: 8338489: Typo in MemorySegment doc
In-Reply-To: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
References: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
Message-ID: <nr_jQlB-FL-sxShFinFEZCgqxlSJ2cptokSJYNv2ViU=.c92fb4ed-5d9f-4f5c-80e9-6ef3967b86a1@github.com>

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to fix a typo in the `MemorySegment` docs.

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263488201

From iris at openjdk.org  Tue Aug 27 14:15:05 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 27 Aug 2024 14:15:05 GMT
Subject: RFR: 8338489: Typo in MemorySegment doc
In-Reply-To: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
References: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
Message-ID: <iKk2ww-YwsVDTjCDm2MIV6P-3TdI5FCYhsjbFjA2pQw=.6be8b9ce-fbb5-4b1d-9083-42417de73a5c@github.com>

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to fix a typo in the `MemorySegment` docs.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263509002

From zzambers at openjdk.org  Tue Aug 27 14:15:08 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 27 Aug 2024 14:15:08 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
Message-ID: <dfkrfqnWOF7Mf7Ciz_GdHViivzuhST2eMIQ-q8iH2ms=.bf844897-92ec-46b8-9b3e-a08e21342337@github.com>

On Tue, 20 Aug 2024 17:34:46 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

If I am not mistaken, new test requires, that testsuite is ran as superuser (root). (Because it writes `/etc/systemd/system`, runs certain systemd commands). Should test be skipped for non-root?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2312691761

From mbaesken at openjdk.org  Tue Aug 27 14:27:07 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 27 Aug 2024 14:27:07 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
Message-ID: <LJmO2vyhlaBZWQgtn-AbJcfxUHPJqpouWw1R_t70QSk=.cf2d69c2-5b98-432f-9327-db2c86c23ca6@github.com>

On Tue, 20 Aug 2024 17:34:46 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

I added the PR to our internal build/test queue .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2312720521

From mcimadamore at openjdk.org  Tue Aug 27 14:29:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 27 Aug 2024 14:29:12 GMT
Subject: Integrated: 8338728: Misc issues in memory layout javadoc
In-Reply-To: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>
References: <aMxFG1q3NmuRXkQT-fY75hXodw_JFxyJSCpSazNqHMk=.3e9c643f-8a67-41e9-81e1-9d31f15763fb@github.com>
Message-ID: <plnWqnDFTZt0iieQSVvJBn-k0zHRDl2x1N7kg25is7w=.e5f52c33-caab-4c6e-8e36-1203986d33e8@github.com>

On Wed, 21 Aug 2024 09:41:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes two minor issues in the `MemoryLayout` javadoc:
> * the section describing dereference path talks about `P` and `P'` but then only uses `P` in the code;
> * the `ceilDiv` math on the `PathElement::sequenceElement(long, long)` is wrong, as the division returns a negative number for F < 0, which is incorrect

This pull request has now been integrated.

Changeset: b25095b0
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b25095b08e4d21b95177a5fa3fff3807b2cf81e0
Stats:     32 lines in 2 files changed: 25 ins; 0 del; 7 mod

8338728: Misc issues in memory layout javadoc

Reviewed-by: pminborg, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/20659

From eirbjo at openjdk.org  Tue Aug 27 14:36:20 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 27 Aug 2024 14:36:20 GMT
Subject: RFR: 8338931: ZipEntry.flag could be made internal to
 ZipOutputStream [v2]
In-Reply-To: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
References: <Cla3_QQjJYttxErpMiVl2wySzslpAxMmB7equtMIOxk=.00527e67-20b9-4337-92c2-ed6d8a9aae76@github.com>
Message-ID: <lBouWmnyGMrP8SOJYLxCSYa996FV-dzz1cn5wsgoYq8=.c1dbe550-a983-476d-9452-d2f7805b7d88@github.com>

> Please review this refactoring PR which moves the `ZipEntry.flag` field to `ZipOutputStream.XEntry`.
> 
> Moving this field will save four bytes from the `ZipEntry` object size and also saves an unneccessary read in `ZipFile.getZipEntry`.
> 
> Testing:
> 
> This PR is a refactoring of existing code and does not update any tests. I added the label `noreg-cleanup` to the JBS issue.
> 
> The following runs clean:
> 
> 
> make test TEST="test/jdk/java/util/zip"
> make test TEST="test/jdk/java/util/jar"
> 
> 
> Performance:
> 
> The JMH benchmark `java.util.zip.ZipFileGetEntry.getEntryHit` show a small but consistent improvement (2-3%).

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Rename XEntry.flag to XEntry.flags"
  
  This reverts commit 4ac3abfde8bcd800cf4f8ad4c5538791d9921e58.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20702/files
  - new: https://git.openjdk.org/jdk/pull/20702/files/4ac3abfd..97eec65d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20702&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20702&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20702/head:pull/20702

PR: https://git.openjdk.org/jdk/pull/20702

From mcimadamore at openjdk.org  Tue Aug 27 14:45:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 27 Aug 2024 14:45:37 GMT
Subject: RFR: 8338731: MemoryLayout::offsetHandle can return a negative
 offset [v2]
In-Reply-To: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
References: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
Message-ID: <q70US7YRM0eWaJg4nCx20SuEo5dLO8_Gh0HjgqlJTMg=.3b75950a-7293-44be-8734-9385d9b1dd8d@github.com>

> When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.
> 
> In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.
> 
> The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into offset_overflow
 - Merge branch 'master' into offset_overflow
 - Initial push

-------------

Changes: https://git.openjdk.org/jdk/pull/20662/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20662&range=01
  Stats: 23 lines in 3 files changed: 14 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20662/head:pull/20662

PR: https://git.openjdk.org/jdk/pull/20662

From sgehwolf at openjdk.org  Tue Aug 27 15:05:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Aug 2024 15:05:05 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <dfkrfqnWOF7Mf7Ciz_GdHViivzuhST2eMIQ-q8iH2ms=.bf844897-92ec-46b8-9b3e-a08e21342337@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
 <dfkrfqnWOF7Mf7Ciz_GdHViivzuhST2eMIQ-q8iH2ms=.bf844897-92ec-46b8-9b3e-a08e21342337@github.com>
Message-ID: <k-zoHJM6CDD5G55dr5PfIvcsmvuCtDjrZE8SaUnzaOU=.d108156f-9e2b-4722-99e0-aa8730527b69@github.com>

On Tue, 27 Aug 2024 14:12:40 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> If I am not mistaken, new test requires, that testsuite is ran as superuser (root). (Because it writes `/etc/systemd/system`, runs certain systemd commands). Should test be skipped for non-root?

Thanks! I can add that. FWIW, container tests are in a similar situation (applying cpu/memory limits is not allowed in rootless on cg v1) and they don't check for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2312812395

From sgehwolf at openjdk.org  Tue Aug 27 15:05:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 27 Aug 2024 15:05:05 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <LJmO2vyhlaBZWQgtn-AbJcfxUHPJqpouWw1R_t70QSk=.cf2d69c2-5b98-432f-9327-db2c86c23ca6@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
 <LJmO2vyhlaBZWQgtn-AbJcfxUHPJqpouWw1R_t70QSk=.cf2d69c2-5b98-432f-9327-db2c86c23ca6@github.com>
Message-ID: <ehBKKv4XEiJJqWqiow2YqVEIAKZBeFpd3EnOXMtRLtg=.3b7dac0b-efe5-4cbc-b3dc-b9eb2e347c2e@github.com>

On Tue, 27 Aug 2024 14:24:18 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I added the PR to our internal build/test queue .

Thanks, Matthias!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2312813813

From asotona at openjdk.org  Tue Aug 27 15:21:51 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 27 Aug 2024 15:21:51 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v3]
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: <e_4h8d6qNH5LUzVDM60f8nUZBuE8hxQB6xmG4Y8OcEM=.a3ab6c1c-de25-4911-ae58-9761d0ae567b@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

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - 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=02
  Stats: 713 lines in 165 files changed: 0 ins; 476 del; 237 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 naoto at openjdk.org  Tue Aug 27 15:37:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Aug 2024 15:37:07 GMT
Subject: RFR: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
Message-ID: <w4pyAo7_iyg8yyK8mwK627aO42VQUcGx80vxSAHoas8=.078eeef1-9bc5-4518-bd45-949a661ccfbd@github.com>

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20680#issuecomment-2312891161

From naoto at openjdk.org  Tue Aug 27 15:37:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Aug 2024 15:37:08 GMT
Subject: Integrated: 8338690: CompactNumberInstance.format incorrectly formats
 some numbers (few vs many)
In-Reply-To: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
References: <cuDbe8lf4n0bN922bcalvT3wkp4aorBSgQAO3J-mjWo=.5d011f00-9dc6-4699-bfbc-bd2b128fd141@github.com>
Message-ID: <oKb3E_mwe0BsB44LBjwnNI5W3SPvF7-wmHpaoSlpmDs=.485d2c4e-eae1-43a2-b809-531db1e3e6b3@github.com>

On Thu, 22 Aug 2024 16:14:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing an issue wrt wrong plural suffix with compact format for some locales. It was retrieving the suffix based on the value before the rounding, which ended up in wrong plural expression.

This pull request has now been integrated.

Changeset: fa4ff78b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa4ff78bd4ed029120717142eec6fb6352cb8e79
Stats:     112 lines in 3 files changed: 64 ins; 39 del; 9 mod

8338690: CompactNumberInstance.format incorrectly formats some numbers (few vs many)

Reviewed-by: joehw, rriggs, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/20680

From stuefe at openjdk.org  Tue Aug 27 15:41:08 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 27 Aug 2024 15:41:08 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace
In-Reply-To: <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <lt66he3oVLE02t3SvZ19qZ_RF5RW_fMED9Ot49xTpQE=.9f57b5d0-5cfb-448a-84ee-97b4477aa6db@github.com>
 <cE0F986OcUbR1OxtjuNd5HVYpdRnn68455Go3Vs_e5I=.7c1dce64-43fb-4137-a8e5-0f162ecc304e@github.com>
 <qJch30RBC-3iul1A9VtlFYzvjIAHJ1wYV714h848ky0=.103ca68b-b808-4ec5-ad8b-b405cfc1ce3a@github.com>
Message-ID: <j1UcU9P9d7pZmtPIqPzxL_75SA_YnqA7YsepQYYN_OU=.718a2a90-ca69-4fee-9f6f-adc7decf5d6e@github.com>

On Mon, 26 Aug 2024 13:57:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> > I don't think the costs for two address comparisons matter, not with the comparatively few deallocations that happen (few hundreds or few thousand). If deallocate is hot, we are using metaspace wrong.
> 
> MethodData does a lot of deallocations from metaspace because it's allocated racily. It might be using Metaspace wrong.

I think that should be okay. This should still be an exception. I have never seen that many deallocations happening in customer cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2312905514

From bpb at openjdk.org  Tue Aug 27 15:42:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Aug 2024 15:42:06 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
Message-ID: <QVsDKmqVRwFT9d3knt6ng7QdA8EEImbzO1ao-ESfrP8=.4647dbf0-2602-4ab9-8cab-5dd3a8a63733@github.com>

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: Modified verbiage per reviewer comment

continue;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2312907368

From eirbjo at openjdk.org  Tue Aug 27 15:51:24 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 27 Aug 2024 15:51:24 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20642/files
  - new: https://git.openjdk.org/jdk/pull/20642/files/ad40d133..eba159f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20642&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20642&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20642/head:pull/20642

PR: https://git.openjdk.org/jdk/pull/20642

From duke at openjdk.org  Tue Aug 27 15:52:05 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Tue, 27 Aug 2024 15:52:05 GMT
Subject: RFR: 8338489: Typo in MemorySegment doc
In-Reply-To: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
References: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
Message-ID: <214bequx3rdhDHnXZ2QjsodpL0wdAoQhmmo3jxuTvU0=.55ed5b54-0d1f-418a-92a8-f1e57bd188a8@github.com>

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to fix a typo in the `MemorySegment` docs.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20727#pullrequestreview-2263831754

From eirbjo at openjdk.org  Tue Aug 27 15:57:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 27 Aug 2024 15:57:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
Message-ID: <KRf4UYcAkXDKLgD_aQp6cZps0ubVcQU1YZfljO1o9ck=.59016763-578c-4f03-81ca-914b2cd76600@github.com>

On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError

JEP-277, "Enhanced Deprecation" includes the following recommendations:

*It is strongly recommended that the reasons for deprecating an API be described in that API's documentation comments. In addition, it is also recommended that potential replacement APIs be discussed and linked from the documentation.*

The reason we are deprecating this class is mainly that it became obsolete in JDK 9. I think we should say just that, and not elaborate with more details of the history of the class.

The recommended API replacement depends a bit on whether the code catches or throws `ZipError`, but also depends on whether the code needs to support running on Java 8 and catching `ZipError` there. Here I think we should mention the use case of catching ZipError when running on Java 8 and briefly point in the direction of the super class `InternalError`.

I think I would prefer to not update the class comment.

Based on the above, the PR now suggests the following documentation comment:


/**
 * Signals that an unrecoverable error has occurred.
 * @deprecated This error became obsolete in JDK 9. Use
 * {@link ZipException} instead. Code needing to catch this
 * error when running on JDK 8 or earlier releases may catch
 * the parent {@link InternalError} instead.
 */

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2312939453

From pminborg at openjdk.org  Tue Aug 27 16:27:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 27 Aug 2024 16:27:09 GMT
Subject: Integrated: 8338489: Typo in MemorySegment doc
In-Reply-To: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
References: <2fgYszIRZZiCH3blGrnGrnfQ0yVGjaz0aIAbcjDxKUQ=.f44e795d-1e1a-4318-a160-cad75c58d6ac@github.com>
Message-ID: <UzSLkwURgmpGt6UQjcejd6F1un5yHWWRUF5Ty9pciwI=.63837634-0bfb-46a3-a7a4-f1b640cce996@github.com>

On Tue, 27 Aug 2024 10:42:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This trivial PR proposes to fix a typo in the `MemorySegment` docs.

This pull request has now been integrated.

Changeset: 2e96f159
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e96f159aaee782a627902c04dbd51daa3406ab5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8338489: Typo in MemorySegment doc

Reviewed-by: rriggs, mcimadamore, iris

-------------

PR: https://git.openjdk.org/jdk/pull/20727

From naoto at openjdk.org  Tue Aug 27 16:34:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Aug 2024 16:34:05 GMT
Subject: RFR: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <xaGM4_RhRmC7bFqNK-yi50oXRjRrw7kLhjAHQWcJp9g=.cffbbd29-2cd6-465d-9bdb-e13abaa135f6@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

LGTM. Thanks for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20368#pullrequestreview-2263946190

From archie.cobbs at gmail.com  Tue Aug 27 16:49:26 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 27 Aug 2024 11:49:26 -0500
Subject: New candidate JEP: 484: Class-File API
In-Reply-To: <20240827135742.4415C7785D5@eggemoggin.niobe.net>
References: <20240827135742.4415C7785D5@eggemoggin.niobe.net>
Message-ID: <CANSoFxvsxQa8-W5R9Pv=RpefPHMCHQkw5ZKGmivCfxdWq3mDSA@mail.gmail.com>

Question... would it be appropriate for this JEP to mention that support
for older-than-current classfile versions is an explicit non-goal?

Otherwise I think there could be many repeats of this discussion
<https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127982.html>
from the other day.

To be clear, I don't disagree with the design choice, I just think it might
be worthwhile to address that point directly and clarify the thinking
behind it so there's no ambiguity.

As it's written today, a casual reading of the JEP comes across as if we're
talking about a great new JDK-sanctioned tool with state of the art design
that will help get all of the classfile manipulation libraries on the same
page to allow analysis/transformation of any class file on the classpath.
Or at least, it doesn't do anything to dispel that notion (unless I'm
missing something).

-Archie

On Tue, Aug 27, 2024 at 8:58?AM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> https://openjdk.org/jeps/484
>
>   Summary: Provide a standard API for parsing, generating, and
>   transforming Java class files.
>
> - Mark



-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240827/f3bc4f78/attachment.htm>

From galder at openjdk.org  Tue Aug 27 17:12:04 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 27 Aug 2024 17:12:04 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <jgrN6hGqHRGDUm8KHX_vpA-Ce9ayHtlTMsfyZyP_pp8=.1f057307-2ae1-4d62-9ddd-4c85b3cefba5@github.com>

On Tue, 9 Jul 2024 12:07:37 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Working on it

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2313102213

From coleenp at openjdk.org  Tue Aug 27 17:27:19 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Aug 2024 17:27:19 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v3]
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <gksmhbijVVMK2RpMKHJD1bAyCxw4J9srhwZBp_NQN-o=.33986263-c9f5-4e38-9b9e-d220706299ca@github.com>

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - With JDK-8338929 we don't need is_in_class_space().
 - Merge branch 'master' into anon
 - Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.
 - 8338526: Don't store abstract and interface Klasses in class metaspace

-------------

Changes: https://git.openjdk.org/jdk/pull/19157/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=02
  Stats: 79 lines in 19 files changed: 30 ins; 11 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/19157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19157/head:pull/19157

PR: https://git.openjdk.org/jdk/pull/19157

From coleenp at openjdk.org  Tue Aug 27 17:27:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Aug 2024 17:27:20 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v3]
In-Reply-To: <Xi9MiXjLHkqFeeUpKJNsZylEe6V77CHcVLxm0GdZ5Wk=.6f66052d-ce0d-442a-b29f-c2f20d90fcaa@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <Xi9MiXjLHkqFeeUpKJNsZylEe6V77CHcVLxm0GdZ5Wk=.6f66052d-ce0d-442a-b29f-c2f20d90fcaa@github.com>
Message-ID: <JlxXa7o8EcqMY3YslUuz9xTHTKazCa2pCPeY6pPHICk=.4ee8fba3-d4e8-4c5d-a0db-5b554e88adb2@github.com>

On Fri, 23 Aug 2024 06:13:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - With JDK-8338929 we don't need is_in_class_space().
>>  - Merge branch 'master' into anon
>>  - Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.
>>  - 8338526: Don't store abstract and interface Klasses in class metaspace
>
> src/hotspot/share/oops/klass.hpp line 205:
> 
>> 203: 
>> 204:   void* operator new(size_t size, ClassLoaderData* loader_data, size_t word_size, TRAPS) throw();
>> 205: 
> 
> Oh ArrayKlass never used this? Its good to move it to InstanceKlass.

ArrayKlass has its own operator new.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1733266271

From liach at openjdk.org  Tue Aug 27 17:33:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Aug 2024 17:33:04 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
Message-ID: <KIeguGjwOo-1sEx5-Jq0kXVcyv0mK0ibmIF8DRlIusw=.f382c452-272e-46bc-be6c-aaea011e3c1a@github.com>

On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError

The updated deprecation specification looks good to me. I will review the CSR when you update it. Needs Lance or another engineer in the area to confirm too.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20642#pullrequestreview-2264064055

From naoto at openjdk.org  Tue Aug 27 17:38:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Aug 2024 17:38:03 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622
 and JDK-8331932 [v2]
In-Reply-To: <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
 <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
Message-ID: <V9dy4_ypuKDSujC_iEzze5vDMh2xpD1FeZoT0U8NweQ=.bb67487a-4294-4a95-bc05-99abdfe49163@github.com>

On Mon, 26 Aug 2024 14:00:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
>> 
>> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final

LGTM. Thank you for the continued effort for the Locale performance improvement, Claes!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20713#pullrequestreview-2264075104

From jiangli at openjdk.org  Tue Aug 27 17:56:03 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 27 Aug 2024 17:56:03 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <3fVMocxS8IOcl2YdBhyFtAd7U8oUkR_arFRFKQNrktI=.e896558e-9e20-49bc-a298-13de3e0f3f11@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

Marked as reviewed by jiangli (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2264106008

From jiangli at openjdk.org  Tue Aug 27 17:56:04 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 27 Aug 2024 17:56:04 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
Message-ID: <8qxU0njJxPJtQiUvMkU2NlOY7xhV3xz17YBXPSDi11E=.69e5a2eb-96fd-462c-9f5d-b9af254701fa@github.com>

On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.
> 
> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 
> 
> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.
> 
> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.

We had a zoom discussion with @magicus and others on this PR (as part of regular hermetic Java meeting) this morning. @magicus mentioned that he has a PR in progress with the static linking part, which helps address my specific concern.

> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.

Yes, the .o files are recompiled for creating the static libraries currently. That causes observable large overhead in terms of both memory and build duration for building JDK itself. In real world constraint environments, both overhead are problematic and cause build issues. So steps toward building the `.so` and `.a` using the same set of `.o` object files should be one of our end goals (just to re-iterate its importance), but would be "ok" without during the initial phases when we are building/integrating hermetic/static support in JDK mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2313180693

From aph-open at littlepinkcloud.com  Tue Aug 27 18:09:18 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 27 Aug 2024 19:09:18 +0100
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <Ze9z13FjRDM1rVQY4obG-9WHoTFTFZ7e3JzcD89kbxs=.9c6c5d29-6733-4047-a1a9-d97a7542f0b9@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <Ze9z13FjRDM1rVQY4obG-9WHoTFTFZ7e3JzcD89kbxs=.9c6c5d29-6733-4047-a1a9-d97a7542f0b9@github.com>
Message-ID: <04927c18-5f6d-4390-baf9-312653eaa76e@littlepinkcloud.com>

On 8/27/24 12:13, Jatin Bhateja wrote:
> Hi @vamsi-parasa ,  Kindly also add a JMH micro benchmark, I did a first
>   run and see around 4% performance drop with attached micro on Sapphire
> Rapids.
> [test.txt](https://github.com/user-attachments/files/16761142/test.txt)

If I had to guess, that's because there are no infinities and no NaNs
so HotSpot will perfectly predict .

Given that this "normal" execution is the expected use of tanh(), it
seems to me that this intrinsic won't help in the usual case, and may
make things worse.


From sviswanathan at openjdk.org  Tue Aug 27 18:30:08 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 27 Aug 2024 18:30:08 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <zujPalHzsKSvw0ju3Bu8Xq0oPVTlElhGyaQU-NAs1og=.51c11bab-df1a-460c-a2df-b9df703b6b78@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/x86/x86.ad line 1773:

> 1771:         return false;
> 1772:       }
> 1773:       if (bt == T_LONG && !VM_Version::supports_avx512vl()) {

we should be able to support bt == T_LONG for 512 bit irrespective of avx512vl.

src/hotspot/cpu/x86/x86.ad line 1953:

> 1951:        if (UseAVX < 1 || size_in_bits < 128 || (size_in_bits == 512 && !VM_Version::supports_avx512bw())) {
> 1952:          return false;
> 1953:        }

UseAVX < 1 could be written as UseAVX == 0. Could we not do register version for size_in_bit < 128?

src/hotspot/cpu/x86/x86.ad line 1962:

> 1960:         return false; // Implementation limitation
> 1961:       }
> 1962:       break;

Could we not do register version for size_in_bit < 128?

src/hotspot/cpu/x86/x86.ad line 2143:

> 2141:       if (is_subword_type(bt) && !VM_Version::supports_avx512bw()) {
> 2142:         return false; // Implementation limitation
> 2143:       }

UMinV and UMaxV are supported on AVX1, AVX2 platform.

src/hotspot/cpu/x86/x86.ad line 2155:

> 2153:         return false; // Implementation limitation
> 2154:       }
> 2155:       return true;

Byte/Short saturating vector add is supported for AVX1, AVX2 platforms. Could we not do register version for size_in_bit < 128?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733330892
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733333203
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733333608
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733336005
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733338300

From lancea at openjdk.org  Tue Aug 27 19:09:04 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Aug 2024 19:09:04 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
Message-ID: <urjYLS8ejxEwN5ZbJwIH-8IIkq93LjcgOuspPlLamg8=.1d190db5-67bd-4990-87d3-a2405a897ae1@github.com>

On Tue, 27 Aug 2024 15:51:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError

src/java.base/share/classes/java/util/zip/ZipError.java line 34:

> 32:  * error when running on JDK 8 or earlier releases may catch
> 33:  * the parent {@link InternalError} instead.
> 34:  * @author  Dave Bristor

As mentioned in an earlier PR comment, the verbiage regarding 


 * Code needing to catch this
 * error when running on JDK 8 or earlier releases may catch
 * the parent {@link InternalError} instead.


Should be in an RN for the JDK release that this PR is approved for, not the proposed javadoc.  Additionally, an RN could  be added  to a future JDK 8 update release after the PR is committed to mainline.

The javadoc should be focused on the current JDK release, not the prior history of this Class


I would suggest something similar to:



 * @deprecated ZipError is deprecated and subject to removal in a
 *  future release. This class is obsolete. Use  {@link ZipException} instead.


or 


 * @deprecated ZipError is deprecated and subject to removal in a
 *  future release. This Error is obsolete and no longer thrown. Use  {@link ZipException} instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1733266739

From eirbjo at openjdk.org  Tue Aug 27 19:52:04 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 27 Aug 2024 19:52:04 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <urjYLS8ejxEwN5ZbJwIH-8IIkq93LjcgOuspPlLamg8=.1d190db5-67bd-4990-87d3-a2405a897ae1@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
 <urjYLS8ejxEwN5ZbJwIH-8IIkq93LjcgOuspPlLamg8=.1d190db5-67bd-4990-87d3-a2405a897ae1@github.com>
Message-ID: <cMrbsvYcO-3yEfvK2QautX13D-bMVBqn5PmG9tLJ0hY=.c9fab8a0-52a3-49ca-97f4-1202530b0d93@github.com>

On Tue, 27 Aug 2024 17:24:42 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The javadoc should be focused on the current JDK release, not the prior history of this Class

Makes sense, let's focus on the current release.

> ```
>  * @deprecated ZipError is deprecated and subject to removal in a
>  *  future release. This class is obsolete. Use  {@link ZipException} instead.
> ```

The leading sentence here seems redundant, since it mostly just repeats the heading generated by javadoc:

**Deprecated, for removal: This API element is subject to removal in a future version**
_ZipError is deprecated and subject to removal in a future release. This Error is obsolete and no longer thrown. Use ZipException instead._

What do you think of dropping that first sentence, such that the rendered result would be:

**Deprecated, for removal: This API element is subject to removal in a future version**
_ZipError is obsolete and is no longer thrown. Use ZipException instead._

(One might argue that *is no longer thrown* hints at different behavior in past releases, but I still think it helps to clarify that code running on the current release need not worry about catching this error)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1733433176

From psandoz at openjdk.org  Tue Aug 27 20:03:07 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 27 Aug 2024 20:03:07 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v6]
In-Reply-To: <SbWS4YOn-u1WfNT4AwWVAvEGa1z_YDsX2DnQ9M0wWDE=.39687e9e-d72c-4151-a835-7645b5670c83@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <SbWS4YOn-u1WfNT4AwWVAvEGa1z_YDsX2DnQ9M0wWDE=.39687e9e-d72c-4151-a835-7645b5670c83@github.com>
Message-ID: <xlVrS0Hg4mltPvLyPNXa1idkQqwmcmPo1KDmrdorOF4=.e5be0b95-9cac-4cb9-b3aa-b8a6f4c85249@github.com>

On Tue, 27 Aug 2024 09:58:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

I think we should leave the fallback expression as `vec2.rearrange(vec1.toShuffle(), vec3);`, lets address that separately if needed. Otherwise, you have introduced an additional code path that requires more explicit testing.

My comment was related to understanding what `SelectFromTwoVectorNode::Ideal` and `VectorRearrangeNode::Ideal` are doing - the former lowers, if needed, into the rearrange expression and the latter adjusts, if needed, the index vector (a comment describing this transformation would be useful, like you have in the former method).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2313401788

From psandoz at openjdk.org  Tue Aug 27 20:28:04 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 27 Aug 2024 20:28:04 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
Message-ID: <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>

On Tue, 27 Aug 2024 10:38:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into fill-performance
>  - Fix typo
>  - Add a comment about the old switch type
>  - Remove unused import
>  - Reduce kick-in size and add test
>  - Initial implementation

How fast do we need to be here given we are measuring in a few nanoseconds per operation? 

What if the goal is not to regress from say explicitly filling in a small sized segment or a comparable array (e.g., < 8 bytes) then maybe a loop suffices and the code is simple?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2313446118

From lancea at openjdk.org  Tue Aug 27 20:40:03 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Aug 2024 20:40:03 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <cMrbsvYcO-3yEfvK2QautX13D-bMVBqn5PmG9tLJ0hY=.c9fab8a0-52a3-49ca-97f4-1202530b0d93@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
 <urjYLS8ejxEwN5ZbJwIH-8IIkq93LjcgOuspPlLamg8=.1d190db5-67bd-4990-87d3-a2405a897ae1@github.com>
 <cMrbsvYcO-3yEfvK2QautX13D-bMVBqn5PmG9tLJ0hY=.c9fab8a0-52a3-49ca-97f4-1202530b0d93@github.com>
Message-ID: <18kEXGWSjX_iG1mwRvMOfpdwaJpynrvOzj9FPnba9J8=.9d774b99-5f73-4b6f-9c0f-9540d2b37bd2@github.com>

On Tue, 27 Aug 2024 19:49:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> > The javadoc should be focused on the current JDK release, not the prior history of this Class
> 
> Makes sense, let's focus on the current release.
> 
> > ```
> >  * @deprecated ZipError is deprecated and subject to removal in a
> >  *  future release. This class is obsolete. Use  {@link ZipException} instead.
> > ```
> 
> The leading sentence here seems redundant, since it mostly just repeats the heading generated by javadoc:
> 
> **Deprecated, for removal: This API element is subject to removal in a future version** _ZipError is deprecated and subject to removal in a future release. This Error is obsolete and no longer thrown. Use ZipException instead._

True, I kept it as it aligns with what was done for SecurityManager and is sightly more specific. as to the element being subject to removal.

That being said,  I am OK with dropping it if we get approval in the CSR.

> 
> What do you think of dropping that first sentence, such that the rendered result would be:
> 
> **Deprecated, for removal: This API element is subject to removal in a future version** _ZipError is obsolete and is no longer thrown. Use ZipException instead._
> 
> (One might argue that _is no longer thrown_ hints at different behavior in past releases, but I still think it helps to clarify that code running on the current release need not worry about catching this error)

As I mentioned above, I am OK, with dropping it

Other options could be:

_ZipError is obsolete and is no longer used.  ZipException should be used instead_

or

_ZipError is no longer used and is obsolete. ZipException should be used instead_

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1733485970

From duke at openjdk.org  Tue Aug 27 20:45:50 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 27 Aug 2024 20:45:50 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v2]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <0XmlykNZ0boUrQnQf-n8QEyYFidr_By4OQabNeX0e_E=.6f2eb39c-9a25-4568-8d45-95fdbf7e051a@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:

 - Eliminate cache
 - Rework using facilities found in ObjectStreamClass
   
   This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/e7334655..1d8f1b22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=00-01

  Stats: 620 lines in 6 files changed: 187 ins; 427 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From duke at openjdk.org  Tue Aug 27 21:25:40 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 27 Aug 2024 21:25:40 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <WDToV3EsXlAGIbz6og4wnktMZIQZ7GxL8IGJvTM8EJA=.5df48925-fca6-4d7f-b241-60d870e355d6@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <WDToV3EsXlAGIbz6og4wnktMZIQZ7GxL8IGJvTM8EJA=.5df48925-fca6-4d7f-b241-60d870e355d6@github.com>
Message-ID: <5RUXvY7Tb8B_QYxg0iLNaC5d6fcNMdHUYXdEzyBoQ_U=.19f4d853-620a-459c-acc1-d57bfd6fb7bc@github.com>

On Mon, 26 Aug 2024 15:47:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> This PR doesn't include any additional tests. It is often appropriate to add more regression testing when introducing a new implementation of a method.

Thank You Joe for the suggestion. Will add more tests. (This PR passes the tier-1 tanh tests in the HyperbolicTests.Java)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2313603036

From jlu at openjdk.org  Tue Aug 27 21:34:51 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 Aug 2024 21:34:51 GMT
Subject: RFR: 8339126: JNI exception pending in Inflater.c
Message-ID: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>

This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/20735/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20735&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339126
  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20735/head:pull/20735

PR: https://git.openjdk.org/jdk/pull/20735

From bchristi at openjdk.org  Tue Aug 27 22:02:53 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 27 Aug 2024 22:02:53 GMT
Subject: RFR: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource
Message-ID: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>

The InterruptibleIO feature (which was only on Solaris) was removed some time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444).

Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed.

-------------

Commit messages:
 - remove handling for defunct InterruptedIOException

Changes: https://git.openjdk.org/jdk/pull/20736/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338716
  Stats: 33 lines in 1 file changed: 0 ins; 30 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20736/head:pull/20736

PR: https://git.openjdk.org/jdk/pull/20736

From bchristi at openjdk.org  Tue Aug 27 22:02:53 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 27 Aug 2024 22:02:53 GMT
Subject: RFR: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource
In-Reply-To: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
References: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
Message-ID: <449ltPoObhBi_9YF-32pDpw0Km7FMQZdf5IL4qkeyOw=.aa36dc92-52c2-4b5d-996b-d72bb433671e@github.com>

On Tue, 27 Aug 2024 21:57:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> The InterruptibleIO feature (which was only on Solaris) was removed some time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444).
> 
> Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed.

Automated test job is in progress, and looks good so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20736#issuecomment-2313648728

From smarks at openjdk.org  Tue Aug 27 22:04:24 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 27 Aug 2024 22:04:24 GMT
Subject: RFR: 8325679: Optimize ArrayList subList sort [v4]
In-Reply-To: <FSHaxCV28GG6SlPO3aigBJsIjrTGQ4-FT1TtUzhhEmA=.4722142b-a1d8-4603-b7db-ed5e82203f42@github.com>
References: <DruTgFzQmTSLjZHTdyZFqLJ48CYFLYuhz-fpG0rQXnc=.de8bb8ac-eab4-4f05-8f73-5ca6a5c7b727@github.com>
 <sAXN5Z3tshLGru7GQLw7KAXqGvwwJQo8_K69VVL7luw=.f9055ab3-4316-4b52-897d-a6bde99400bd@github.com>
 <FSHaxCV28GG6SlPO3aigBJsIjrTGQ4-FT1TtUzhhEmA=.4722142b-a1d8-4603-b7db-ed5e82203f42@github.com>
Message-ID: <OBFd1gBiRw8ozxGcq0TwT9nEQ8FxrXUmx8XdQmsVk1k=.1720c507-499b-45f3-95b8-c6b9568e159f@github.com>

On Tue, 9 Jul 2024 18:53:44 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Attila Szegedi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove test
>
> Keep it open, please.

@szegedi

Hi Attila, sorry for the long delay on this. If you update the PR per @liach's comment on 2024-07-09, I can sponsor it. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17818#issuecomment-2313653413

From duke at openjdk.org  Tue Aug 27 22:07:20 2024
From: duke at openjdk.org (duke)
Date: Tue, 27 Aug 2024 22:07:20 GMT
Subject: RFR: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <-nxY7JXQtAocSZVASYW0hSst1zaTBZwuRXvYRnNAl3k=.2c61ba9c-dc52-4e0b-a714-a81664cba773@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

@wenshao 
Your change (at version 9d7cc54c449d4e12d0eb30c103e8aa3aaf206b6d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20368#issuecomment-2313656091

From duke at openjdk.org  Tue Aug 27 22:13:23 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 22:13:23 GMT
Subject: Integrated: 8337832: Optimize datetime toString
In-Reply-To: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
References: <TLkaIdb34cN-pLu-0oMUEuFXLJUFj0JFjxMESVQKOfA=.feb119ea-cf04-465f-9073-805bc78982d7@github.com>
Message-ID: <1QMb2OTAXUcnlSAbMRE4iVJy1NEfZME0vWgluOpmwhM=.2993e5e6-5c6f-4888-97e6-b9a881d7c538@github.com>

On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Similar to PR #20321, this improves performance by providing a method that passes in a StringBuilder to avoid unnecessary object allocation.

This pull request has now been integrated.

Changeset: 449ca2c3
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/449ca2c3c1cb5d056a2d259be2ff069ba2a36b80
Stats:     32 lines in 4 files changed: 23 ins; 1 del; 8 mod

8337832: Optimize datetime toString

Reviewed-by: scolebourne, liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20368

From liach at openjdk.org  Tue Aug 27 22:24:02 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Aug 2024 22:24:02 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
Message-ID: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>

`TypeKind` enum constants are named in wrong code style; correct them before finalization.

Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.

-------------

Commit messages:
 - 8339115: Rename TypeKind enum constants to follow code style

Changes: https://git.openjdk.org/jdk/pull/20737/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339115
  Stats: 664 lines in 31 files changed: 70 ins; 14 del; 580 mod
  Patch: https://git.openjdk.org/jdk/pull/20737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20737/head:pull/20737

PR: https://git.openjdk.org/jdk/pull/20737

From duke at openjdk.org  Tue Aug 27 22:26:21 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 27 Aug 2024 22:26:21 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
 <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>
Message-ID: <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>

On Tue, 27 Aug 2024 10:54:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp line 437:
>> 
>>> 435:   __ mulpd(xmm1, xmm1);
>>> 436:   __ movdqu(xmm4, ExternalAddress(pv + 32), r11 /*rscratch*/);
>>> 437:   __ mulpd(xmm2, xmm1);
>> 
>> I would encourage either you add detailed comments or give meaningful names to the registers to ease the review process.
>
> I agree, this is all rather obscure. Ideally the same names that are used in wherever this comes from.
> 
> Where does the algorithm come from? What are its accuracy guarantees?
> 
> In addition, given the rarity of hyperbolic tangents in Java applications, do we need this?

@theRealAph, this implementation is based on Intel libm math library and meets the accuracy requirements. The algorithm is provided in the comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1733589125

From sviswanathan at openjdk.org  Tue Aug 27 22:28:21 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 27 Aug 2024 22:28:21 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <4k6vX8rkREK9CYMZjs0KfHikLJJ1NWbMtWYYzLcYPc0=.53547148-1abb-4a7f-8238-944c13a26304@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/x86/x86.ad line 10635:

> 10633: %}
> 10634: 
> 10635: instruct saturating_unsigned_add_reg_avx(vec dst, vec src1, vec src2, vec xtmp1, vec xtmp2, vec xtmp3, vec xtmp4)

Should the temp here and all the places related to !avx512vl() be legVec instead of vec?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733588147

From ihse at openjdk.org  Tue Aug 27 22:31:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Aug 2024 22:31:15 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
Message-ID: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>

Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.

We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

-------------

Commit messages:
 - Fix debug builds
 - Try fixing static builds on zero
 - Fix zero
 - Fix libfallbackLinker
 - Also update native tests
 - 8339120: Use more fine-granular gcc unused warnings

Changes: https://git.openjdk.org/jdk/pull/20733/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339120
  Stats: 50 lines in 17 files changed: 28 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Tue Aug 27 22:31:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 27 Aug 2024 22:31:16 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <Bf2Hw0qejuqqPoPfXd_kq8xTGvpL9LVrWfXNTUcjJno=.705d1175-43bd-4844-bbf3-740c4caceb8b@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

If at some point the diff seems larger than needed, it could be that I have reordered things where the alphabetic order had capsized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20733#issuecomment-2313681273

From duke at openjdk.org  Tue Aug 27 22:37:19 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 22:37:19 GMT
Subject: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong
 [v4]
In-Reply-To: <L3_IsNQ19zHuB7ycVYN7DIytFhC_yanXu_tKyjz8JWI=.5413ebeb-5c38-4287-9391-41b6e9a40ed7@github.com>
References: <tc-wIpp8PRgt_KxxoJ8LMiLTYFXA3yTZ-ypI4aK4ttM=.dd9adc4a-b350-41c4-ab21-eeb74ac0ba35@github.com>
 <L3_IsNQ19zHuB7ycVYN7DIytFhC_yanXu_tKyjz8JWI=.5413ebeb-5c38-4287-9391-41b6e9a40ed7@github.com>
Message-ID: <1jpFSNK1aQ0WYTRvGZIKp8KLlBcya4h520AH8RiwPB0=.740a1fb7-c630-4410-a09a-1b448a8da9ae@github.com>

On Tue, 23 Jul 2024 02:48:56 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Currently, about 25% of the time spent by the Integer.parseInt and Long.parseLong methods is spent on the Character.digit method.
>> 
>> The Character.digit method is common to all radixes. We can use a digit method optimized for Latin1 encoding radix 10 to improve the performance of Integer.parseInt and Long.parseLong methods.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add description for DECIMAL_DIGITS

@jddarcy  do I need to make more improvements to this PR? Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20168#issuecomment-2313690417

From jjg at openjdk.org  Tue Aug 27 22:41:18 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 27 Aug 2024 22:41:18 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
In-Reply-To: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
Message-ID: <7_wHsVuwcRF8Q9t7p3ZKCW0aegJceddguT4ud21ScO0=.5cbe52f1-4cb7-45e1-afba-50004c49aee3@github.com>

On Tue, 27 Aug 2024 22:15:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
> 
> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
> 
> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
> 
> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.

Changes to JSpec.java look OK.

No comment on other changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20737#pullrequestreview-2264584894

From darcy at openjdk.org  Tue Aug 27 22:47:18 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Aug 2024 22:47:18 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <5RUXvY7Tb8B_QYxg0iLNaC5d6fcNMdHUYXdEzyBoQ_U=.19f4d853-620a-459c-acc1-d57bfd6fb7bc@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <WDToV3EsXlAGIbz6og4wnktMZIQZ7GxL8IGJvTM8EJA=.5df48925-fca6-4d7f-b241-60d870e355d6@github.com>
 <5RUXvY7Tb8B_QYxg0iLNaC5d6fcNMdHUYXdEzyBoQ_U=.19f4d853-620a-459c-acc1-d57bfd6fb7bc@github.com>
Message-ID: <k9BNHWV60-h0--5q9V-wmC9APFRNTz4DDla8LSwWcko=.fb51e30e-215a-4bb5-b543-210b227c5a0b@github.com>

On Tue, 27 Aug 2024 21:22:26 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> > This PR doesn't include any additional tests. It is often appropriate to add more regression testing when introducing a new implementation of a method.
> 
> Thank You Joe for the suggestion. Will add more tests. (This PR passes the tier-1 tanh tests in the HyperbolicTests.Java)

Yes @vamsi-parasa ; running that test is a good backstop and it is written to be applicable to any implementation of {sinh, cosh, tanh} that meet the general quality-of-implementation criteria for java.lang.Math. To be explicit, the WorstCaseTests.java file, and for good measure all the java.lang.Math tests, should also be run too for a change like this.

For a hypothetical example, if an intrinsic used different polynomials for different ranges of the input, it would be a reasonable regression tests _for that implementation_ to probe around the boundary of the transition between the polynomials to make sure the monotonicity requirements were being met.

That kind of check could be written to be generally applicable and be suitable for a regression tests in java/lang/Math or could be suitable for a regression test in the HotSpot area. HTH

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2313699961

From jiangli at openjdk.org  Tue Aug 27 23:17:19 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 27 Aug 2024 23:17:19 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
Message-ID: <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>

On Tue, 27 Aug 2024 13:55:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.
> 
> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 
> 
> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.
> 
> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.

@magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2313737779

From john.r.rose at oracle.com  Tue Aug 27 23:44:28 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 27 Aug 2024 16:44:28 -0700
Subject: RFR: 8338023: Support two vector selectFrom API [v5]
In-Reply-To: <2_P1qPMS46tgh4RUSuitcjXYnd0koS_BxfRRRmj79EY=.c3baeeaa-87f7-47d4-bc70-ae2afd9de745@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <7e5pWnvjqk-dQYNeaZjFzXcd5WlzniZPl5T4l1rKQGE=.0882bcd4-e307-4a29-aa41-5496ee029a60@github.com>
 <2_P1qPMS46tgh4RUSuitcjXYnd0koS_BxfRRRmj79EY=.c3baeeaa-87f7-47d4-bc70-ae2afd9de745@github.com>
Message-ID: <DFF8CEF7-85CD-4D26-868D-9059A48D6127@oracle.com>

On 23 Aug 2024, at 15:33, Paul Sandoz wrote:

> The float/double conversion bothers me, not suggesting we do something about it here, noting down for any future conversation on shuffles.

Yes, it?s a pain which is noticeable in the vector/shuffle conversions.
In the worst case it adds dynamic reformatting operations to get from
the artificially ?uniform? float/double index format into the real
format the hardware requires.  As a workaround, the user could convert
the float/double payloads bitwise into int/long payloads, and then
do the shuffling in the uniform int/long API, later reconverting
back to float/double after the payloads are reordered.  Those
conversions don?t actually use any dynamic operations.

For prototyping, it seems fine to take the hit and ignore the fact
that the index vectors are in an odd (though ?uniform?) format.

From duke at openjdk.org  Tue Aug 27 23:49:50 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 27 Aug 2024 23:49:50 GMT
Subject: RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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 nine additional commits since the last revision:

 - Speed up Instant.toString using JavaTimeAccess
 - add JavaTimeAccess SharedSecrets
 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
 - breaking out the printNano methods
 - copyright
 - Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
   
   Co-authored-by: Stephen Colebourne <scolebourne at joda.org>
 - 1. fix handle fraction == -1
   2. Split two methods to make codeSize less than 325
 - add comment
 - optimize format instant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/ccbd6b5a..df2a13d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20353&range=05-06

  Stats: 40550 lines in 1327 files changed: 22559 ins; 11677 del; 6314 mod
  Patch: https://git.openjdk.org/jdk/pull/20353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353

PR: https://git.openjdk.org/jdk/pull/20353

From duke at openjdk.org  Wed Aug 28 00:13:23 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 28 Aug 2024 00:13:23 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v2]
In-Reply-To: <0XmlykNZ0boUrQnQf-n8QEyYFidr_By4OQabNeX0e_E=.6f2eb39c-9a25-4568-8d45-95fdbf7e051a@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <0XmlykNZ0boUrQnQf-n8QEyYFidr_By4OQabNeX0e_E=.6f2eb39c-9a25-4568-8d45-95fdbf7e051a@github.com>
Message-ID: <6YLjR5SPNQyj7R5cfnu4uYVhRLhUkSDl-aJeYwfXHag=.eb7bdd5e-6ca6-4aff-a3e7-aa21b1819ea8@github.com>

On Tue, 27 Aug 2024 20:45:50 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.

No?need to?create?multiple `MethodHandles.Lookup`?objects in?the?static?initialiser:

src/java.base/share/classes/java/io/ObjectStreamDefaultSupport.java line 50:

> 48:             DRO_HANDLE = MethodHandles.lookup().findStatic(ObjectStreamDefaultSupport.class, "defaultReadObject", droType);
> 49:             MethodType dwoType = MethodType.methodType(void.class, ObjectStreamClass.class, Object.class, ObjectOutputStream.class);
> 50:             DWO_HANDLE = MethodHandles.lookup().findStatic(ObjectStreamDefaultSupport.class, "defaultWriteObject", dwoType);

Suggestion:

            var lookup = MethodHandles.lookup();
            MethodType droType = MethodType.methodType(void.class, ObjectStreamClass.class, Object.class, ObjectInputStream.class);
            DRO_HANDLE = lookup.findStatic(ObjectStreamDefaultSupport.class, "defaultReadObject", droType);
            MethodType dwoType = MethodType.methodType(void.class, ObjectStreamClass.class, Object.class, ObjectOutputStream.class);
            DWO_HANDLE = lookup.findStatic(ObjectStreamDefaultSupport.class, "defaultWriteObject", dwoType);

-------------

PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2264666938
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1733657524

From sviswanathan at openjdk.org  Wed Aug 28 00:15:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 28 Aug 2024 00:15:19 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <QfgwwVXsYjjdGR65TfJJZjAXTS81OUyP-WOvWRRmfBk=.9e3ff6c8-201e-4b0e-93a2-9de753904279@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
 <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
 <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>
 <QfgwwVXsYjjdGR65TfJJZjAXTS81OUyP-WOvWRRmfBk=.9e3ff6c8-201e-4b0e-93a2-9de753904279@github.com>
Message-ID: <agai02WarwvrKhvnB04UiBvmolhjJaMc6y8xk0xjytU=.def3d32b-7250-4a53-a4d3-679997edd22c@github.com>

On Thu, 15 Aug 2024 06:59:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> its usage in existing patch is limited to [type comparison.](https://github.com/openjdk/jdk/pull/20507/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1542)
>> 
>> Ah, that makes sense to me. I took a closer look and I think since the patch is creating a `VectorReinterpret` node after unsigned vector nodes, it might be able to avoid cases where the type might get filtered/joined, like with `PhiNode::Value`. That might lead to errors since `empty_type->filter(other_type) == TOP`. It's unfortunate that it's not really possible to disambiguate between an empty type and an unsigned range, which would allow us to solve this elegantly.
>
> Hey @jaskarth , Central idea behind introducing VectorReinterpretNode after unsigned vector IR is to facilitate unboxing-boxing optimization, this explicit reinterpretation ensures type compatibility between value being boxed and box type which is always signed vector types.
> 
> As mentioned previously my plan is to address is handle  value range related concerns in a follow up patch along with intrisification and auto-vectorization of newly created scalar saturating IR, this patch is not generating scalar IR with newly defined unsigned types.

Wonder if it would have been simpler if we added unsigned vector operators like Op_SaturatingUnsignedAddVB etc. We are not adding unsigned data types to Java, only supporting unsigned (saturating) operations on existing signed integral types.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1733659843

From lancea at openjdk.org  Wed Aug 28 00:20:18 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Aug 2024 00:20:18 GMT
Subject: RFR: 8339126: JNI exception pending in Inflater.c
In-Reply-To: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
References: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
Message-ID: <ZdhuGdIOQRnN6W-tYIg-Vz7KyaB74fbkiRcLwEOQohk=.ab2e5318-412b-4d03-929d-ae2f388210d6@github.com>

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestreview-2264674014

From archie.cobbs at gmail.com  Wed Aug 28 01:21:28 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 27 Aug 2024 20:21:28 -0500
Subject: Namespace Prefix Issue in XML to XSL Transformation
In-Reply-To: <SA1PR15MB52849997884D00D57E8880DC9D942@SA1PR15MB5284.namprd15.prod.outlook.com>
References: <SA1PR15MB52849997884D00D57E8880DC9D942@SA1PR15MB5284.namprd15.prod.outlook.com>
Message-ID: <CANSoFxtTwzafZ8hk5qt_gQFB6Vw4gCCNiiLuSSG2zy44zy_sNA@mail.gmail.com>

Hi Hempushpa,

What you describe appears to be this issue: JDK-8168664
<https://bugs.openjdk.org/browse/JDK-8168664>.

-Archie

On Tue, Aug 27, 2024 at 12:29?AM Hempushpa Sahu <Hempushpa.Sahu at ibm.com>
wrote:

> Problem Description :
>
> XSLT transformation creating unique namespace prefixes.
>
>
>
> Analysis & Observation :
>
> When upgrading from Java 8 to Java 17, the XSLT transformation is
> generating a new namespace prefix for every XML element, even when the
> namespace value matches that of the parent element. This leads to large XML
> file transformations exceeding the file size and memory limits on our
> systems.
>
>
>
> The behaviour in OpenJDK has remained consistent since JDK 8; however, the
> namespace prefix issue is not something we find acceptable.
>
>
>
> Our investigation into the OpenJDK code led us to defect
> https://bugs.openjdk.org/browse/JDK-8167179, which addressed the
> namespace prefix issue in the OpenJDK 8 release. Despite this, we are still
> able to reproduce the issue in OpenJDK versions 8, 11, 17, and 22.
>
>
>
>
>
> Releases:
>
> OpenJDK 8, 11, 17 & 22 the issue is seen.
>
>
>
> Next steps:
>
> Please review and suggest if the above understanding is right. And please
> suggest solution to resolve the issue.
>
>
>
> NOTE:
>
> Please find the attachment with below files-
>
> XML file - sourceFile.xml
>
> XSL file - ie_si_to_spe.xsl
>
> Current output - sourceFile-test-transform.xml
>
> Expected output - sourceFile-expected-transform.xml
>
>
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240827/356656a2/attachment-0001.htm>

From liach at openjdk.org  Wed Aug 28 01:54:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 01:54:55 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without allocating
 instruction objects
Message-ID: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>

Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.

-------------

Commit messages:
 - Moar fixes
 - More direct code builder

Changes: https://git.openjdk.org/jdk/pull/20738/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339132
  Stats: 772 lines in 4 files changed: 719 ins; 25 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/20738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20738/head:pull/20738

PR: https://git.openjdk.org/jdk/pull/20738

From jwaters at openjdk.org  Wed Aug 28 03:49:25 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Aug 2024 03:49:25 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <hIiv7dM_QvSeLf3DIiTUlWwtruXr6K8BERQkewTd4sc=.b65677db-ecfa-40d7-ab81-4070f7ae948d@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

That's a lot of new warnings, but I like the idea of being more fine grained in what is disabled and enabled

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2265064013

From vtewari at openjdk.org  Wed Aug 28 04:41:21 2024
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 28 Aug 2024 04:41:21 GMT
Subject: RFR: 8339126: JNI exception pending in Inflater.c
In-Reply-To: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
References: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
Message-ID: <BXC5XF9TCbKII4lkSzYjvH-ugB18XKYjHV7nobXEuWM=.1a69bdf0-8fb8-465a-b6f0-14bee374d525@github.com>

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestreview-2265120728

From iklam at openjdk.org  Wed Aug 28 06:02:23 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 Aug 2024 06:02:23 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v3]
In-Reply-To: <gksmhbijVVMK2RpMKHJD1bAyCxw4J9srhwZBp_NQN-o=.33986263-c9f5-4e38-9b9e-d220706299ca@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <gksmhbijVVMK2RpMKHJD1bAyCxw4J9srhwZBp_NQN-o=.33986263-c9f5-4e38-9b9e-d220706299ca@github.com>
Message-ID: <gE0DnzZhQ09_sYL1hP1KV_O5XwAX3aNJ3vbBN8pvhFk=.8e89d321-bcb3-4f36-8e3c-1ae5f53e4458@github.com>

On Tue, 27 Aug 2024 17:27:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - With JDK-8338929 we don't need is_in_class_space().
>  - Merge branch 'master' into anon
>  - Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.
>  - 8338526: Don't store abstract and interface Klasses in class metaspace

Looks OK to me.

Maybe we should add an assert in `CompressedKlassPointers::encode_not_null()` to check that we never encode abstract and interface classes?

src/hotspot/share/oops/metadata.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved.

No more change in this file?

-------------

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2265222694
PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1734036194

From alanb at openjdk.org  Wed Aug 28 06:35:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Aug 2024 06:35:24 GMT
Subject: RFR: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource
In-Reply-To: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
References: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
Message-ID: <kqj71jUzZNfWRr96QRF7NvQIgvxvphRE31FREWoJxxE=.0fee3cbf-0f4a-4e16-9758-e1a4d7feb1f2@github.com>

On Tue, 27 Aug 2024 21:57:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed.

Yes, but aside from cleanup, this also fixes a bug where it clears the interrupt status and doesn't restore it. Good to get this fixed.

src/java.base/share/classes/jdk/internal/loader/Resource.java line 89:

> 87:         // can propagate upwards without being caught too early
> 88:         InputStream in = cachedInputStream();
> 89:         int len = getContentLength();

Pre-existing question but I wonder if this should move into the try block so that the input stream is closed in the event of getContentLength failing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20736#issuecomment-2314427102
PR Review Comment: https://git.openjdk.org/jdk/pull/20736#discussion_r1734072287

From kbarrett at openjdk.org  Wed Aug 28 06:41:19 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Aug 2024 06:41:19 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

We should make a similar set of changes for clang, though doing that in a separate
proposal is good.  Is there a JBS issue for that yet?

make/autoconf/flags-cflags.m4 line 239:

> 237:       # Additional warnings that are not activated by -Wall and -Wextra
> 238:       WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \
> 239:           -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \

I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++
code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal
to have a non-local constant in a header file that isn't used by every translation unit.  For C++ use
`-Wunused-const-variable=1`.  I think doing this might eliminate the need for disabling this warning
in a bunch of other places in this PR.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2265277235
PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734067573

From adam.sotona at oracle.com  Wed Aug 28 07:13:02 2024
From: adam.sotona at oracle.com (Adam Sotona)
Date: Wed, 28 Aug 2024 07:13:02 +0000
Subject: [External] : Re: New candidate JEP: 484: Class-File API
In-Reply-To: <CANSoFxvsxQa8-W5R9Pv=RpefPHMCHQkw5ZKGmivCfxdWq3mDSA@mail.gmail.com>
References: <20240827135742.4415C7785D5@eggemoggin.niobe.net>
 <CANSoFxvsxQa8-W5R9Pv=RpefPHMCHQkw5ZKGmivCfxdWq3mDSA@mail.gmail.com>
Message-ID: <DS0PR10MB68471B354B9D14052591EDD28C952@DS0PR10MB6847.namprd10.prod.outlook.com>

Class files conforming to the Chapter 4. ?The class File Format? of the Java Virtual Machine Specification are supported. It covers class file versions far to the history.

Feel free to report cases where the support is insufficient.

Thank you,
Adam

From: Archie Cobbs <archie.cobbs at gmail.com>
Date: Tuesday, 27 August 2024 at 18:49
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Cc: Adam Sotona <adam.sotona at oracle.com>, jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: [External] : Re: New candidate JEP: 484: Class-File API
Question... would it be appropriate for this JEP to mention that support for older-than-current classfile versions is an explicit non-goal?

Otherwise I think there could be many repeats of this discussion<https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127982.html> from the other day.

To be clear, I don't disagree with the design choice, I just think it might be worthwhile to address that point directly and clarify the thinking behind it so there's no ambiguity.

As it's written today, a casual reading of the JEP comes across as if we're talking about a great new JDK-sanctioned tool with state of the art design that will help get all of the classfile manipulation libraries on the same page to allow analysis/transformation of any class file on the classpath. Or at least, it doesn't do anything to dispel that notion (unless I'm missing something).

-Archie

On Tue, Aug 27, 2024 at 8:58?AM Mark Reinhold <mark.reinhold at oracle.com<mailto:mark.reinhold at oracle.com>> wrote:
https://openjdk.org/jeps/484

  Summary: Provide a standard API for parsing, generating, and
  transforming Java class files.

- Mark


--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240828/976fc8dc/attachment-0001.htm>

From redestad at openjdk.org  Wed Aug 28 07:52:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 07:52:19 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects
In-Reply-To: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
Message-ID: <bvxYIedx30T4fWD3LHPf8p525i4I4yC4ihInikpRLaM=.43436262-70f3-4813-8879-acda976fdc5f@github.com>

On Wed, 28 Aug 2024 01:49:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.

This seem to work great. A reduction on all relevant startup and footprint metrics. -26 classes on `StringConcatStartup`, for example.

Perhaps the code changes could be reduced somewhat if `DirectCodeBuilder::writeBytecode(Opcode)` et.c. returned `DirectCodeBuilder`.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20738#pullrequestreview-2265439168

From eirbjo at openjdk.org  Wed Aug 28 08:11:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 28 Aug 2024 08:11:08 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v2]
In-Reply-To: <18kEXGWSjX_iG1mwRvMOfpdwaJpynrvOzj9FPnba9J8=.9d774b99-5f73-4b6f-9c0f-9540d2b37bd2@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <EJLtoQ9Ev6kP2BzodAlzowv7e2i632Uf9Ii_L6luh44=.9e90c460-d5e9-4f2d-9bb9-9285a5a93075@github.com>
 <urjYLS8ejxEwN5ZbJwIH-8IIkq93LjcgOuspPlLamg8=.1d190db5-67bd-4990-87d3-a2405a897ae1@github.com>
 <cMrbsvYcO-3yEfvK2QautX13D-bMVBqn5PmG9tLJ0hY=.c9fab8a0-52a3-49ca-97f4-1202530b0d93@github.com>
 <18kEXGWSjX_iG1mwRvMOfpdwaJpynrvOzj9FPnba9J8=.9d774b99-5f73-4b6f-9c0f-9540d2b37bd2@github.com>
Message-ID: <pLVwyANmT-j3l_MIrl1uVPLCcw3ktNd9tbmluHnyO8I=.af518595-088a-481b-a4fb-9420e39eb223@github.com>

On Tue, 27 Aug 2024 20:37:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Other options could be:
> 
> _ZipError is obsolete and is no longer used. ZipException should be used instead_

This looks good to me! I've pushed this with a an empty line above to visually separate the class description from the javadoc tags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20642#discussion_r1734190699

From eirbjo at openjdk.org  Wed Aug 28 08:11:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 28 Aug 2024 08:11:08 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
Message-ID: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>

> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
> 
> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
> 
> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
> 
> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
> 
> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into ziperror-deprecation
 - Simplify the deprecation note by focusing on behavior in the current release
 - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
 - Update copyright year
 - Deprecate java.util.zip.ZipError for removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20642/files
  - new: https://git.openjdk.org/jdk/pull/20642/files/eba159f4..44a3284b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20642&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20642&range=01-02

  Stats: 5234 lines in 190 files changed: 3589 ins; 764 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/20642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20642/head:pull/20642

PR: https://git.openjdk.org/jdk/pull/20642

From pminborg at openjdk.org  Wed Aug 28 08:34:21 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 Aug 2024 08:34:21 GMT
Subject: RFR: 8338731: MemoryLayout::offsetHandle can return a negative
 offset [v2]
In-Reply-To: <q70US7YRM0eWaJg4nCx20SuEo5dLO8_Gh0HjgqlJTMg=.3b75950a-7293-44be-8734-9385d9b1dd8d@github.com>
References: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
 <q70US7YRM0eWaJg4nCx20SuEo5dLO8_Gh0HjgqlJTMg=.3b75950a-7293-44be-8734-9385d9b1dd8d@github.com>
Message-ID: <37DirXvqnjok5XaRZ8yJF6dRVwHOkKM7kanfLExA4kY=.5c535d77-b0ab-4147-adf7-ca4e8bc7b2da@github.com>

On Tue, 27 Aug 2024 14:45:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.
>> 
>> In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.
>> 
>> The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into offset_overflow
>  - Merge branch 'master' into offset_overflow
>  - Initial push

Merge ok ;-)

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20662#pullrequestreview-2265544939

From pminborg at openjdk.org  Wed Aug 28 09:10:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 Aug 2024 09:10:24 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
Message-ID: <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>

On Tue, 27 Aug 2024 20:25:46 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> How fast do we need to be here given we are measuring in a few nanoseconds per operation?
> 
> What if the goal is not to regress from say explicitly filling in a small sized segment or a comparable array (e.g., < 8 bytes) then maybe a loop suffices and the code is simple?

Fair question. I have another version (called "patch bits" below) that is based on bit logic (first doing int ops, then short and lastly byte, similar to `ArraySupport::vectorizedMismatch`). This has slightly worse performance but is more scalable and perhaps simpler.

![image](https://github.com/user-attachments/assets/292c75aa-0df8-4bb7-b45f-426d0f8470d9)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2314760835

From michaelm at openjdk.org  Wed Aug 28 09:16:26 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 28 Aug 2024 09:16:26 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v3]
In-Reply-To: <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>
Message-ID: <LHIHmby10_sd7D87lyVMqafmfeYvOAZNUPZ6WGdSaJM=.b47175e9-7754-432f-a803-f5354d69c1c3@github.com>

On Tue, 27 Aug 2024 08:38:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Christian's suggestion - string ValueSource(s) instead of MethodSource

Update looks reasonable

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20691#pullrequestreview-2265658939

From cstein at openjdk.org  Wed Aug 28 09:24:20 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 28 Aug 2024 09:24:20 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v3]
In-Reply-To: <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>
Message-ID: <vB12s8FD-rk6FK2C-FjD75HPWIjvrfyzXVOUzDuX_M8=.191a4a90-9850-4245-981f-09e0134ebb89@github.com>

On Tue, 27 Aug 2024 08:38:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Christian's suggestion - string ValueSource(s) instead of MethodSource

Test looks good to me.

-------------

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20691#pullrequestreview-2265674069

From jpai at openjdk.org  Wed Aug 28 09:24:20 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Aug 2024 09:24:20 GMT
Subject: RFR: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest [v3]
In-Reply-To: <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
 <WuqurQouY4VcbC2bNdeG54x3jj_3G-ggAroZvWMZHA4=.01272d61-de1e-484a-9190-06ca0c4eabda@github.com>
Message-ID: <wyJR6TRH9EkzIMuL_iG9mZ8x0Zq8xXdXCJG_C7laoJY=.7bc335fb-0025-48b7-ab4a-d80fc3b74be4@github.com>

On Tue, 27 Aug 2024 08:38:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
>> 
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
>> 
>> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
>> 
>> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
>> 
>> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
>> 
>> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Christian's suggestion - string ValueSource(s) instead of MethodSource

Thank you all for the reviews and inputs. tier testing in CI continues to pass. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20691#issuecomment-2314792981

From pminborg at openjdk.org  Wed Aug 28 09:28:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 Aug 2024 09:28:59 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v6]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <z2exjigP2APYj-KgYNPMUcvxiUF3YvdbfwI2l5an280=.6c43a3f5-9988-4aab-82aa-eb0027c34809@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/92a0bcf2-f5b0-4a91-9c02-39423f870209)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Switch to bit checking instead of switch statement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/6fb6eefa..e2a52912

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=04-05

  Stats: 33 lines in 1 file changed: 6 ins; 15 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From jpai at openjdk.org  Wed Aug 28 09:33:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Aug 2024 09:33:36 GMT
Subject: Integrated: 8338445: jdk.internal.loader.URLClassPath may leak JarFile
 instance when dealing with unexpected Class-Path entry in manifest
In-Reply-To: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
References: <SjGntqEfsA1nnSksgsNxrK1fGjB_ps7L2fahGiSjSA4=.11a6c2bb-d6da-4032-8212-8f902e1d3e90@github.com>
Message-ID: <WbGzvdRkcuClBDX9HahJ9Q4KferxzHEmOZvMl1JzXEE=.97316b7e-f3f9-4e03-85f4-563527784135@github.com>

On Fri, 23 Aug 2024 10:45:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8338445?
> 
> The JDK internal class `jdk.internal.loader.URLClassPath` is used by classloader implementations in the JDK (for example by the `java.net.URLClassLoader` and the `jdk.internal.loader.ClassLoaders$AppClassLoader`). The implementation in `URLClassPath` constructs internal `Loader`s for each URL that is in the classpath of that instance. `Loader` implementations hold on to underlying resources from which the classpath resources are served by the `URLClassPath`.
> 
> When constructing a `Loader`, the `URLClassPath` allows the loader implementation to parse a local classpath for that specific `Loader`. For example, the `JarLoader` (an internal class of the JDK) will parse `Class-Path` attribute in the jar file's manifest to construct additional URLs that will be included in the classpath through which resources will be served by `URLClassPath`. While parsing the local classpath, if the `Loader` instance runs into any `IOException` or a `SecurityException`, the `URLClassPath` will ignore that specific instance of the `Loader` and will not hold on to it as a classpath element.
> 
> As noted earlier, `Loader` instances may hold onto underlying resources. When the `URLClassPath` ignores such `Loader`(s) and doesn't call `close()` on them, then that results in potential resource leaks. The linked JBS issue demonstrates a case where the `JarFile` held by the `JarLoader` doesn't get closed (until GC garbage collects the `JarLoader` and thus the `JarFile`), when the `URLClassPath` ignores that `JarLoader` due to an `IOException` when the `JarLoader` is parsing the `Class-Path` value from the jar's manifest.
> 
> The commit in this PR addresses the issue by calling `close()` on such `Loader`s that get rejected by the `URLClassPath` when either an `IOException` or a `SecurityException` gets thrown when constructing the `Loader` or parsing the local classpath.
> 
> A new jtreg test has been introduced which consistently reproduces this issue (on Windows) and verifies the fix. Additionally tier1, tier2 and tier3 testing has completed with this change without any failures.

This pull request has now been integrated.

Changeset: 2e174c63
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e174c6367c7755d8541f9669f7f10ed89878f58
Stats:     184 lines in 2 files changed: 173 ins; 4 del; 7 mod

8338445: jdk.internal.loader.URLClassPath may leak JarFile instance when dealing with unexpected Class-Path entry in manifest

Reviewed-by: michaelm, cstein, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20691

From mcimadamore at openjdk.org  Wed Aug 28 09:56:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 09:56:19 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths
In-Reply-To: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
Message-ID: <MdSeBAPFe7ZoxFlrgnNBo1MUljIfSGxo_I81xiGstkk=.6ab559a8-c47e-48fd-a3c1-7c2957dc3fa9@github.com>

On Tue, 27 Aug 2024 09:36:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1316:

> 1314: 
> 1315:     /**
> 1316:      * Reads a string using the given byte length from this segment at the given offset,

What happens is there's a null terminator before `length` ? Seems like we're just copying it? IMHO, this is the tension with this API.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1335:

> 1333:      *         largest string supported by the platform
> 1334:      * @throws IndexOutOfBoundsException if {@code offset < 0}
> 1335:      * @throws IndexOutOfBoundsException if {@code offset > byteSize() - (B + N)}, where:

I believe this is incorrect - e.g. all the B + N stuff is not needed, as we have a length

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734361085
PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734360517

From mcimadamore at openjdk.org  Wed Aug 28 10:00:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:00:19 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths
In-Reply-To: <MdSeBAPFe7ZoxFlrgnNBo1MUljIfSGxo_I81xiGstkk=.6ab559a8-c47e-48fd-a3c1-7c2957dc3fa9@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <MdSeBAPFe7ZoxFlrgnNBo1MUljIfSGxo_I81xiGstkk=.6ab559a8-c47e-48fd-a3c1-7c2957dc3fa9@github.com>
Message-ID: <ozzbLpjSGfqMdOT61VpaAKHgA8zquNPmkdIzj1iIOn0=.b44d62b7-c9d9-4600-94b0-c01677a3ba68@github.com>

On Wed, 28 Aug 2024 09:52:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1316:
> 
>> 1314: 
>> 1315:     /**
>> 1316:      * Reads a string using the given byte length from this segment at the given offset,
> 
> What happens is there's a null terminator before `length` ? Seems like we're just copying it? IMHO, this is the tension with this API.

Overall, I guess I'm not overly convinced that it's worth adding a method like this for:

byte[] bytes = new byte[len];
MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len);
return new String(bytes, charset);

e.g. the API provides string shortcuts for the common case. The more convoluted case can still be achieve via `copy`. Is there anything I'm missing here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734367933

From mcimadamore at openjdk.org  Wed Aug 28 10:00:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:00:19 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths
In-Reply-To: <ozzbLpjSGfqMdOT61VpaAKHgA8zquNPmkdIzj1iIOn0=.b44d62b7-c9d9-4600-94b0-c01677a3ba68@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <MdSeBAPFe7ZoxFlrgnNBo1MUljIfSGxo_I81xiGstkk=.6ab559a8-c47e-48fd-a3c1-7c2957dc3fa9@github.com>
 <ozzbLpjSGfqMdOT61VpaAKHgA8zquNPmkdIzj1iIOn0=.b44d62b7-c9d9-4600-94b0-c01677a3ba68@github.com>
Message-ID: <5mPAYOuQvlg2wDkXgm02wWWcogml-V97F1reGS2EisM=.84e445e8-5ce5-49d3-a94e-7136d985157f@github.com>

On Wed, 28 Aug 2024 09:56:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1316:
>> 
>>> 1314: 
>>> 1315:     /**
>>> 1316:      * Reads a string using the given byte length from this segment at the given offset,
>> 
>> What happens is there's a null terminator before `length` ? Seems like we're just copying it? IMHO, this is the tension with this API.
>
> Overall, I guess I'm not overly convinced that it's worth adding a method like this for:
> 
> byte[] bytes = new byte[len];
> MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len);
> return new String(bytes, charset);
> 
> e.g. the API provides string shortcuts for the common case. The more convoluted case can still be achieve via `copy`. Is there anything I'm missing here?

Ok, I suppose what you do get is the auto-detection of charset length, which adjusts the size of the copy...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734369629

From mcimadamore at openjdk.org  Wed Aug 28 10:05:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:05:19 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths
In-Reply-To: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
Message-ID: <al-p-KK7-WPRz1byGXcrO3HBz4SpqhpW8g61q-G0h94=.e94fc25f-b0b9-4d4b-8bc5-4c814ca08cc2@github.com>

On Tue, 27 Aug 2024 09:36:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new overload to `MemorySegment::getString` whereby it is possible to pass in a known byte length of the content in a segment that should be converted to a String. This is useful in case one already knows the byte length and thereby does not need to scan for a null terminator.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1326:

> 1324:      * @param offset  offset in bytes (relative to this segment address) at which this
> 1325:      *                access operation will occur
> 1326:      * @param length  byte length to be used for string conversion (not including any

I suppose this might also create confusion - e.g. some users might expect the length to be "logical" (e.g. expressed in number of chars, which then can be turned into a physical length using the charset).

src/java.base/share/classes/jdk/internal/foreign/StringSupport.java line 58:

> 56:     public static String read(MemorySegment segment, long offset, int len, Charset charset) {
> 57:         return switch (CharsetKind.of(charset)) {
> 58:             case SINGLE_BYTE -> readByte(segment, offset, len, charset);

How does this work, exactly? All methods called here seem to do:

byte[] bytes = new byte[len];
MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, len);


Why do we need different methods?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734375912
PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734374765

From mcimadamore at openjdk.org  Wed Aug 28 10:08:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:08:19 GMT
Subject: RFR: 8333843: Provide methods on MemorySegment to read strings
 with known lengths
In-Reply-To: <5mPAYOuQvlg2wDkXgm02wWWcogml-V97F1reGS2EisM=.84e445e8-5ce5-49d3-a94e-7136d985157f@github.com>
References: <4d-JQ9xSGSN1xj_2FbIGfuj63Rh_q6f6ZOKAReEIBEI=.562d325a-914d-4c8e-be65-ec386b399624@github.com>
 <MdSeBAPFe7ZoxFlrgnNBo1MUljIfSGxo_I81xiGstkk=.6ab559a8-c47e-48fd-a3c1-7c2957dc3fa9@github.com>
 <ozzbLpjSGfqMdOT61VpaAKHgA8zquNPmkdIzj1iIOn0=.b44d62b7-c9d9-4600-94b0-c01677a3ba68@github.com>
 <5mPAYOuQvlg2wDkXgm02wWWcogml-V97F1reGS2EisM=.84e445e8-5ce5-49d3-a94e-7136d985157f@github.com>
Message-ID: <m9JhqYotsayJ1sx7k4qD1S0PR11wWvQ2fGdC66Y9Gag=.b7d1200d-2b62-4a70-92c2-65814ee5e7b1@github.com>

On Wed, 28 Aug 2024 09:57:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Ok, I suppose what you do get is the auto-detection of charset length, which adjusts the size of the copy...

NVM, this is not what this impl is doing. I see no performance benefit for using the new API over a `copy`. If so, this new API is just for ease of use. While that's ok, IMHO it's not an easy API to add, as we're making a number of arbitrary choices here:
* what to do with terminators in the middle of the string
* whether length is length of string in chars, or length in bytes (we do the latter)

This leaves me a bit skeptical that this API is the right primitive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20725#discussion_r1734379824

From mcimadamore at openjdk.org  Wed Aug 28 10:25:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:25:28 GMT
Subject: Integrated: 8338731: MemoryLayout::offsetHandle can return a negative
 offset
In-Reply-To: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
References: <0nPV5kfNxQB4tHY88VVa8jelKJ3TdoN-ZUIxqn0hl7k=.d8f1745a-081b-4b48-8227-a760086d77ba@github.com>
Message-ID: <dkkNulMZLvPYgT9cyJpj-qEwdCUFtAEMVrYPJ0Lv4CY=.7f04dbfc-1577-45c7-a7c4-45fd1dafb44f@github.com>

On Wed, 21 Aug 2024 13:26:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> When working on startup improvements, I noticed that the method handle returned by `MemoryLayout::offsetHandle` can overflow if the client calls the handle with a base offset that is too big.
> 
> In other similar situations, the layout API always fails with `ArithmeticException` (see `MemoryLayout::scale`), so we should do the same here.
> 
> The fix is to use a `Math::addExact(long, long)` for the outermost add operation in the computation of the offset method handle. That outermost computation in fact is the only one that can overflow: it is an addition between a user-provided base offset `B` and a layout offset `L`. `L` is guaranteed not to overflow, by construction (as `L` is derived from a layout path). But `B` + `L` might overflow, so the new logic checks for that.

This pull request has now been integrated.

Changeset: 1ff9ac72
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ff9ac7233d51a58fd54a92d2c45761478574cc7
Stats:     23 lines in 3 files changed: 14 ins; 1 del; 8 mod

8338731: MemoryLayout::offsetHandle can return a negative offset

Reviewed-by: pminborg, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/20662

From mcimadamore at openjdk.org  Wed Aug 28 10:29:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:29:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
Message-ID: <_7Y1rugU2kYQP4aNpfdoIXOBHcfEFEE_05xgRnbPFyE=.472cd59a-ac28-4918-bfe8-1f6db68a1771@github.com>

On Wed, 28 Aug 2024 09:06:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> How fast do we need to be here given we are measuring in a few nanoseconds per operation?

The goal here is to be "competitive" with array bulk operations (given arrays do have bound checks as well) across all the segment size spectrum. It's fine to lose something in order to get to more maintainable code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2314929916

From mcimadamore at openjdk.org  Wed Aug 28 10:29:24 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:29:24 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v6]
In-Reply-To: <z2exjigP2APYj-KgYNPMUcvxiUF3YvdbfwI2l5an280=.6c43a3f5-9988-4aab-82aa-eb0027c34809@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <z2exjigP2APYj-KgYNPMUcvxiUF3YvdbfwI2l5an280=.6c43a3f5-9988-4aab-82aa-eb0027c34809@github.com>
Message-ID: <_1pW_I8oG8lcnINLFykvDHRHeh04RZR7T2JIK5TpyH8=.0c8e3d04-c1e7-4019-aea1-fa42b76ebe7a@github.com>

On Wed, 28 Aug 2024 09:28:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to bit checking instead of switch statement

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 59:

> 57: import sun.nio.ch.DirectBuffer;
> 58: 
> 59: import static java.lang.foreign.ValueLayout.*;

Please use direct imports

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1734408375

From mcimadamore at openjdk.org  Wed Aug 28 10:35:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:35:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v6]
In-Reply-To: <z2exjigP2APYj-KgYNPMUcvxiUF3YvdbfwI2l5an280=.6c43a3f5-9988-4aab-82aa-eb0027c34809@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <z2exjigP2APYj-KgYNPMUcvxiUF3YvdbfwI2l5an280=.6c43a3f5-9988-4aab-82aa-eb0027c34809@github.com>
Message-ID: <JeYUPee2R_bf3R036U0FikLHA_vEgLgqYFG-9GMudec=.10dbe8d6-2d14-498d-8761-081232816417@github.com>

On Wed, 28 Aug 2024 09:28:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to bit checking instead of switch statement

Added some nit coments - overall, the code looks very clean, and it's nice to see this improvements... now onto copy :-)

test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java line 87:

> 85:     public void buffer_fill() {
> 86:         // Hopefully, the creation of the intermediate array will be optimized away.
> 87:         buffer.clear().put(new byte[ELEM_SIZE]);

I think this should use an "absolute" put with explicit offset, so that you can avoid the clear? Otherwise it's not apple to apple...

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2265840314
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1734415133

From mcimadamore at openjdk.org  Wed Aug 28 10:35:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 10:35:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v6]
In-Reply-To: <JeYUPee2R_bf3R036U0FikLHA_vEgLgqYFG-9GMudec=.10dbe8d6-2d14-498d-8761-081232816417@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <z2exjigP2APYj-KgYNPMUcvxiUF3YvdbfwI2l5an280=.6c43a3f5-9988-4aab-82aa-eb0027c34809@github.com>
 <JeYUPee2R_bf3R036U0FikLHA_vEgLgqYFG-9GMudec=.10dbe8d6-2d14-498d-8761-081232816417@github.com>
Message-ID: <Ksb2yFoc3I4VJYZk5XN2F2ra8dbX8oyBjtEGEffMJk8=.7de66585-18e2-4eb1-abc4-31abdfca3765@github.com>

On Wed, 28 Aug 2024 10:30:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Switch to bit checking instead of switch statement
>
> test/micro/org/openjdk/bench/java/lang/foreign/TestFill.java line 87:
> 
>> 85:     public void buffer_fill() {
>> 86:         // Hopefully, the creation of the intermediate array will be optimized away.
>> 87:         buffer.clear().put(new byte[ELEM_SIZE]);
> 
> I think this should use an "absolute" put with explicit offset, so that you can avoid the clear? Otherwise it's not apple to apple...

in general though, ByteBuffer doesn't have a "fill" operation. What you are testing here is fill vs. copy, which is not really apple to apple. I think it's probably better to leave BB alone here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1734418264

From pminborg at openjdk.org  Wed Aug 28 11:10:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 28 Aug 2024 11:10:05 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v7]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <vP2hZ0cVv7PMHSP7WTkyElfYV0S3bCDKKYFIYctg74g=.00605162-454d-4fa6-9df4-1447cd137ca4@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Make minor updates after comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/e2a52912..78eb92a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=05-06

  Stats: 9 lines in 2 files changed: 2 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From ihse at openjdk.org  Wed Aug 28 11:28:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 11:28:19 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
Message-ID: <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>

On Wed, 28 Aug 2024 06:38:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> We should make a similar set of changes for clang, though doing that in a separate
proposal is good. Is there a JBS issue for that yet?

Yes, we should. I am 80% done with that patch, but I have not yet opened a JBS ticket. Will do that now.

> make/autoconf/flags-cflags.m4 line 239:
> 
>> 237:       # Additional warnings that are not activated by -Wall and -Wextra
>> 238:       WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \
>> 239:           -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \
> 
> I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++
> code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal
> to have a non-local constant in a header file that isn't used by every translation unit.  For C++ use
> `-Wunused-const-variable=1`.  I think doing this might eliminate the need for disabling this warning
> in a bunch of other places in this PR.

Good point, I'll try that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20733#issuecomment-2315053230
PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734501680

From mcimadamore at openjdk.org  Wed Aug 28 11:34:19 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 11:34:19 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v7]
In-Reply-To: <vP2hZ0cVv7PMHSP7WTkyElfYV0S3bCDKKYFIYctg74g=.00605162-454d-4fa6-9df4-1447cd137ca4@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <vP2hZ0cVv7PMHSP7WTkyElfYV0S3bCDKKYFIYctg74g=.00605162-454d-4fa6-9df4-1447cd137ca4@github.com>
Message-ID: <OmAUy8Xnykkdv5pUUNsgs_M9rxTyQdJQro9HwPcLuaw=.deddcbd4-d97f-493d-bc27-af91911f9a4a@github.com>

On Wed, 28 Aug 2024 11:10:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make minor updates after comments

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2265989842

From mcimadamore at openjdk.org  Wed Aug 28 11:49:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Aug 2024 11:49:25 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
Message-ID: <3QUopc87Z1gljDCAjpmx3abjU_rJD35aslvoNpSqS7U=.0268fea9-eacd-4ba2-83b6-963f45c04962@github.com>

On Wed, 28 Aug 2024 09:06:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> then maybe a loop suffices and the code is simple?

We have tried a loop, but sadly the performance is not great if the number of iteration is small. This is due to the fact that long loops are split into two loops, and outer and an inner, where the inner loop works up to `Integer.MAX_SIZE`. While this strategy pays off for bigger iterations, it doesn't for very small ones. The C2 optimizations currently have a cutoff point, but it's possible that this point is set too high.

This is being discussed with @rwestrel

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2315107066

From eirbjo at openjdk.org  Wed Aug 28 11:51:59 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 28 Aug 2024 11:51:59 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java
Message-ID: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>

Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:

* The test is converted to JUnit 5
* The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
*  Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
* Coverage is added for calling `available()` on a closed `ZipInputStream`
* Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)

Additionally, the test is split into multiple methods, adding javadoc comments for each of them.

-------------

Commit messages:
 - Add coverage for calling available() on a closed ZipInputStream
 - Clean up the Available test and convert it to JUnit 5

Changes: https://git.openjdk.org/jdk/pull/20744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339154
  Stats: 145 lines in 1 file changed: 103 ins; 10 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/20744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20744/head:pull/20744

PR: https://git.openjdk.org/jdk/pull/20744

From duke at openjdk.org  Wed Aug 28 12:31:51 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 12:31:51 GMT
Subject: RFR: 8339158: TypeKind add slotSize field
Message-ID: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>

Small improvement, add a final field, no need to calculate every time.

-------------

Commit messages:
 - slotSize field

Changes: https://git.openjdk.org/jdk/pull/20743/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339158
  Stats: 18 lines in 1 file changed: 2 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20743/head:pull/20743

PR: https://git.openjdk.org/jdk/pull/20743

From liach at openjdk.org  Wed Aug 28 12:31:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 12:31:51 GMT
Subject: RFR: 8339158: TypeKind add slotSize field
In-Reply-To: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
References: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
Message-ID: <tWhJS1v0eBvtqFqpeZRiD125mMjPm5fd952iF0NaDMY=.93cb44e1-d0a4-43ff-a082-ea54fbaa4b43@github.com>

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Small improvement, add a final field, no need to calculate every time.

Is this field access faster than a table switch?

Also notice there's #20737 which may come before your improvement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2315115615

From duke at openjdk.org  Wed Aug 28 12:31:51 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 12:31:51 GMT
Subject: RFR: 8339158: TypeKind add slotSize field
In-Reply-To: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
References: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
Message-ID: <8kYUcLr_LzBykk2ZAFKGGwUW1mH6qfT8c6jDl2D0784=.69466170-ea53-4806-aa33-5bf069696762@github.com>

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Small improvement, add a final field, no need to calculate every time.

Of course, the implementation complexity of these two is different, and the code size is also different.

## codeSize

# baseline
java.lang.classfile.TypeKind::slotSize (50 bytes) 

# current
java.lang.classfile.TypeKind::slotSize (5 bytes)   inline


## bytecode
* baseline

  public int slotSize();
    Code:
       0: aload_0
       1: invokevirtual #60                 // Method ordinal:()I
       4: lookupswitch  { // 3
                     4: 44
                     5: 44
                     9: 40
               default: 48
          }
      40: iconst_0
      41: goto          49
      44: iconst_2
      45: goto          49
      48: iconst_1
      49: ireturn


* current

  public int slotSize();
    Code:
       0: aload_0
       1: getfield      #60                 // Field slotSize:I
       4: ireturn


This is not a high frequency call, a slight improvement

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2315182651

From ihse at openjdk.org  Wed Aug 28 12:34:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 12:34:28 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v2]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <EU5oA6dm39X6mxMx-Pt5cQMUlaiW6kgoHIfoTWcZlM4=.4532a170-dc0c-4f55-b035-602a512acbaa@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Use -Wunused-const-variable=1 instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/7d4f1380..27cd3b06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=00-01

  Stats: 48 lines in 5 files changed: 8 ins; 1 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Wed Aug 28 12:34:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 12:34:29 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v2]
In-Reply-To: <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
 <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>
Message-ID: <kj31yN6Llw0LfS6uJQTJ2mmIDBz5IvFHVNQVjWAwMjY=.6f0b5244-a1b8-480e-bfb1-5189444bb34e@github.com>

On Wed, 28 Aug 2024 11:26:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 239:
>> 
>>> 237:       # Additional warnings that are not activated by -Wall and -Wextra
>>> 238:       WARNINGS_ENABLE_ADDITIONAL="-Wpointer-arith -Wreturn-type -Wsign-compare \
>>> 239:           -Wtrampolines -Wundef -Wunused-const-variable -Wunused-function \
>> 
>> I think we don't want `-Wunused-const-variable=2` (eqv. `-Wunused-const-variable`) for C++
>> code. Recall that C++ const variables default to internal linkage (e.g. implicitly static). It's normal
>> to have a non-local constant in a header file that isn't used by every translation unit.  For C++ use
>> `-Wunused-const-variable=1`.  I think doing this might eliminate the need for disabling this warning
>> in a bunch of other places in this PR.
>
> Good point, I'll try that.

It turned out to be sort-of okay-ish. I explicitly listed like 6 or so per-file exclusions in Hotspot (even though my normal cutoff for just setting a component-wide exclude is 3-4) since it seems that you will want to look at and fix those.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734588979

From ihse at openjdk.org  Wed Aug 28 12:47:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 12:47:19 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
 <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>
Message-ID: <sEu79RK8yvbgjFoOB0GLpL_YAb8AKu8tZ-AKgSyMlow=.884ba84b-17f7-4d7f-a34c-4c145b3c9dd1@github.com>

On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.
>> 
>> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 
>> 
>> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.
>> 
>> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.
>
> @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime.

@jianglizhou Are there any other authors on the `hermetic-java-runtime` branch that should be credited?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315222006

From ihse at openjdk.org  Wed Aug 28 13:02:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 13:02:55 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix aarch54

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/27cd3b06..7d3bf0d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From yzheng at openjdk.org  Wed Aug 28 13:17:20 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 28 Aug 2024 13:17:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <cM6_tGA-3aKQtrxZ6lc6yUyk0fg-2ud9kdwdB-f5pgE=.188b3347-38e4-49f1-9bca-d6a24e836bfd@github.com>

On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

src/hotspot/share/jvmci/jvmciCompilerToVM.hpp line 114:

> 112:     static address dcos;
> 113:     static address dtan;
> 114:     static address dtanh;

Could you please add the following initializing code?

diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
index 9752d7edf99..1db9be70db0 100644
--- a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
+++ b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
@@ -259,6 +259,17 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
   SET_TRIGFUNC(dpow);
 
 #undef SET_TRIGFUNC
+
+#define SET_TRIGFUNC_OR_NULL(name)                              \
+  if (StubRoutines::name() != nullptr) {                        \
+    name = StubRoutines::name();                                \
+  } else {                                                      \
+    name = nullptr;                                             \
+  }
+
+  SET_TRIGFUNC_OR_NULL(dtanh);
+
+#undef SET_TRIGFUNC_OR_NULL
 }
 
 static jboolean is_c1_supported(vmIntrinsics::ID id){
diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index fea308503cf..189c1465589 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -126,6 +126,7 @@
   static_field(CompilerToVM::Data,             dsin,                                   address)                                      \
   static_field(CompilerToVM::Data,             dcos,                                   address)                                      \
   static_field(CompilerToVM::Data,             dtan,                                   address)                                      \
+  static_field(CompilerToVM::Data,             dtanh,                                  address)                                      \
   static_field(CompilerToVM::Data,             dexp,                                   address)                                      \
   static_field(CompilerToVM::Data,             dlog,                                   address)                                      \
   static_field(CompilerToVM::Data,             dlog10,                                 address)                                      \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1734655447

From kbarrett at openjdk.org  Wed Aug 28 13:38:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Aug 2024 13:38:20 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]
In-Reply-To: <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>
Message-ID: <CYdPaXV4225As6MAyJ7HXXm3km8SwG6Jqbc_8Qhb2gw=.bf7b3427-0ae8-4705-8bf1-26310ad929ea@github.com>

On Wed, 28 Aug 2024 13:02:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix aarch54

Changes requested by kbarrett (Reviewer).

make/modules/java.desktop/lib/ClientLibraries.gmk line 284:

> 282: 
> 283: ifeq ($(USE_EXTERNAL_HARFBUZZ), true)
> 284:   LIBFONTMANAGER_EXTRA_SRC =

I think this 3space -> 2space indentation change shouldn't be part of this PR, esp. since 3space is
used in other parts of this file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266289452
PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734691445

From sgehwolf at openjdk.org  Wed Aug 28 13:40:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 28 Aug 2024 13:40:05 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v4]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <gsLMzw5t8t562GqFRY8nn5G60T7XlAUjAkb_7dNu2rY=.987faf7a-0c7c-4f5b-98b5-d83b2805a974@github.com>

> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
> 
> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
> 
> This patch addresses this issue by:
> 
> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
> 
> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
> 
> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been proposed in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
> 
> Thoughts?
> 
> Testing:
> 
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices

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 two additional commits since the last revision:

 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - 8336881: [Linux] Support for hierarchical limits for Metrics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20280/files
  - new: https://git.openjdk.org/jdk/pull/20280/files/f0c775b2..2d918ca4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=02-03

  Stats: 6199 lines in 321 files changed: 4177 ins; 896 del; 1126 mod
  Patch: https://git.openjdk.org/jdk/pull/20280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280

PR: https://git.openjdk.org/jdk/pull/20280

From erikj at openjdk.org  Wed Aug 28 13:41:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Aug 2024 13:41:21 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
Message-ID: <9YbB0gtUIqE5SAmbAMmVC_S8wNDa9kKPVop6uvKUxCY=.e000ded5-fcb8-42f9-bde7-97cd1f52ecf9@github.com>

On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.

I understand your stance and it's a fair principle. My opinion is that we need to weigh the pros and cons with more nuance. We are often in situations where have to weigh runtime performance against things like (openjdk) developer convenience, maintainability and build performance. As we are building the Java platform, we often give up a lot to eek out the last drops of runtime performance, but we sure aren't always making that tradeoff in favor of performance. As a very clear example, we could enable LTO (Link Time Optimization), which would likely give a measurable (though likely small) performance improvement at runtime, at the cost of a big increase in build time, but we haven't, because we don't think the tradeoff is worth it. My take on the current issue is that the potential savings in build time is easily comparable to using LTO or not, while the difference in runtime performance is likely different by orders of magnitudes. My point is that we make these kinds of calls quite 
 often.

So in this case, my take is that even if the size difference in the number of people impacted is big, I think the size difference in the actual impact more than makes up for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315348318

From liach at openjdk.org  Wed Aug 28 14:08:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 14:08:19 GMT
Subject: RFR: 8339158: TypeKind add slotSize field
In-Reply-To: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
References: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
Message-ID: <ITbGJIpcFs8VX5B9VSA-iQXJ8KR37rv9pj5q0yrkQok=.5f65e9f7-91e9-4555-83a0-b04c146d3fe7@github.com>

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Small improvement, add a final field, no need to calculate every time.

What if we reorder the constants to be like:

VOID, REFERENCE, DOUBLE, LONG, FLOAT, INT, SHORT, CHAR, BYTE, BOOLEAN;

and check like:

int i = ordinal();
return i < 3 ? i : i == 3 : 2 : 1;

I think about such an order because we usually switch over:
1. `VOID, REFERENCE, DOUBLE, LONG, FLOAT, INT` for "computational types"
2. `DOUBLE, LONG, FLOAT, INT, SHORT, CHAR, BYTE, BOOLEAN` for array instructions and such
This order might reduce table switch size for both cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2315419446

From duke at openjdk.org  Wed Aug 28 14:15:20 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 14:15:20 GMT
Subject: RFR: 8339158: TypeKind add slotSize field
In-Reply-To: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
References: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
Message-ID: <ntsDTPHkwT88IuwryQk3lS1Zfol7DMxyv0MhmPUzw68=.59fa8573-aaa8-4a0d-b1c9-e8006b9ae91f@github.com>

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> Small improvement, add a final field, no need to calculate every time.

That kind of code is hard to understand. How simple is it to add a field?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2315436832

From lancea at openjdk.org  Wed Aug 28 14:17:21 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Aug 2024 14:17:21 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
Message-ID: <YNBPCczRGqXAr7RptCM5XN8MdGZV3DBQb9JSCT38DbQ=.dc89b9ec-b81b-44e1-b88e-69fea41b8010@github.com>

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into ziperror-deprecation
>  - Simplify the deprecation note by focusing on behavior in the current release
>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>  - Update copyright year
>  - Deprecate java.util.zip.ZipError for removal

I think the revised proposal looks good and once you update the CSR, let me know and I will review it.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20642#pullrequestreview-2266422624

From aph at openjdk.org  Wed Aug 28 14:20:20 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 28 Aug 2024 14:20:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <8CAXws7Rp6HKERu5hSTOrXi8GRFRdV4I670Nf8NSZlI=.ba6acccb-77e5-46a6-bec2-e0ea97dfe85d@github.com>
 <Po6OlSwT75xgqLIh3IxkSArji5MOUHL_pRIqPlDXzaY=.fa08357e-ba02-4927-af59-636db79281b8@github.com>
 <NjCB73qaaGsJBqfljEcWx1U1cjbsw92l3Nej93LWlr8=.1982ecb4-460e-4817-8bb3-6204d2c16f3b@github.com>
Message-ID: <dhR6mqhLpebQe19yn2YWz2mfEYou2GzqpwrtG87otfo=.2330d40c-cd39-404c-99b2-388b9f479c7b@github.com>

On Tue, 27 Aug 2024 22:23:44 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> I agree, this is all rather obscure. Ideally the same names that are used in wherever this comes from.
>> 
>> Where does the algorithm come from? What are its accuracy guarantees?
>> 
>> In addition, given the rarity of hyperbolic tangents in Java applications, do we need this?
>
> @theRealAph, this implementation is based on Intel libm math library and meets the accuracy requirements. The algorithm is provided in the comments.

Do you have a copy of this information? Should it be in the commit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1734776732

From zzambers at openjdk.org  Wed Aug 28 14:23:21 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Wed, 28 Aug 2024 14:23:21 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <k-zoHJM6CDD5G55dr5PfIvcsmvuCtDjrZE8SaUnzaOU=.d108156f-9e2b-4722-99e0-aa8730527b69@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
 <dfkrfqnWOF7Mf7Ciz_GdHViivzuhST2eMIQ-q8iH2ms=.bf844897-92ec-46b8-9b3e-a08e21342337@github.com>
 <k-zoHJM6CDD5G55dr5PfIvcsmvuCtDjrZE8SaUnzaOU=.d108156f-9e2b-4722-99e0-aa8730527b69@github.com>
Message-ID: <0MlDf-EYzm6DG3KhZTK9xJlXmb9CRkwhi4VwQGA5xgY=.3c38107b-5b73-4508-b245-45f15fac845a@github.com>

On Tue, 27 Aug 2024 15:01:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > If I am not mistaken, new test requires, that testsuite is ran as superuser (root). (Because it writes `/etc/systemd/system`, runs certain systemd commands). Should test be skipped for non-root?
> 
> Thanks! I can add that. FWIW, container tests are in a similar situation (applying cpu/memory limits is not allowed in rootless on cg v1) and they don't check for it.

I think, it would be nice to skip on non-root, as tests are often ran as non-root. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2315477927

From archie.cobbs at gmail.com  Wed Aug 28 14:33:44 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Wed, 28 Aug 2024 09:33:44 -0500
Subject: [External] : Re: New candidate JEP: 484: Class-File API
In-Reply-To: <DS0PR10MB68471B354B9D14052591EDD28C952@DS0PR10MB6847.namprd10.prod.outlook.com>
References: <20240827135742.4415C7785D5@eggemoggin.niobe.net>
 <CANSoFxvsxQa8-W5R9Pv=RpefPHMCHQkw5ZKGmivCfxdWq3mDSA@mail.gmail.com>
 <DS0PR10MB68471B354B9D14052591EDD28C952@DS0PR10MB6847.namprd10.prod.outlook.com>
Message-ID: <CANSoFxtVV4LSNfazfpGVfLrvgKHOQ+fn_m5zUDiJQXARQbztbA@mail.gmail.com>

Hi Adam,

My apologies, this was a misunderstanding on my part. I think I misread this
comment
<https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127983.html>
and didn't notice the word "preview":

Unfortunately, ClassFile API's scope is only to interpret correctly the
> Class Files that are accepted by the current VM and support writing such
> class files; for example, for release N, we will not support correct
> parsing or writing of *preview* class files from N-1, N-2, etc.


So I mistakenly thought it was saying the ClassFile API in JDK N would not
support class files from previous versions N-1, etc.

-Archie

On Wed, Aug 28, 2024 at 2:13?AM Adam Sotona <adam.sotona at oracle.com> wrote:

> Class files conforming to the Chapter 4. ?The class File Format? of the
> Java Virtual Machine Specification are supported. It covers class file
> versions far to the history.
>
>
>
> Feel free to report cases where the support is insufficient.
>
>
>
> Thank you,
>
> Adam
>
>
>
> *From: *Archie Cobbs <archie.cobbs at gmail.com>
> *Date: *Tuesday, 27 August 2024 at 18:49
> *To: *core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
> *Cc: *Adam Sotona <adam.sotona at oracle.com>, jdk-dev at openjdk.org <
> jdk-dev at openjdk.org>
> *Subject: *[External] : Re: New candidate JEP: 484: Class-File API
>
> Question... would it be appropriate for this JEP to mention that support
> for older-than-current classfile versions is an explicit non-goal?
>
>
>
> Otherwise I think there could be many repeats of this discussion
> <https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127982.html>
> from the other day.
>
>
>
> To be clear, I don't disagree with the design choice, I just think it
> might be worthwhile to address that point directly and clarify the thinking
> behind it so there's no ambiguity.
>
>
>
> As it's written today, a casual reading of the JEP comes across as if
> we're talking about a great new JDK-sanctioned tool with state of the art
> design that will help get all of the classfile manipulation libraries on
> the same page to allow analysis/transformation of any class file on the
> classpath. Or at least, it doesn't do anything to dispel that notion
> (unless I'm missing something).
>
>
>
> -Archie
>
>
>
> On Tue, Aug 27, 2024 at 8:58?AM Mark Reinhold <mark.reinhold at oracle.com>
> wrote:
>
> https://openjdk.org/jeps/484
>
>   Summary: Provide a standard API for parsing, generating, and
>   transforming Java class files.
>
> - Mark
>
>
>
> --
>
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240828/c034561d/attachment.htm>

From liach at openjdk.org  Wed Aug 28 14:38:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 14:38:21 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal [v3]
In-Reply-To: <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <Xm7ByI9n962Obg2601CQafatRbm9TetttgdghLqphhs=.087527e5-07d2-419d-b4c3-455f448b73a5@github.com>
Message-ID: <7o1pwDAbTxmZVXlm-sf12IKteimCgb2v3JoinGtdH3U=.5b46fe1b-6da7-4b37-8720-755cff7efe1c@github.com>

On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which suggests to deprecate the unused class `java.util.zip.ZipError` for removal.
>> 
>> The class has been unsed by OpenJDK since  the ZIP API was rewritten from native to Java in JDK 9.
>> 
>> I opted to not explain the reason for the deprecation in detail, but instead simply point to `ZipException` as an alternative. Should more explanation be desired, I could prepend that with a note saying that the class is unused since JDK 9.
>> 
>> A CSR for this API update has been drafted, I'll update the Specification section there once we reach a concensus on the deprecation note in this PR.
>> 
>> This deprecation was initially suggested here: https://mail.openjdk.org/pipermail/core-libs-dev/2024-June/125720.html
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into ziperror-deprecation
>  - Simplify the deprecation note by focusing on behavior in the current release
>  - Extend the deprecation note to mention that the error became obsolete in JDK 9 and to mention that code may be updated to catch the super class InternalError
>  - Update copyright year
>  - Deprecate java.util.zip.ZipError for removal

Looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20642#pullrequestreview-2266481144

From lancea at openjdk.org  Wed Aug 28 14:41:19 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Aug 2024 14:41:19 GMT
Subject: RFR: 8338729: Retire the test jdk/java/util/zip/TestZipError.java
In-Reply-To: <2qQYLW8xwJAtu8UiUmvQVScFmXC61npdY6AYI-Yt5GY=.40c86241-851a-4ce7-9085-ac8bc7356924@github.com>
References: <2qQYLW8xwJAtu8UiUmvQVScFmXC61npdY6AYI-Yt5GY=.40c86241-851a-4ce7-9085-ac8bc7356924@github.com>
Message-ID: <mykdqHEyWIh7R48bigfaON4y0ze6vNEDVho_qNVO4rE=.14ebc084-d89d-469c-a0db-3d20c4df05f9@github.com>

On Wed, 21 Aug 2024 09:59:38 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only, cleanup PR which proposes that we retire the `jdk/java/util/zip/TestZipError.java` test.
> 
> The test has fallen out of sync with its original and stated purpose described by its name, `@summary` tag and code comments. The error condition actually being exercised has existing coverage in the `ZipSourceCache` test.
> 
> Background:
> 
> * The test was initially added in JDK-4615343 (Java 6) to exercise code paths which caused `ZipFile` entry enumeration to throw a `ZipError` (a subclass of `InternalError`).
> * After the rewrite of the ZipFile API from native to Java in JDK-8145260 (JDK 9), the Java code now tested no longer throws `ZipError` (The `ZipError` class is no longer used in OpenJDK)
> * As part of JDK-8145260, `TestZipError.java` was updated to catch `ZipException` instead of `ZipError` for the expected/passing case. Interestingly, a line was added which caused the test to not simply enumerate the entries of the updated ZipFile, but to also consume the input stream of the entries.
> * The added line caused `ZipFileInputStream.initDataOffset` to throw a `ZipException` when the CEN local header offset does not contain the expected LOC header, resulting in a ZipException with the message "ZipFile invalid LOC header (bad signature)". This added line caused the test to (accidentally?) test something which is actually different than its original purpose. 
> * The "invalid LOC header" scenario is currently better tested by the `ZipSourceCache` JUnit test, which also runs on non-Windows platforms.
> * Note that JDK-8145260 did not update the copyright years in the license header of this file.
> 
> Considering all of the above, I suggest that we do not invest resources in bringing the naming, summary and code comments of this test in line with what is actually being tested. Instead, we should simply retire it in favor of the existing `ZipSourceCache` test.
> 
> Testing:
> 
> * No tests are updated in this PR, I added a `noreg-cleanup` label in the JBS
> * By collecting a stack trace, I verified that the `ZipException` caught by `TestZipError` is indeed caused by the LOC header validation logic in `ZipFileInputStream.initDataOffset`
> * Similarly, I also verified that `ZipSourceCache` throws on the same condition as `TestZipError`

Thanks for catching this, I agree this test can go the way of the dodo bird.

Not sure why it was kept (or at least re-worked/named) after [JDK-8145260](https://bugs.openjdk.org/browse/JDK-8145260) but I am sure there was a good reason at the time

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20660#pullrequestreview-2266492192

From duke at openjdk.org  Wed Aug 28 14:47:45 2024
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 14:47:45 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize
Message-ID: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>

A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

-------------

Commit messages:
 - optimize slotSize & isDoubleSlot

Changes: https://git.openjdk.org/jdk/pull/20747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339168
  Stats: 11 lines in 1 file changed: 4 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20747/head:pull/20747

PR: https://git.openjdk.org/jdk/pull/20747

From liach at openjdk.org  Wed Aug 28 14:47:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 14:47:45 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <vQa8zusdk7-_lI7pHUA7f_aNw0TMJBV4eIUjXdBvPKg=.b2a3a7a4-ff50-4509-b873-c3dfbfd95719@github.com>

On Wed, 28 Aug 2024 13:12:35 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

Nice optimization enabled by our PrimitiveClassDesc object sharing.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20747#pullrequestreview-2266376528

From jpai at openjdk.org  Wed Aug 28 14:57:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Aug 2024 14:57:21 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
Message-ID: <Ajej0x77lVAduuMvCQYcIfUF9IhTwbmmUx4Iz4-BLlQ=.318906eb-d6d6-466a-a5cb-c75d33473daf@github.com>

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: Modified verbiage per reviewer comment

src/java.base/share/classes/java/io/BufferedInputStream.java line 54:

> 52:  *
> 53:  * <p> More than one instance of {@code BufferedInputStream} should not be
> 54:  * used with the same underlying {@code InputStream} instance.  Doing

Nit - there's one extra space here before the `Doing`. Same in the other classes as well.

src/java.base/share/classes/java/io/BufferedReader.java line 62:

> 60:  * replacing each DataInputStream with an appropriate BufferedReader.
> 61:  *
> 62:  * <p> More than one instance of BufferedReader should not be used with the

Nit - In the `BufferedInputStream` and the `BufferedOutputStream` we use `{@code ...}` to refer to these classes. Perhaps we should do the same here for `BufferedReader` and `Reader`? Same comment in the `BufferedWriter`  class update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1734835883
PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1734842931

From ihse at openjdk.org  Wed Aug 28 15:01:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:01:33 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v4]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <KgBC60i5kAAsmyHiUnWuP1Plcv3nh2nOIW8g9LNKhrM=.5c75079b-84c8-44f9-b9f3-4e307d21bd1f@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix ppc64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/7d3bf0d7..69a6b308

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=02-03

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Wed Aug 28 15:12:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:12:34 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v5]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <eJTrcLr8Y5nK_QXxwjrC_AXgKauaiauboNjmO9_QeHE=.0d553f03-7ebb-4ff7-a2c6-5093e78c507e@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix s390x build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/69a6b308..f4bdce72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=03-04

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From ihse at openjdk.org  Wed Aug 28 15:12:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:12:34 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v5]
In-Reply-To: <kj31yN6Llw0LfS6uJQTJ2mmIDBz5IvFHVNQVjWAwMjY=.6f0b5244-a1b8-480e-bfb1-5189444bb34e@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <T4rqV_-AyEo5Xvecfu1ffRwYjFdyAFpP7vu9xsBofFk=.c55de0dc-2c01-40e6-a73c-7120c74589c2@github.com>
 <Wh_ehv03iycRbr8kc8OJpaa8NnL3IUeNxUNLcqe7aRE=.8d2dd737-0832-4aab-a3de-554094fe9b4f@github.com>
 <kj31yN6Llw0LfS6uJQTJ2mmIDBz5IvFHVNQVjWAwMjY=.6f0b5244-a1b8-480e-bfb1-5189444bb34e@github.com>
Message-ID: <CHHurrG_t_PlepqZYEZDoxJUvFEb9gyRpv2j4GWmX78=.3e38360e-8a82-44e7-8ba0-466530396d33@github.com>

On Wed, 28 Aug 2024 12:29:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Good point, I'll try that.
>
> It turned out to be sort-of okay-ish. I explicitly listed like 6 or so per-file exclusions in Hotspot (even though my normal cutoff for just setting a component-wide exclude is 3-4) since it seems that you will want to look at and fix those.

Actually, it was probably a bad idea. I've been chasing platform-specific build failures for the last hour or so. :( But now at least it is done. I hope you guys can use this to actually fix the problems so it was worth it. ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734869178

From ihse at openjdk.org  Wed Aug 28 15:12:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:12:34 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v3]
In-Reply-To: <CYdPaXV4225As6MAyJ7HXXm3km8SwG6Jqbc_8Qhb2gw=.bf7b3427-0ae8-4705-8bf1-26310ad929ea@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <8Z0-2COIwtT2yDoSU8DkeNh2NbBOg7LZhFCEqtJzLOI=.83df3ab0-da2f-4b81-ab72-6091924ffdc1@github.com>
 <CYdPaXV4225As6MAyJ7HXXm3km8SwG6Jqbc_8Qhb2gw=.bf7b3427-0ae8-4705-8bf1-26310ad929ea@github.com>
Message-ID: <GCeXNsH3kFHr6aWWGr4EFYCKj-1D-pat3f6DpKjgkQM=.5d34adec-5180-48f2-a73c-2c6a7f5eca3e@github.com>

On Wed, 28 Aug 2024 13:35:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch54
>
> make/modules/java.desktop/lib/ClientLibraries.gmk line 284:
> 
>> 282: 
>> 283: ifeq ($(USE_EXTERNAL_HARFBUZZ), true)
>> 284:   LIBFONTMANAGER_EXTRA_SRC =
> 
> I think this 3space -> 2space indentation change shouldn't be part of this PR, esp. since 3space is
> used in other parts of this file.

Really? That is sooo broken. :( But fair enough, I'll do a separate PR on the broken indentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20733#discussion_r1734867997

From eirbjo at openjdk.org  Wed Aug 28 15:15:20 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 28 Aug 2024 15:15:20 GMT
Subject: RFR: 8336843: Deprecate java.util.zip.ZipError for removal
In-Reply-To: <RdZoRGPTtamByMOyg8p4Entv_jfHMnIURYQ73aHT8ks=.ea442115-c578-40f9-8517-2f58672aaa18@github.com>
References: <XQnNMTnuaPJUb7GyjlIkV1-3DuwMoeitMVli2RTTe1s=.9d366a05-2730-4d33-a20b-709b351a38a9@github.com>
 <04mDTpAYPyJc_PVg2TQq1Fmvf1p7PgfVJkHDcGETuhA=.723673dc-390e-4c1b-aebb-e9867fd9d665@github.com>
 <RdZoRGPTtamByMOyg8p4Entv_jfHMnIURYQ73aHT8ks=.ea442115-c578-40f9-8517-2f58672aaa18@github.com>
Message-ID: <wWNKTPCK1YSqVEVn8a-RQZlIM0Jrv6Yrf7PJ-y4OAvY=.d8ae5ebd-43f0-4248-9a47-310c072271b9@github.com>

On Sun, 25 Aug 2024 13:36:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`: https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637
>
>> I think linking to the CSR would be fine, but there is no prerequisite for API specs to link to CSRs. Need @jddarcy to double check here. I was emulating `Thread.stop`:
>> 
>> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/java.base/share/classes/java/lang/Thread.java#L1637
> 
> I am not suggesting link to the CSR, what I was indicating the CSR provides more details  because of the proposed removal.
> 
> Comparing to `Thread::stop` is not quite the same, and  the verbiage you are pointing to above was added when the method was [degraded to throw a UOE](https://bugs.openjdk.org/browse/JDK-8277861), not  when it was [deprecated for removal](https://bugs.openjdk.org/browse/JDK-8277861)
> 
> The overall usage of ZipError is extremely minimal in the wild at best, from what I can tell was in a catch statement and was not documented to be thrown by any public  API, though was thrown by ZipFile's internal ZipEntryIterator::next
> 
> If this was a more heavily used Exception, it would probably warrant further consideration for additional documentation, I am not convinced it is needed here

Thanks @LanceAndersen and @liach for your patient reviews.

I have updated the Specification section of the CSR and moved it to the Proposed state for an initial round of reviews:

https://bugs.openjdk.org/browse/JDK-8338663

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20642#issuecomment-2315639343

From kbarrett at openjdk.org  Wed Aug 28 15:17:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Aug 2024 15:17:52 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
Message-ID: <AGU85m2KKLxP9maWuwpt7XYjylhqg7ha5W-skjWyHvc=.fa1483d5-8898-402a-9719-42c056dd771c@github.com>

On Wed, 28 Aug 2024 15:15:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roll back indentation fix

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266590446

From ihse at openjdk.org  Wed Aug 28 15:17:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 28 Aug 2024 15:17:52 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Roll back indentation fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20733/files
  - new: https://git.openjdk.org/jdk/pull/20733/files/f4bdce72..88654b97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20733&range=04-05

  Stats: 35 lines in 1 file changed: 0 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/20733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20733/head:pull/20733

PR: https://git.openjdk.org/jdk/pull/20733

From eirbjo at openjdk.org  Wed Aug 28 15:26:23 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 28 Aug 2024 15:26:23 GMT
Subject: Integrated: 8338729: Retire the test
 jdk/java/util/zip/TestZipError.java
In-Reply-To: <2qQYLW8xwJAtu8UiUmvQVScFmXC61npdY6AYI-Yt5GY=.40c86241-851a-4ce7-9085-ac8bc7356924@github.com>
References: <2qQYLW8xwJAtu8UiUmvQVScFmXC61npdY6AYI-Yt5GY=.40c86241-851a-4ce7-9085-ac8bc7356924@github.com>
Message-ID: <EmHozauIWxR8nON4SqT4hr4lRmh6UNEoEhsKTRkPOZY=.e6261812-d50f-4952-89cb-f4258a7d8c39@github.com>

On Wed, 21 Aug 2024 09:59:38 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only, cleanup PR which proposes that we retire the `jdk/java/util/zip/TestZipError.java` test.
> 
> The test has fallen out of sync with its original and stated purpose described by its name, `@summary` tag and code comments. The error condition actually being exercised has existing coverage in the `ZipSourceCache` test.
> 
> Background:
> 
> * The test was initially added in JDK-4615343 (Java 6) to exercise code paths which caused `ZipFile` entry enumeration to throw a `ZipError` (a subclass of `InternalError`).
> * After the rewrite of the ZipFile API from native to Java in JDK-8145260 (JDK 9), the Java code now tested no longer throws `ZipError` (The `ZipError` class is no longer used in OpenJDK)
> * As part of JDK-8145260, `TestZipError.java` was updated to catch `ZipException` instead of `ZipError` for the expected/passing case. Interestingly, a line was added which caused the test to not simply enumerate the entries of the updated ZipFile, but to also consume the input stream of the entries.
> * The added line caused `ZipFileInputStream.initDataOffset` to throw a `ZipException` when the CEN local header offset does not contain the expected LOC header, resulting in a ZipException with the message "ZipFile invalid LOC header (bad signature)". This added line caused the test to (accidentally?) test something which is actually different than its original purpose. 
> * The "invalid LOC header" scenario is currently better tested by the `ZipSourceCache` JUnit test, which also runs on non-Windows platforms.
> * Note that JDK-8145260 did not update the copyright years in the license header of this file.
> 
> Considering all of the above, I suggest that we do not invest resources in bringing the naming, summary and code comments of this test in line with what is actually being tested. Instead, we should simply retire it in favor of the existing `ZipSourceCache` test.
> 
> Testing:
> 
> * No tests are updated in this PR, I added a `noreg-cleanup` label in the JBS
> * By collecting a stack trace, I verified that the `ZipException` caught by `TestZipError` is indeed caused by the LOC header validation logic in `ZipFileInputStream.initDataOffset`
> * Similarly, I also verified that `ZipSourceCache` throws on the same condition as `TestZipError`

This pull request has now been integrated.

Changeset: b6700095
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6700095c018a67a55b746cd4eee763c68f538e0
Stats:     116 lines in 1 file changed: 0 ins; 116 del; 0 mod

8338729: Retire the test jdk/java/util/zip/TestZipError.java

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/20660

From psandoz at openjdk.org  Wed Aug 28 15:32:24 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 28 Aug 2024 15:32:24 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v7]
In-Reply-To: <vP2hZ0cVv7PMHSP7WTkyElfYV0S3bCDKKYFIYctg74g=.00605162-454d-4fa6-9df4-1447cd137ca4@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <vP2hZ0cVv7PMHSP7WTkyElfYV0S3bCDKKYFIYctg74g=.00605162-454d-4fa6-9df4-1447cd137ca4@github.com>
Message-ID: <9EZ2LYvCH1Q-4VsOhPSiU_L9u5pGY7anPvfvLu1ZwKI=.8e0b4a63-2dea-4561-9839-855dcd5d421b@github.com>

On Wed, 28 Aug 2024 11:10:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make minor updates after comments

Current approach looks reasonable.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2266627806

From jwaters at openjdk.org  Wed Aug 28 15:34:20 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 28 Aug 2024 15:34:20 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
Message-ID: <y2q_LRB8SAoGsnPo-t3nLaUnqfdAR-DeBYz0a85s4cY=.73b4f9cb-589a-4e10-b288-29cf1f01aedf@github.com>

On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roll back indentation fix

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2266632564

From duke at openjdk.org  Wed Aug 28 15:35:19 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 28 Aug 2024 15:35:19 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
Message-ID: <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>

On Wed, 28 Aug 2024 09:06:48 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> How fast do we need to be here given we are measuring in a few nanoseconds per operation? 
>> 
>> What if the goal is not to regress from say explicitly filling in a small sized segment or a comparable array (e.g., < 8 bytes) then maybe a loop suffices and the code is simple?
>
>> How fast do we need to be here given we are measuring in a few nanoseconds per operation?
>> 
>> What if the goal is not to regress from say explicitly filling in a small sized segment or a comparable array (e.g., < 8 bytes) then maybe a loop suffices and the code is simple?
> 
> Fair question. I have another version (called "patch bits" below) that is based on bit logic (first doing int ops, then short and lastly byte, similar to `ArraySupport::vectorizedMismatch`). This has slightly worse performance but is more scalable and perhaps simpler.
> 
> ![image](https://github.com/user-attachments/assets/292c75aa-0df8-4bb7-b45f-426d0f8470d9)

@minborg Hi! I didn't checked the numbers with the benchmark I've written at https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is meant to stress the branch predictor (without enough `samples` i.e. past 128K on my machine) - can you give it a shot with M1 ? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2315685287

From coleenp at openjdk.org  Wed Aug 28 15:42:57 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Aug 2024 15:42:57 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'anon' of github.com:coleenp/jdk into anon
 - Fix copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19157/files
  - new: https://git.openjdk.org/jdk/pull/19157/files/94413cd1..1382ced0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19157/head:pull/19157

PR: https://git.openjdk.org/jdk/pull/19157

From coleenp at openjdk.org  Wed Aug 28 15:42:58 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Aug 2024 15:42:58 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v3]
In-Reply-To: <gE0DnzZhQ09_sYL1hP1KV_O5XwAX3aNJ3vbBN8pvhFk=.8e89d321-bcb3-4f36-8e3c-1ae5f53e4458@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <gksmhbijVVMK2RpMKHJD1bAyCxw4J9srhwZBp_NQN-o=.33986263-c9f5-4e38-9b9e-d220706299ca@github.com>
 <gE0DnzZhQ09_sYL1hP1KV_O5XwAX3aNJ3vbBN8pvhFk=.8e89d321-bcb3-4f36-8e3c-1ae5f53e4458@github.com>
Message-ID: <SB1KFHIkAvPi40Gzr1cZxHc3PiPDEQwY8SlCdxmhIn4=.ae7b763e-ba05-41a3-86c0-f2fc451fb5ec@github.com>

On Wed, 28 Aug 2024 05:57:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - With JDK-8338929 we don't need is_in_class_space().
>>  - Merge branch 'master' into anon
>>  - Incorporated a set of Thomas Stuefe's comments. Take out AbstractClass MetaspaceObj::Type.
>>  - 8338526: Don't store abstract and interface Klasses in class metaspace
>
> src/hotspot/share/oops/metadata.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> No more change in this file?

I removed the copyright.
I tried to add an assert to CompresssedKlassPointers::encode_not_null but CDS calls this with ill-formed Klass* pointers so the tests crash.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1734914543

From redestad at openjdk.org  Wed Aug 28 16:05:47 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 16:05:47 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing
 overheads
Message-ID: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>

Removing PrimitiveEntry reduces boxing/unboxing and removes a class.

-------------

Commit messages:
 - Revert tag rewrite
 - Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

Changes: https://git.openjdk.org/jdk/pull/20749/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339167
  Stats: 127 lines in 2 files changed: 81 ins; 22 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/20749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20749/head:pull/20749

PR: https://git.openjdk.org/jdk/pull/20749

From liach at openjdk.org  Wed Aug 28 16:05:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 16:05:48 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads
In-Reply-To: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
Message-ID: <OFvrheZLETJ8MepheKVqUtEc8USkKOPeJ8QWeAUevbA=.36b3c585-be4a-4ed8-9a33-8010dbbdcf02@github.com>

On Wed, 28 Aug 2024 14:27:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 1044:

> 1042:         @Override
> 1043:         void writeTo(BufWriterImpl pool) {
> 1044:             pool.writeU1(ClassFile.TAG_INTEGER);

Please either remove this change or propagate this change to all primitive number entries.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20749#discussion_r1734805023

From redestad at openjdk.org  Wed Aug 28 16:05:48 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 16:05:48 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads
In-Reply-To: <OFvrheZLETJ8MepheKVqUtEc8USkKOPeJ8QWeAUevbA=.36b3c585-be4a-4ed8-9a33-8010dbbdcf02@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
 <OFvrheZLETJ8MepheKVqUtEc8USkKOPeJ8QWeAUevbA=.36b3c585-be4a-4ed8-9a33-8010dbbdcf02@github.com>
Message-ID: <WFiyxp6WuPZVQBgACTJzOByWfp-gCyCUKiZher3LlCk=.4ef615ce-482d-4139-979c-653c8961a749@github.com>

On Wed, 28 Aug 2024 14:33:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 1044:
> 
>> 1042:         @Override
>> 1043:         void writeTo(BufWriterImpl pool) {
>> 1044:             pool.writeU1(ClassFile.TAG_INTEGER);
> 
> Please either remove this change or propagate this change to all primitive number entries.

Fixed. This one was unintended, but as you suggested offline perhaps we should rethink storing `tag` and `hash` in `AbstractPoolEntry` and let implementations decide on whether storing or calculating is best. Future work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20749#discussion_r1734939430

From sviswanathan at openjdk.org  Wed Aug 28 16:08:25 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 28 Aug 2024 16:08:25 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v2]
In-Reply-To: <agai02WarwvrKhvnB04UiBvmolhjJaMc6y8xk0xjytU=.def3d32b-7250-4a53-a4d3-679997edd22c@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <d31gmElDMBxt1yiojL9hKIb8S2kzngyrsF-BFP3rz8I=.fd28230a-1816-42c9-92f7-fa0a174afe6d@github.com>
 <ifmN4o7Vlw_DkSTFcYNa4YstawCFs3Ygw_24_QY5Qgg=.58067377-af46-46c8-af5a-aea1bd7f7389@github.com>
 <NRXC6AdWWN8uLMxD6m2HrtO8Qm2NdjR7jBUS-l-Tp7Y=.d19d28ec-7920-4b85-b90d-61675fbe0485@github.com>
 <x_q8qS3JoNQ-yL58IP9V-bgMTS6_NYPcZ2SpmKhz82M=.97577e35-8d16-4fb6-bbe7-8e079f7ba4ef@github.com>
 <QfgwwVXsYjjdGR65TfJJZjAXTS81OUyP-WOvWRRmfBk=.9e3ff6c8-201e-4b0e-93a2-9de753904279@github.com>
 <agai02WarwvrKhvnB04UiBvmolhjJaMc6y8xk0xjytU=.def3d32b-7250-4a53-a4d3-679997edd22c@github.com>
Message-ID: <Vv7j1ge8HBVY0I0nVq07uuSatyIwmQaqrk47grgTqJo=.2a89c118-3ed2-499e-92a5-e4fa006e32aa@github.com>

On Wed, 28 Aug 2024 00:12:26 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Hey @jaskarth , Central idea behind introducing VectorReinterpretNode after unsigned vector IR is to facilitate unboxing-boxing optimization, this explicit reinterpretation ensures type compatibility between value being boxed and box type which is always signed vector types.
>> 
>> As mentioned previously my plan is to address is handle  value range related concerns in a follow up patch along with intrisification and auto-vectorization of newly created scalar saturating IR, this patch is not generating scalar IR with newly defined unsigned types.
>
> Wonder if it would have been simpler if we added unsigned vector operators like Op_SaturatingUnsignedAddVB etc. We are not adding unsigned data types to Java, only supporting unsigned (saturating) operations on existing signed integral types.

If the aim is to reduce the number of nodes, we could merge the Op_SaturatingAddVB, Op_SaturatingAddVS, Op_SaturatingAddVI, and Op_SaturatingAddVL into one Op_SaturatingAddV. Likewise for unsigned saturating add into Op_SaturatingUnsignedAddV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1734951862

From sgehwolf at openjdk.org  Wed Aug 28 16:13:07 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 28 Aug 2024 16:13:07 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@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 10 additional commits since the last revision:

 - Add root check for SystemdMemoryAwarenessTest.java
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Add Whitebox check for host cpu
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - Merge branch 'master' into jdk-8333446-systemd-slice-tests
 - 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/eda249b4..7e8d9ed4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=04-05

  Stats: 6081 lines in 315 files changed: 4125 ins; 864 del; 1092 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  Wed Aug 28 16:13:07 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 28 Aug 2024 16:13:07 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v5]
In-Reply-To: <0MlDf-EYzm6DG3KhZTK9xJlXmb9CRkwhi4VwQGA5xgY=.3c38107b-5b73-4508-b245-45f15fac845a@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <yZvw5LMkV-A6lSj8AKOVqZFAQYEpB-jn53M4oBOQd7A=.26ceb992-e21e-48f2-8128-105ae602bde7@github.com>
 <dfkrfqnWOF7Mf7Ciz_GdHViivzuhST2eMIQ-q8iH2ms=.bf844897-92ec-46b8-9b3e-a08e21342337@github.com>
 <k-zoHJM6CDD5G55dr5PfIvcsmvuCtDjrZE8SaUnzaOU=.d108156f-9e2b-4722-99e0-aa8730527b69@github.com>
 <0MlDf-EYzm6DG3KhZTK9xJlXmb9CRkwhi4VwQGA5xgY=.3c38107b-5b73-4508-b245-45f15fac845a@github.com>
Message-ID: <WznWIFvf2M17g4Tvjg1t4VfhAvscI9LYFlzdP36UhuM=.e4a2e7fd-f11e-4b75-941c-cfc7295c2d91@github.com>

On Wed, 28 Aug 2024 14:21:09 GMT, Zdenek Zambersky <zzambers at openjdk.org> wrote:

> > > If I am not mistaken, new test requires, that testsuite is ran as superuser (root). (Because it writes `/etc/systemd/system`, runs certain systemd commands). Should test be skipped for non-root?
> > 
> > 
> > Thanks! I can add that. FWIW, container tests are in a similar situation (applying cpu/memory limits is not allowed in rootless on cg v1) and they don't check for it.
> 
> I think, it would be nice to skip on non-root, as tests are often ran as non-root. Thanks.

Done in https://github.com/openjdk/jdk/pull/19530/commits/7e8d9ed46815096ae8c4502f3320ebf5208438d5

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2315757991

From iklam at openjdk.org  Wed Aug 28 16:20:23 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 Aug 2024 16:20:23 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
Message-ID: <jHwWZwsfLDvY4d6kWIQLGipTGQrfVPbBmfjHx317KlY=.754f08d1-354c-4ecb-bea2-e419ac7e74ac@github.com>

On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'anon' of github.com:coleenp/jdk into anon
>  - Fix copyright

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/19157#pullrequestreview-2266738043

From liach at openjdk.org  Wed Aug 28 16:24:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 16:24:20 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads
In-Reply-To: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
Message-ID: <AAkUONaR4gKlYBNiUytPhEH0MuN8fw-ynT6lBRIBtQc=.dc9f99f6-08cb-4b81-b9d7-786b2c8e11e3@github.com>

On Wed, 28 Aug 2024 14:27:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.

Changes requested by liach (Reviewer).

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 1079:

> 1077: 
> 1078:         FloatEntryImpl(ConstantPool cpm, int index, float f) {
> 1079:             super(cpm, ClassFile.TAG_FLOAT, index, Float.hashCode(f));

Suggestion:

            super(cpm, ClassFile.TAG_FLOAT, index, hash1(ClassFile.TAG_FLOAT, Float.hashCode(f)));

-------------

PR Review: https://git.openjdk.org/jdk/pull/20749#pullrequestreview-2266744670
PR Review Comment: https://git.openjdk.org/jdk/pull/20749#discussion_r1734971814

From bpb at openjdk.org  Wed Aug 28 16:40:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 16:40:23 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <Ajej0x77lVAduuMvCQYcIfUF9IhTwbmmUx4Iz4-BLlQ=.318906eb-d6d6-466a-a5cb-c75d33473daf@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
 <Ajej0x77lVAduuMvCQYcIfUF9IhTwbmmUx4Iz4-BLlQ=.318906eb-d6d6-466a-a5cb-c75d33473daf@github.com>
Message-ID: <cBiKb6sUc-6xxhUSeM6bgAXF08CmgMq57fKp3Eh6OSc=.ffaacdd9-9229-43bc-a7e2-82c5ed789bf7@github.com>

On Wed, 28 Aug 2024 14:53:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8336895: Modified verbiage per reviewer comment
>
> src/java.base/share/classes/java/io/BufferedReader.java line 62:
> 
>> 60:  * replacing each DataInputStream with an appropriate BufferedReader.
>> 61:  *
>> 62:  * <p> More than one instance of BufferedReader should not be used with the
> 
> Nit - In the `BufferedInputStream` and the `BufferedOutputStream` we use `{@code ...}` to refer to these classes. Perhaps we should do the same here for `BufferedReader` and `Reader`? Same comment in the `BufferedWriter`  class update.

Yes, I saw that but did not want to change it in the initial pass(es) as it's too much noise. If things are otherwise quiescent, then I can change it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1734992217

From jpai at openjdk.org  Wed Aug 28 16:50:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Aug 2024 16:50:23 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
Message-ID: <FQGuOmyHYGtZAvtuVWlBPgTv54uOS-VHvKleFIzFh1c=.3890cb09-e9a4-4417-a656-1ab41b18a6e1@github.com>

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: Modified verbiage per reviewer comment

Marked as reviewed by jpai (Reviewer).

I think the changes look OK.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20320#pullrequestreview-2266799168
PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2315830248

From jpai at openjdk.org  Wed Aug 28 17:01:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Aug 2024 17:01:18 GMT
Subject: RFR: 8339126: JNI exception pending in Inflater.c
In-Reply-To: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
References: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
Message-ID: <SciRuN0OZuRbMKAPSFwInN7ty-u6cdOK0R2A8jRQUl0=.72e16ba2-8003-4933-a274-7b7823286a65@github.com>

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

Looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestreview-2266821773

From naoto at openjdk.org  Wed Aug 28 17:07:19 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Aug 2024 17:07:19 GMT
Subject: RFR: 8339126: JNI exception pending in Inflater.c
In-Reply-To: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
References: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
Message-ID: <uT8GcgKdzM76eL_YLnw8TVtkYJWPrNehv_UwvD7cUWM=.8a5cb277-4309-428e-a573-47c5f0eba580@github.com>

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20735#pullrequestreview-2266833278

From coleenp at openjdk.org  Wed Aug 28 17:19:25 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Aug 2024 17:19:25 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
Message-ID: <f2UO4j0sZ87xvTadqUJpgg11T7n9bTA8sTmB4lsEmnc=.d1f5af54-2855-4e59-9099-06418ad71147@github.com>

On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'anon' of github.com:coleenp/jdk into anon
>  - Fix copyright

Thanks Ioi.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2315880742

From jiangli at openjdk.org  Wed Aug 28 17:19:23 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 28 Aug 2024 17:19:23 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <BeiZn9bGbf4QnQp1NK-ICE4UMOWfQ69W9OFDi3wYrfo=.dbea5276-6770-4b67-8f4b-a1bd8ebd355b@github.com>
 <W4_qu1WmI5dVU7jOS1ppECKBnPdT_OjW0Qo5ZLDJyQo=.9ca295d5-ce8e-44f1-af69-027d3df54ffc@github.com>
Message-ID: <bhEaZtx3yqF8AHILP18elpVqLQKcnyrlrc9LKoMaMu0=.8562a11a-5bf7-4e9c-9168-d0697278b977@github.com>

On Tue, 27 Aug 2024 23:15:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> And the discussion whether the checks are made "dynamically" or "statically" is too simplified to be really helpful.
>> 
>> Currently, we compile two sets of all object files, with slightly different compiler arguments, one for dynamic libraries and one for static libraries. Files that are doing things differently for these two modes have an #ifdef, so the alternative way of doing things are not included in the object file. 
>> 
>> In your branch, you still have a separate compilation of all files for static builds, but you also try to figure out through various means (which involves jumping through some hoops to get the bootstrapping right) if this is a static build or a dynamic build. In a way, one could argue that this is just worse than the current solution, since you are still recompiling all files separately for static libraries so you could "know" at build time if you are static or not.
>> 
>> What I am trying to do is to get to a point where we can compile almost all files just once, and then have two trivially small files that are compiled twice, with just a different value of a define that makes the difference. To propagate this information to all other object files, they need to call the function provided in this object file. So, is it then a "build time" lookup or a "runtime lookup", or a "static lookup" vs "dynamic lookup"? The semantics does not really matter. The whole point is that the difference in build is reduced to an absolute minimum. Sure, this single "lookup" function could be created more like the way you are doing in your branch to try to figure this out without the help of the build system, but there is really no point in that. This is a simple and elegant solution.
>
> @magicus please also specify contributor properly to so it's clear part of the change is based on/extracted from https://github.com/openjdk/leyden/tree/hermetic-java-runtime.

> @jianglizhou Are there any other authors on the `hermetic-java-runtime` branch that should be credited?

For any commits in https://github.com/openjdk/leyden/compare/master...hermetic-java-runtime contributed by other contributor(s) or additional contributor(s), I documented that the commit message (e.g. https://github.com/openjdk/leyden/commit/4faa3a964ec550e410c741048c7e0ed99ac64b52). The current PR is related to the following. Please refer to those commit messages.

- https://github.com/openjdk/leyden/commit/7d75a7f4d6aa020b7580fbbf660b2b3e3a41b274
- https://github.com/openjdk/leyden/commit/22d8c439157b61acdfe99090d39f91c09388b1b1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2315882065

From coleenp at openjdk.org  Wed Aug 28 17:19:25 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Aug 2024 17:19:25 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <cm-SjRLYbstqXVvYQL4uEK_H4DI5z5oVetZGTMZqMsY=.8697b89b-8e16-40fc-9d82-809538abb436@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <0UeIWfhsJRNahI3I8r8wKfGlvWuY-0crKHqGxbPXk5o=.6b9ff3f1-f297-40f0-9c81-99507c2b2880@github.com>
 <77NWcTx23rX8UnhRcnOqS36y4Y-7-zDEf3hyYD1bcbw=.6f02be24-3cd2-44d8-8483-934295aab9fd@github.com>
 <MZftBPrG2vDEMDK7LDuyyvNTnxi42GdCtP9UtwOijjc=.40ccfb67-a338-47f7-b310-28546b4100be@github.com>
 <cm-SjRLYbstqXVvYQL4uEK_H4DI5z5oVetZGTMZqMsY=.8697b89b-8e16-40fc-9d82-809538abb436@github.com>
Message-ID: <SurIBzKcGPNIArXc-jsVdDW12fXdcMMrXHjiv5TbSuI=.e1e3e27a-79a1-4eab-8975-afbb9ef9553c@github.com>

On Wed, 21 Aug 2024 21:32:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I feel like making it ACC_INTERFACE might cause some error if there are no public nonstatic methods, which is the case with this class. I don't know what @liach your comment means, but this code got more complicated than it was with the first version of this change.  When I talked to @rose00 he thought ACC_ABSTRACT would be okay for this.
>
> Yes, you are right that we currently don't add ACC_PUBLIC flags on methods, which will fail if we add ACC_INTERFACE. Same for the fields; these LambdaForm classes use fields to store class data that's usually stored as condy, because LambdaForm is the infrastructure that condy uses (like LambdaMetafacotry cannot use lambdas). Those fields are my concerns for the interface migration.

Thanks for reviewing this part.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1735039561

From redestad at openjdk.org  Wed Aug 28 17:51:52 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 17:51:52 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads [v2]
In-Reply-To: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
Message-ID: <Lj5tF3QaKfWdWrNIuzhxGYhp9L588GhrAnkA6JlP7nE=.3c6d4ee4-22c1-42e7-ae59-adda20254d13@github.com>

> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Wrong hash for FloatEntryImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20749/files
  - new: https://git.openjdk.org/jdk/pull/20749/files/028c0e9b..e7dbd1c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20749&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20749&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20749.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20749/head:pull/20749

PR: https://git.openjdk.org/jdk/pull/20749

From lancea at openjdk.org  Wed Aug 28 17:53:26 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Aug 2024 17:53:26 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v9]
In-Reply-To: <uCe-ROsBsSqWzakkOT1bIP0RyKuPNDRzKg3mQsEWcUE=.ed7fdaed-8285-4062-ba97-495f0ccc9278@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <uCe-ROsBsSqWzakkOT1bIP0RyKuPNDRzKg3mQsEWcUE=.ed7fdaed-8285-4062-ba97-495f0ccc9278@github.com>
Message-ID: <qQ8-D2YKHinhumPCTNMmR9TdBt86tYtpp0_GvGWZqaA=.22ca2687-9814-4c24-bf3c-8d925f433b8d@github.com>

On Sun, 11 Aug 2024 18:58:05 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert all functional changes, leaving only tests & Javadoc.

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 43:

> 41:  * frame that marks the end of the compressed data. Therefore it's possible for the underlying
> 42:  * input to contain additional data beyond the end of the compressed GZIP data. In particular,
> 43:  * some GZIP compression tools function by partitioning the input, compressing each parttion

I think we need to simplify the above  keeping the focus on that GZIPInputStream supports the reading of concatenated  Gzip streams.  After reading  a streams trailer(though some docs refer to it as a footer, but I think we go with trailer),  if an additional gzip header is found, the stream will be decompressed... etc.. 

If there is additional data/byes after the trailer that does not represent another gzip, header, it will indicate you have reached the end of the input stream

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1735080776

From liach at openjdk.org  Wed Aug 28 17:58:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 17:58:22 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads [v2]
In-Reply-To: <Lj5tF3QaKfWdWrNIuzhxGYhp9L588GhrAnkA6JlP7nE=.3c6d4ee4-22c1-42e7-ae59-adda20254d13@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
 <Lj5tF3QaKfWdWrNIuzhxGYhp9L588GhrAnkA6JlP7nE=.3c6d4ee4-22c1-42e7-ae59-adda20254d13@github.com>
Message-ID: <XhMXWWfEjBzS8KlERkAOKRNgtQ55vBas3dHmcIvH3Uc=.bdbd26f6-9322-499a-a98c-b5d01ba2c5be@github.com>

On Wed, 28 Aug 2024 17:51:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrong hash for FloatEntryImpl

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20749#pullrequestreview-2266928775

From bpb at openjdk.org  Wed Aug 28 18:04:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 18:04:33 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v4]
In-Reply-To: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
Message-ID: <rJRhnj4YvOV-_e13zm8a818JbkU3lrbmuJIKwEfzjd0=.492c1356-5147-4252-aa21-2e1964cda646@github.com>

> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8336895: "  Doing" -> " Doing" and add some {@code} tags

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20320/files
  - new: https://git.openjdk.org/jdk/pull/20320/files/268b5eec..d6831f92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20320&range=02-03

  Stats: 33 lines in 4 files changed: 3 ins; 0 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/20320.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20320/head:pull/20320

PR: https://git.openjdk.org/jdk/pull/20320

From bpb at openjdk.org  Wed Aug 28 18:04:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 18:04:34 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
Message-ID: <FARDaaT0iVXvaDEj9bfkCX4KDOGKq62LL3lAdT3GOjk=.5d9dd49b-e4f6-4d6c-9d40-6958b12e05f2@github.com>

On Fri, 26 Jul 2024 22:32:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage stating that two buffered readers or input streams should not be used to read from the same reader or input stream, respectively.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8336895: Modified verbiage per reviewer comment

There seems to be consensus on this so I will file a CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20320#issuecomment-2315956908

From bpb at openjdk.org  Wed Aug 28 18:04:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 18:04:34 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <Ajej0x77lVAduuMvCQYcIfUF9IhTwbmmUx4Iz4-BLlQ=.318906eb-d6d6-466a-a5cb-c75d33473daf@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
 <Ajej0x77lVAduuMvCQYcIfUF9IhTwbmmUx4Iz4-BLlQ=.318906eb-d6d6-466a-a5cb-c75d33473daf@github.com>
Message-ID: <b_3Ap47kBrD1korfb0zrxGKeGWa_mFH-Yjhrz7ls4LA=.95aff6fd-eb94-4062-9894-22d5c1fa3dc2@github.com>

On Wed, 28 Aug 2024 14:49:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8336895: Modified verbiage per reviewer comment
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 54:
> 
>> 52:  *
>> 53:  * <p> More than one instance of {@code BufferedInputStream} should not be
>> 54:  * used with the same underlying {@code InputStream} instance.  Doing
> 
> Nit - there's one extra space here before the `Doing`. Same in the other classes as well.

Fixed in d6831f9.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1735090263

From bpb at openjdk.org  Wed Aug 28 18:04:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 18:04:34 GMT
Subject: RFR: 8336895: BufferedReader doesn't read full \r\n line ending
 when it doesn't fit in buffer [v3]
In-Reply-To: <cBiKb6sUc-6xxhUSeM6bgAXF08CmgMq57fKp3Eh6OSc=.ffaacdd9-9229-43bc-a7e2-82c5ed789bf7@github.com>
References: <a-uDYpr9kyzRvJLQzRQk_4WBvfVtvxtgyRNLcD92P6k=.40eacde5-0253-493a-8a16-5874ce05a5b6@github.com>
 <Ulv6Sg9qmyyjl2iDUZuizQqt3_xZPyMzJQJ6aWoxUGw=.2a7d5865-2457-4f45-a982-b4a3903c362a@github.com>
 <Ajej0x77lVAduuMvCQYcIfUF9IhTwbmmUx4Iz4-BLlQ=.318906eb-d6d6-466a-a5cb-c75d33473daf@github.com>
 <cBiKb6sUc-6xxhUSeM6bgAXF08CmgMq57fKp3Eh6OSc=.ffaacdd9-9229-43bc-a7e2-82c5ed789bf7@github.com>
Message-ID: <xnoDbysHEkUOrXthGTvwzan5J_Ss9MnadlvnFtBex2s=.5a4171fb-21a2-41fd-9004-c284044a98c4@github.com>

On Wed, 28 Aug 2024 16:38:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedReader.java line 62:
>> 
>>> 60:  * replacing each DataInputStream with an appropriate BufferedReader.
>>> 61:  *
>>> 62:  * <p> More than one instance of BufferedReader should not be used with the
>> 
>> Nit - In the `BufferedInputStream` and the `BufferedOutputStream` we use `{@code ...}` to refer to these classes. Perhaps we should do the same here for `BufferedReader` and `Reader`? Same comment in the `BufferedWriter`  class update.
>
> Yes, I saw that but did not want to change it in the initial pass(es) as it's too much noise. If things are otherwise quiescent, then I can change it.

Fixed in d6831f9 and added a link for `line.separator`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20320#discussion_r1735090929

From acobbs at openjdk.org  Wed Aug 28 18:11:22 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 28 Aug 2024 18:11:22 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v9]
In-Reply-To: <qQ8-D2YKHinhumPCTNMmR9TdBt86tYtpp0_GvGWZqaA=.22ca2687-9814-4c24-bf3c-8d925f433b8d@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <uCe-ROsBsSqWzakkOT1bIP0RyKuPNDRzKg3mQsEWcUE=.ed7fdaed-8285-4062-ba97-495f0ccc9278@github.com>
 <qQ8-D2YKHinhumPCTNMmR9TdBt86tYtpp0_GvGWZqaA=.22ca2687-9814-4c24-bf3c-8d925f433b8d@github.com>
Message-ID: <rai3hHx1M5D6S24ugOsgm_oCeRYaVuCOU01D8SpiMng=.257fa6c4-6ece-4e39-a492-46f16e5a8111@github.com>

On Wed, 28 Aug 2024 17:50:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert all functional changes, leaving only tests & Javadoc.
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 43:
> 
>> 41:  * frame that marks the end of the compressed data. Therefore it's possible for the underlying
>> 42:  * input to contain additional data beyond the end of the compressed GZIP data. In particular,
>> 43:  * some GZIP compression tools function by partitioning the input, compressing each parttion
> 
> I think we need to simplify the above  keeping the focus on that GZIPInputStream supports the reading of concatenated  Gzip streams.  After reading  a streams trailer(though some docs refer to it as a footer, but I think we go with trailer),  if an additional gzip header is found, the stream will be decompressed... etc.. 
> 
> If there is additional data/byes after the trailer that does not represent another gzip, header, it will indicate you have reached the end of the input stream

Sounds good. How would you like to do that?

E.g. we could just remove the words "In particular, some GZIP compression tools function by partitioning the input, compressing each partition separately, and then concatenating the resulting compressed data streams. To support this kind of input".  We could also remove "In the latter case, the number of additional bytes that were read is unspecified." Or something else (what would you suggest?)

Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1735101196

From redestad at openjdk.org  Wed Aug 28 18:18:33 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 18:18:33 GMT
Subject: RFR: 8338897: Small startup regression remains after JDK-8309622
 and JDK-8331932 [v2]
In-Reply-To: <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
 <QP2b9lbEEM9m3UttP1rQ1xLbHjj6f5kbweTLr3vfK4M=.5e1b7a7a-ced4-479d-b4ee-50b59fa085be@github.com>
Message-ID: <DpSoPE8m9nDyLDXOMZd59HcgLkWFecavSfmSY3evimE=.d89350c7-0406-449d-a39b-e719f5ecf3b2@github.com>

On Mon, 26 Aug 2024 14:00:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
>> 
>> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final

Thanks for reviewing!

I'll use 8338897 for this even though I'm not sure this resolves the observed regression entirely. Feel free to log a new issue if there's still some lengths to go.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20713#issuecomment-2315981023

From redestad at openjdk.org  Wed Aug 28 18:18:34 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 18:18:34 GMT
Subject: Integrated: 8338897: Small startup regression remains after
 JDK-8309622 and JDK-8331932
In-Reply-To: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
References: <CVI5VtZYl-ZxeWQaBh-UoEO28A8ckO1jRdvXLJSQPsA=.484186f9-91ee-42ed-b537-8d50a7dde253@github.com>
Message-ID: <qw3IIy8h6SIuMY8oUmzzycEx--_QI93IS3tw4hUc2fM=.5503d252-182a-4d2c-9234-8b913ce0ca6f@github.com>

On Mon, 26 Aug 2024 13:30:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> #14404 caused some startup regressions, where the main cause of startup increase in that change was due the use of - and the not very optimized state of - runtime bootstrapped switches. This was remedied by a series of optimizations to the switch bootstrap methods and finally a desugaring of the switch added by #14404. Now @shipilev reports that there appears to be some lingering startup issue from #14404. 
> 
> One thing that stands out is a couple of caches which are being eagerly initialized regardless of user locale. This PR makes those caches lazily initialized and slightly more efficient (no need to implement `UnaryOperator` after inlining some code). Avoids loading 4 classes if running the HelloStream startup test in a locale that's in the set of constant base locales, 2 otherwise. This doesn't really do much to move the needle for startup on my setup, but tentatively it's the only remaining inefficiency I've found that came from #14404.

This pull request has now been integrated.

Changeset: a98ecad0
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a98ecad0a920f12d81386de3d0f549d542014773
Stats:     37 lines in 2 files changed: 12 ins; 16 del; 9 mod

8338897: Small startup regression remains after JDK-8309622 and JDK-8331932

Reviewed-by: liach, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20713

From redestad at openjdk.org  Wed Aug 28 18:25:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 18:25:23 GMT
Subject: RFR: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads [v2]
In-Reply-To: <Lj5tF3QaKfWdWrNIuzhxGYhp9L588GhrAnkA6JlP7nE=.3c6d4ee4-22c1-42e7-ae59-adda20254d13@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
 <Lj5tF3QaKfWdWrNIuzhxGYhp9L588GhrAnkA6JlP7nE=.3c6d4ee4-22c1-42e7-ae59-adda20254d13@github.com>
Message-ID: <RrylRrm_56JlhNs4fRoIIdqupyPX_73gHpYHs3TzyqY=.9972e7ba-5949-425c-aa6a-b0aed32e46dd@github.com>

On Wed, 28 Aug 2024 17:51:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrong hash for FloatEntryImpl

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20749#issuecomment-2315990919

From redestad at openjdk.org  Wed Aug 28 18:25:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 18:25:23 GMT
Subject: Integrated: 8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce
 boxing overheads
In-Reply-To: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
References: <H1vzE8Unb-XTsnkg1u7T3Jzt95Y7O2SRhHGt1fHzFMI=.d72e3103-035c-4e9b-8a42-8d0e25fdff3e@github.com>
Message-ID: <ayEMmu2yBZFGm_UJ2mvt5_SDQovNirUW5QOxORO_frk=.2dc0aaf1-1743-455d-b560-2bd38a60a9bd@github.com>

On Wed, 28 Aug 2024 14:27:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Removing PrimitiveEntry reduces boxing/unboxing and removes a class.

This pull request has now been integrated.

Changeset: eff6d9cd
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eff6d9cd23f9da8720a44ad628aa0a3e6f58facf
Stats:     127 lines in 2 files changed: 81 ins; 22 del; 24 mod

8339167: Remove AbstractPoolEntry.PrimitiveEntry to reduce boxing overheads

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/20749

From bchristi at openjdk.org  Wed Aug 28 18:35:32 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 28 Aug 2024 18:35:32 GMT
Subject: RFR: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource [v2]
In-Reply-To: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
References: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
Message-ID: <_rX2WAky69lAAEJoVKr-mB3cavdDo54rXjqf_OQTKVQ=.e1db0fd0-3577-40cd-ab36-6760f75d5a55@github.com>

> The InterruptibleIO feature (which was only on Solaris) was removed some time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444).
> 
> Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  move getContentLength() inside try block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20736/files
  - new: https://git.openjdk.org/jdk/pull/20736/files/5eefe663..86d5a5a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20736&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20736&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20736/head:pull/20736

PR: https://git.openjdk.org/jdk/pull/20736

From bchristi at openjdk.org  Wed Aug 28 18:35:32 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 28 Aug 2024 18:35:32 GMT
Subject: RFR: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource [v2]
In-Reply-To: <kqj71jUzZNfWRr96QRF7NvQIgvxvphRE31FREWoJxxE=.0fee3cbf-0f4a-4e16-9758-e1a4d7feb1f2@github.com>
References: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
 <kqj71jUzZNfWRr96QRF7NvQIgvxvphRE31FREWoJxxE=.0fee3cbf-0f4a-4e16-9758-e1a4d7feb1f2@github.com>
Message-ID: <tTHddPUItNenxJj734o9t7-FGPlsUWOFzDeLK7w9Yk8=.9d513710-cee7-4767-afb1-205d22bdba67@github.com>

On Wed, 28 Aug 2024 06:32:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move getContentLength() inside try block
>
> src/java.base/share/classes/jdk/internal/loader/Resource.java line 89:
> 
>> 87:         // can propagate upwards without being caught too early
>> 88:         InputStream in = cachedInputStream();
>> 89:         int len = getContentLength();
> 
> Pre-existing issue but I wonder if this should move into the try block so that the input stream is closed in the event of getContentLength failing.

I agree, that seems like a good idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20736#discussion_r1735128133

From alanb at openjdk.org  Wed Aug 28 18:42:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Aug 2024 18:42:21 GMT
Subject: RFR: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource [v2]
In-Reply-To: <_rX2WAky69lAAEJoVKr-mB3cavdDo54rXjqf_OQTKVQ=.e1db0fd0-3577-40cd-ab36-6760f75d5a55@github.com>
References: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
 <_rX2WAky69lAAEJoVKr-mB3cavdDo54rXjqf_OQTKVQ=.e1db0fd0-3577-40cd-ab36-6760f75d5a55@github.com>
Message-ID: <DmMw6Do0iLKRY2NFFiyqC6HwkLZDSMmefJFN243k0qE=.10f8a9b7-0577-45ea-8715-fa495aa79ce3@github.com>

On Wed, 28 Aug 2024 18:35:32 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> The InterruptibleIO feature (which was only on Solaris) was removed some time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444).
>> 
>> Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move getContentLength() inside try block

I think this looks okay. I suspect the catching of IOException from close can be removed too but we don't have to do that now.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20736#pullrequestreview-2267010682

From bpb at openjdk.org  Wed Aug 28 19:13:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 19:13:19 GMT
Subject: RFR: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix [v2]
In-Reply-To: <JuJIDUcx7EIZShK-nnW8GTrZTmVw6CdPrqes6i0Pgac=.6d2352d8-be73-4d31-9b4f-2e017b886526@github.com>
References: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
 <JuJIDUcx7EIZShK-nnW8GTrZTmVw6CdPrqes6i0Pgac=.6d2352d8-be73-4d31-9b4f-2e017b886526@github.com>
Message-ID: <opia4v29XMJOglbX2UJmrZ0xNJhj5kXWgTckDol0wHI=.d5fe2856-4d0e-4ea2-a838-de6cfa3f8fbc@github.com>

On Fri, 2 Aug 2024 08:44:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6426678: having the generated name -> with the generated name
>
> src/java.base/share/classes/java/io/File.java line 2120:
> 
>> 2118:      * prefix, five or more internally-generated characters, and the suffix.
>> 2119:      *
>> 2120:      * <p> If a file having the generated name cannot be created by the
> 
> I think it might be clear to say "with the generated name".

So changed in 64440ec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20435#discussion_r1735169219

From aturbanov at openjdk.org  Wed Aug 28 19:30:21 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 28 Aug 2024 19:30:21 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects
In-Reply-To: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
Message-ID: <CEretR2oiIrhoTlUIn7Sy6zplaQKxBSyJSwGXGi5jSo=.45658ebf-3e7f-4bac-9096-74e754ab48a3@github.com>

On Wed, 28 Aug 2024 01:49:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 657:

> 655:                 };
> 656:             if (value instanceof Long lVal)
> 657:                 return lVal == 0l ? lconst_0()

Suggestion:

                return lVal == 0L ? lconst_0()

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 658:

> 656:             if (value instanceof Long lVal)
> 657:                 return lVal == 0l ? lconst_0()
> 658:                         : lVal == 1l ? lconst_1()

Suggestion:

                        : lVal == 1L ? lconst_1()

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 666:

> 664:                         : ldc(constantPool().floatEntry(fVal));
> 665:             if (value instanceof Double dVal)
> 666:                 return Double.doubleToRawLongBits(dVal) == 0l ? dconst_0()

Suggestion:

                return Double.doubleToRawLongBits(dVal) == 0L ? dconst_0()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20738#discussion_r1735187162
PR Review Comment: https://git.openjdk.org/jdk/pull/20738#discussion_r1735187339
PR Review Comment: https://git.openjdk.org/jdk/pull/20738#discussion_r1735187623

From erikj at openjdk.org  Wed Aug 28 19:36:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 28 Aug 2024 19:36:19 GMT
Subject: RFR: 8339120: Use more fine-granular gcc unused warnings [v6]
In-Reply-To: <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
 <O-r-qYjq4hOO6wR08EZgDB_wNd2XDP-kFfkWToEv5Ig=.cae8eedd-9dba-433e-8e56-198e56bf73af@github.com>
Message-ID: <QbwTh_Qzgj4o-CKhBYF33ichnJLXVX5RvY_Z2a0OhY4=.f6964407-a5c3-4307-b083-140cefa7d23c@github.com>

On Wed, 28 Aug 2024 15:17:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roll back indentation fix

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20733#pullrequestreview-2267102496

From liach at openjdk.org  Wed Aug 28 19:56:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 19:56:53 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects [v2]
In-Reply-To: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
Message-ID: <FsX_GDq7_k2KBq3_5bA8Dx5Pfz8gS9gcXy6RQ-9q8ts=.2e3505b8-0670-44a8-bbde-629586154c7a@github.com>

> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Use uppercase L for long literals
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20738/files
  - new: https://git.openjdk.org/jdk/pull/20738/files/2a3b2cf6..d798b302

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20738&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20738&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20738/head:pull/20738

PR: https://git.openjdk.org/jdk/pull/20738

From lancea at openjdk.org  Wed Aug 28 19:58:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 28 Aug 2024 19:58:20 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v9]
In-Reply-To: <rai3hHx1M5D6S24ugOsgm_oCeRYaVuCOU01D8SpiMng=.257fa6c4-6ece-4e39-a492-46f16e5a8111@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <uCe-ROsBsSqWzakkOT1bIP0RyKuPNDRzKg3mQsEWcUE=.ed7fdaed-8285-4062-ba97-495f0ccc9278@github.com>
 <qQ8-D2YKHinhumPCTNMmR9TdBt86tYtpp0_GvGWZqaA=.22ca2687-9814-4c24-bf3c-8d925f433b8d@github.com>
 <rai3hHx1M5D6S24ugOsgm_oCeRYaVuCOU01D8SpiMng=.257fa6c4-6ece-4e39-a492-46f16e5a8111@github.com>
Message-ID: <PxxFpha2Q6oIz6a1QRjyFNLgkv8zecZy-NTtUeDx0yM=.edf54b62-fef1-480b-b35e-c2ee69ff813b@github.com>

On Wed, 28 Aug 2024 18:08:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Sounds good. How would you like to do that?
> 
> E.g. we could just remove the words "In particular, some GZIP compression tools function by partitioning the input, compressing each partition separately, and then concatenating the resulting compressed data streams. To support this kind of input". We could also remove "In the latter case, the number of additional bytes that were read is unspecified." Or something else (what would you suggest?)
> 
> Thanks.

Yes, no reason to talk about gzip tools.  The focus should be that this method can read concatenated gzip streams when there is a gzip header immediately after the gzip trailer, otherwise additional bytes are treated as End of stream

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1735217188

From swen at openjdk.org  Wed Aug 28 20:05:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 20:05:50 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
Message-ID: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>

A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

-------------

Commit messages:
 - refactor
 - optimize BufWriterImpl#writeU1/U2/Int/Long

Changes: https://git.openjdk.org/jdk/pull/20748/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20748&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339196
  Stats: 42 lines in 1 file changed: 32 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20748.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20748/head:pull/20748

PR: https://git.openjdk.org/jdk/pull/20748

From swen at openjdk.org  Wed Aug 28 20:05:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 20:05:50 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <djVzgEgbrwN_bXVErLWAMsNz1OjbVPqmQdrqN16qzyA=.fb95ce41-7a6d-412b-88de-ccc40d4de27f@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

@liach 
Is this what you want to see?

## baseline

@ 29   jdk.internal.classfile.impl.BufWriterImpl::writeU1 (8 bytes)   inline (hot)
  @ 4   jdk.internal.classfile.impl.BufWriterImpl::writeIntBytes (54 bytes)   inline (hot)
    @ 2   jdk.internal.classfile.impl.BufWriterImpl::reserveSpace (52 bytes)   inline (hot)
      @ 45   java.util.Arrays::copyOf (33 bytes)   failed to inline: low call site frequency

@ 77   jdk.internal.classfile.impl.BufWriterImpl::writeU2 (8 bytes)   inline (hot)
  @ 4   jdk.internal.classfile.impl.BufWriterImpl::writeIntBytes (54 bytes)   inline (hot)
    @ 2   jdk.internal.classfile.impl.BufWriterImpl::reserveSpace (52 bytes)   inline (hot)
      @ 45   java.util.Arrays::copyOf (33 bytes)   failed to inline: low call site frequency


## current

@ 113   jdk.internal.classfile.impl.BufWriterImpl::writeU1 (24 bytes)   inline (hot)
  @ 2   jdk.internal.classfile.impl.BufWriterImpl::reserveSpace (22 bytes)   inline (hot)
    @ 18   jdk.internal.classfile.impl.BufWriterImpl::grow (33 bytes)   failed to inline: low call site frequency

@ 58   jdk.internal.classfile.impl.BufWriterImpl::writeU2 (38 bytes)   inline (hot)
  @ 2   jdk.internal.classfile.impl.BufWriterImpl::reserveSpace (22 bytes)   inline (hot)
    @ 18   jdk.internal.classfile.impl.BufWriterImpl::grow (33 bytes)   failed to inline: low call site frequency

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20748#issuecomment-2315596836

From redestad at openjdk.org  Wed Aug 28 20:05:50 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 20:05:50 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <5TThg73qqoMijDN7l-fIQX6Wvon3jo_cl5mXsHx-Wu0=.d5d0c3f9-3fcf-4aba-a13f-a30a7db6b1c5@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

I made an off-list suggestion along this line some time before integration. IIRC it was a decent win back then, and with the merge store optimizations in place it might be even more impactful now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20748#issuecomment-2316019489

From liach at openjdk.org  Wed Aug 28 20:05:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 20:05:50 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <K3eP-0BWXu2uKiXu5vDZ2nfc7KTTtMOUGf6godKhcXs=.3eb90bb9-b944-4649-911d-6d1dd99594bc@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java line 124:

> 122:     public void writeLong(long x) {
> 123:         reserveSpace(8);
> 124:         elems[offset    ] = (byte) (x >> 56);

Since elems is mutable, should we pull it to a local variable and write instead? Does C2 optimize this current code in compile logs?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20748#discussion_r1734740549

From liach at openjdk.org  Wed Aug 28 20:11:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 20:11:19 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <mjz50Jh_LYH8fzv4b0Rn3-VHNsvQSVOEAMrsbfiGF9E=.b2fe540c-a5fd-4529-9284-045ee98952d1@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20748#pullrequestreview-2267171302

From redestad at openjdk.org  Wed Aug 28 20:39:21 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 28 Aug 2024 20:39:21 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects [v2]
In-Reply-To: <FsX_GDq7_k2KBq3_5bA8Dx5Pfz8gS9gcXy6RQ-9q8ts=.2e3505b8-0670-44a8-bbde-629586154c7a@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
 <FsX_GDq7_k2KBq3_5bA8Dx5Pfz8gS9gcXy6RQ-9q8ts=.2e3505b8-0670-44a8-bbde-629586154c7a@github.com>
Message-ID: <qb-_P3JsWyu7KvGO3fV0Qv4dyaJXWal0JgHhf9ELF-Y=.8cc7801c-d459-4d61-aefe-32658885474a@github.com>

On Wed, 28 Aug 2024 19:56:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use uppercase L for long literals
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20738#pullrequestreview-2267222497

From liach at openjdk.org  Wed Aug 28 20:53:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 20:53:14 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v2]
In-Reply-To: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
Message-ID: <8pnK4m5ddLDqUykh0v_vnzry5U_mSMzLVoqZScLhTz8=.ec6f4076-56b3-46d0-a793-7a3d1401d85d@github.com>

> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
> 
> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
> 
> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
> 
> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.

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 three additional commits since the last revision:

 - More fixes, reorder constants
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
 - 8339115: Rename TypeKind enum constants to follow code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20737/files
  - new: https://git.openjdk.org/jdk/pull/20737/files/f686716f..b7c499fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=00-01

  Stats: 3432 lines in 65 files changed: 2324 ins; 537 del; 571 mod
  Patch: https://git.openjdk.org/jdk/pull/20737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20737/head:pull/20737

PR: https://git.openjdk.org/jdk/pull/20737

From liach at openjdk.org  Wed Aug 28 21:14:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 21:14:50 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects [v3]
In-Reply-To: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
Message-ID: <MI1RpfmLOIWHXp9DzkFbwnWnUwS68bP7akDFqc1yHC4=.f4ecaa47-dcf2-43a6-bf77-b29f9cc04d69@github.com>

> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.

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:

 - Remove redundant qualification, avoid boxing in b/sipush validation
 - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cob-direct-methods
 - Use uppercase L for long literals
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Moar fixes
 - More direct code builder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20738/files
  - new: https://git.openjdk.org/jdk/pull/20738/files/d798b302..a12992d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20738&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20738&range=01-02

  Stats: 2927 lines in 47 files changed: 1943 ins; 509 del; 475 mod
  Patch: https://git.openjdk.org/jdk/pull/20738.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20738/head:pull/20738

PR: https://git.openjdk.org/jdk/pull/20738

From liach at openjdk.org  Wed Aug 28 21:16:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 21:16:26 GMT
Subject: RFR: 8339158: TypeKind add slotSize field
In-Reply-To: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
References: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
Message-ID: <3RD-qoKQBUSB-92tTMGa61Owfsh-FHy3GCN4NlKcSCs=.d3ae6154-f3c4-44f8-9bf7-574cc7800a1a@github.com>

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Small improvement, add a final field, no need to calculate every time.

I think this is now part of #20737.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20743#issuecomment-2316262099

From jlu at openjdk.org  Wed Aug 28 21:17:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Aug 2024 21:17:26 GMT
Subject: RFR: 8339126: JNI exception pending in Inflater.c
In-Reply-To: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
References: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
Message-ID: <gTTI2cVdL2QJm51MyrIiv8Q8_D3MXAYCa4B6jIK_Bs0=.c0064b41-6b24-499d-b377-a8c083c1814e@github.com>

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20735#issuecomment-2316262343

From jlu at openjdk.org  Wed Aug 28 21:17:27 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Aug 2024 21:17:27 GMT
Subject: Integrated: 8339126: JNI exception pending in Inflater.c
In-Reply-To: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
References: <jt_2iUbMj00e6bxKuMzNSkCfjSll9r78jVPg_teaMOc=.33c77bbd-7e9e-4c3f-9454-e038e7ab644a@github.com>
Message-ID: <ahcE0qytWR8xc0G6LQFu4n7MYozvk3wGrlXWIJ6pxps=.adca9480-ce8b-4678-b0ce-aaa20313fc87@github.com>

On Tue, 27 Aug 2024 21:26:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses the JNI pending exception in Inflater.c, under `Java_java_util_zip_Inflater_initIDs`.

This pull request has now been integrated.

Changeset: a8ac2872
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8ac28725bfc22867c76856ddce094588a97b84c
Stats:     3 lines in 1 file changed: 1 ins; 1 del; 1 mod

8339126: JNI exception pending in Inflater.c

Reviewed-by: lancea, vtewari, jpai, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20735

From liach at openjdk.org  Wed Aug 28 21:24:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 21:24:34 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v3]
In-Reply-To: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
Message-ID: <Fr2Q9FINC96w4JPjxPw_pN1XDjJQ5_ABP_DdqpkF6W8=.4dd875d1-4aa1-490a-a598-b9debe76045a@github.com>

> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
> 
> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
> 
> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
> 
> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20737/files
  - new: https://git.openjdk.org/jdk/pull/20737/files/b7c499fa..41f81fe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20737/head:pull/20737

PR: https://git.openjdk.org/jdk/pull/20737

From swen at openjdk.org  Wed Aug 28 21:51:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 21:51:22 GMT
Subject: Withdrawn: 8339158: TypeKind add slotSize field
In-Reply-To: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
References: <b97ky3LDyJiO3y0k29yeIFY2MJ5ws2-afKk-QohJir0=.1196a7b1-fa2d-47dc-a0c3-bfe05fe2f26b@github.com>
Message-ID: <6qYcvUa5BaQ_HHcgYN7tUERi5q3zm9y7c-RWQhwcbO4=.e9138a11-b309-472d-bc78-05a52ccffcc1@github.com>

On Wed, 28 Aug 2024 10:26:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Small improvement, add a final field, no need to calculate every time.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20743

From acobbs at openjdk.org  Wed Aug 28 21:56:50 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 28 Aug 2024 21:56:50 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v10]
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: <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>

> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
> 
> There are several issues with this:
> 
> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
> 
> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
> 
> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Shorten the description of concatenation behavior per review comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/18385/files
  - new: https://git.openjdk.org/jdk/pull/18385/files/a69bf2a9..34f2a21c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18385&range=08-09

  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 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 bchristi at openjdk.org  Wed Aug 28 22:57:21 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 28 Aug 2024 22:57:21 GMT
Subject: Integrated: 8338716: Re-visit "interrupt handling" in
 jdk.internal.loader.Resource
In-Reply-To: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
References: <HUPU9ofFQxbaskZeRsvcsj7fjkfz5uX3561ok10Bd5s=.67ec4a11-8c35-4401-a532-14ab77a95582@github.com>
Message-ID: <p5gPUyKmVKmyQQrKURAHSKouA0zyektAiJHlr7n21Wk=.b44e936d-4d5f-49fe-9928-990fcd60b4cd@github.com>

On Tue, 27 Aug 2024 21:57:16 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> The InterruptibleIO feature (which was only on Solaris) was removed some time ago. See [JDK-4385444](https://bugs.openjdk.org/browse/JDK-4385444).
> 
> Vestiges of it remain in jdk.internal.loader.Resource.getBytes(), and should be removed.

This pull request has now been integrated.

Changeset: 26e3d535
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26e3d535ad4d6e5d78ca50941cfa39dd337892a9
Stats:     34 lines in 1 file changed: 1 ins; 31 del; 2 mod

8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20736

From swen at openjdk.org  Wed Aug 28 23:37:27 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 23:37:27 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator$Frame
Message-ID: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>

A small optimization to reduce the code size of StackMapGenerator.Frame's pushStack and setLocalsFromArg methods

Below is the compiler log of C2


# baseline
jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (27 bytes)   failed to inline: callee uses too much stack
jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (46 bytes)   failed to inline: callee is too large
jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (183 bytes)   failed to inline: callee is too large
jdk.internal.classfile.impl.StackMapGenerator$Frame::setLocalsFromArg (367 bytes)   failed to inline: callee is too large

# current
jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (26 bytes)   inline
jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (37 bytes)   failed to inline: callee is too large
jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (82 bytes)
jdk.internal.classfile.impl.StackMapGenerator$Frame::setLocalsFromArg (255 bytes)   failed to inline: callee is too large

-------------

Commit messages:
 - from @liach 's suggestion
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
 - optimize frame#setLocalsFromArg
 - optimize frame#pushStack

Changes: https://git.openjdk.org/jdk/pull/20756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339205
  Stats: 41 lines in 1 file changed: 10 ins; 9 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/20756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20756/head:pull/20756

PR: https://git.openjdk.org/jdk/pull/20756

From liach at openjdk.org  Wed Aug 28 23:37:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Aug 2024 23:37:28 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator$Frame
In-Reply-To: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
Message-ID: <ht1pwsXI3anE9jw6-rirJW4ZwFTcn-KXceRqgr0jtwQ=.82008446-92cb-42f9-97bb-2a778ef936c3@github.com>

On Wed, 28 Aug 2024 22:20:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to reduce the code size of StackMapGenerator.Frame's pushStack and setLocalsFromArg methods
> 
> Below is the compiler log of C2
> 
> 
> # baseline
> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (27 bytes)   failed to inline: callee uses too much stack
> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (46 bytes)   failed to inline: callee is too large
> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (183 bytes)   failed to inline: callee is too large
> jdk.internal.classfile.impl.StackMapGenerator$Frame::setLocalsFromArg (367 bytes)   failed to inline: callee is too large
> 
> # current
> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (26 bytes)   inline
> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (37 bytes)   failed to inline: callee is too large
> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (82 bytes)
> jdk.internal.classfile.impl.StackMapGenerator$Frame::setLocalsFromArg (255 bytes)   failed to inline: callee is too large

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 959:

> 957:                  : pushStack(
> 958:                          desc == CD_float ? Type.FLOAT_TYPE :
> 959:                          desc instanceof PrimitiveClassDescImpl ? Type.INTEGER_TYPE : Type.referenceType(desc));

I think you can first use a `desc.isPrimitive()` and then go through all primitive type checks; handling references first should be faster in general.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1058:

> 1056:             for (int i = 0; i < methodDesc.parameterCount(); i++) {
> 1057:                 var desc = methodDesc.parameterType(i);
> 1058:                 if (desc == CD_void) throw new AssertionError("Should not reach here");

You can use
Suggestion:

                assert desc != CD_void;

So this fails in unit tests. But this takes code size.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1060:

> 1058:                 if (desc == CD_void) throw new AssertionError("Should not reach here");
> 1059:                 Type type;
> 1060:                 if (desc instanceof PrimitiveClassDescImpl) {

Can we use `desc.isPrimitive()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1735361672
PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1735362742
PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1735362061

From swen at openjdk.org  Wed Aug 28 23:37:29 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 23:37:29 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator$Frame
In-Reply-To: <ht1pwsXI3anE9jw6-rirJW4ZwFTcn-KXceRqgr0jtwQ=.82008446-92cb-42f9-97bb-2a778ef936c3@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
 <ht1pwsXI3anE9jw6-rirJW4ZwFTcn-KXceRqgr0jtwQ=.82008446-92cb-42f9-97bb-2a778ef936c3@github.com>
Message-ID: <VYqivY_6zWhrLIlxinHBW3-KvQhsL0VqMm_j5-gFV1U=.1f658d39-9f14-4cfd-a0ae-6e78483be93d@github.com>

On Wed, 28 Aug 2024 22:38:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A small optimization to reduce the code size of StackMapGenerator.Frame's pushStack and setLocalsFromArg methods
>> 
>> Below is the compiler log of C2
>> 
>> 
>> # baseline
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (27 bytes)   failed to inline: callee uses too much stack
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (46 bytes)   failed to inline: callee is too large
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (183 bytes)   failed to inline: callee is too large
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::setLocalsFromArg (367 bytes)   failed to inline: callee is too large
>> 
>> # current
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (26 bytes)   inline
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (37 bytes)   failed to inline: callee is too large
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::pushStack (82 bytes)
>> jdk.internal.classfile.impl.StackMapGenerator$Frame::setLocalsFromArg (255 bytes)   failed to inline: callee is too large
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1060:
> 
>> 1058:                 if (desc == CD_void) throw new AssertionError("Should not reach here");
>> 1059:                 Type type;
>> 1060:                 if (desc instanceof PrimitiveClassDescImpl) {
> 
> Can we use `desc.isPrimitive()`?

I have tried isPrimitive(). The codeSize of the virtual function call isPrimitive() is 2 bytes larger than instanceof. The performance of instanceof should be better. But isPrimitive() is a public API and easier to understand. If you think isPrimitive is better, I think it's OK too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1735374088

From swen at openjdk.org  Wed Aug 28 23:37:29 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 Aug 2024 23:37:29 GMT
Subject: RFR: 8339205: Optimize StackMapGenerator$Frame
In-Reply-To: <VYqivY_6zWhrLIlxinHBW3-KvQhsL0VqMm_j5-gFV1U=.1f658d39-9f14-4cfd-a0ae-6e78483be93d@github.com>
References: <Jxvjk--23eNS4gI9bjSknitXZuUnhR-NjYQOlSu-FAU=.2369f4c4-e880-4297-a49a-48d6a3790ec9@github.com>
 <ht1pwsXI3anE9jw6-rirJW4ZwFTcn-KXceRqgr0jtwQ=.82008446-92cb-42f9-97bb-2a778ef936c3@github.com>
 <VYqivY_6zWhrLIlxinHBW3-KvQhsL0VqMm_j5-gFV1U=.1f658d39-9f14-4cfd-a0ae-6e78483be93d@github.com>
Message-ID: <HtmajXkSyeT1wZlIcufwsp9fpcrmMdSwqX73ttdKYTs=.1534a2cf-ae9a-4254-88d3-1fc25e0d3b46@github.com>

On Wed, 28 Aug 2024 22:59:20 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 1060:
>> 
>>> 1058:                 if (desc == CD_void) throw new AssertionError("Should not reach here");
>>> 1059:                 Type type;
>>> 1060:                 if (desc instanceof PrimitiveClassDescImpl) {
>> 
>> Can we use `desc.isPrimitive()`?
>
> I have tried isPrimitive(). The codeSize of the virtual function call isPrimitive() is 2 bytes larger than instanceof. The performance of instanceof should be better. But isPrimitive() is a public API and easier to understand. If you think isPrimitive is better, I think it's OK too.

ClassDesc {
    default boolean isPrimitive() {
        return descriptorString().length() == 1;
    }       
}


Using isPrimitive will result in three virtual function calls, isPrimitive/descriptorString/length. C2 can be optimized inline, but one more reference access to descriptorString is necessary. Considering the possible slowdown caused by cache miss, can we keep using instanceof?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20756#discussion_r1735388215

From iklam at openjdk.org  Thu Aug 29 04:24:02 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 29 Aug 2024 04:24:02 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v2]
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <EeFA_XcicxNG31_1NvccLJieHtjUQm2FPUnnWPCNkw4=.6b00686a-021f-4129-8809-fe4a0fabcc6a@github.com>

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Fixed copyright dates
 - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
 - Fixed whitespaces
 - 8338017: Add AOT command-line flag aliases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20516/files
  - new: https://git.openjdk.org/jdk/pull/20516/files/4f06fe70..1fd5b154

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=00-01

  Stats: 55003 lines in 1635 files changed: 31975 ins; 15386 del; 7642 mod
  Patch: https://git.openjdk.org/jdk/pull/20516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20516/head:pull/20516

PR: https://git.openjdk.org/jdk/pull/20516

From dholmes at openjdk.org  Thu Aug 29 05:09:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Aug 2024 05:09:21 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v2]
In-Reply-To: <EeFA_XcicxNG31_1NvccLJieHtjUQm2FPUnnWPCNkw4=.6b00686a-021f-4129-8809-fe4a0fabcc6a@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <EeFA_XcicxNG31_1NvccLJieHtjUQm2FPUnnWPCNkw4=.6b00686a-021f-4129-8809-fe4a0fabcc6a@github.com>
Message-ID: <oC2ZnKYlfMA194YjGSF56KfBfmP3nVD2qbYh3hEE8pk=.74999fc0-00fe-481b-89be-0fd6146a7649@github.com>

On Thu, 29 Aug 2024 04:24:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Fixed copyright dates
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
>  - Fixed whitespaces
>  - 8338017: Add AOT command-line flag aliases

Seems reasonable but one issue flagged below.

Thanks.

src/java.base/share/native/libjli/java.c line 1521:

> 1519:             dumpSharedSpaces = JNI_TRUE;
> 1520:         }
> 1521:         if (JLI_StrCmp(arg, "-XX:AOTMode=create") == 0) {

This is inappropriate - the launcher does not, and should not, process hotspot -XX options. Any aliasing should happen in the hotspot argument processing logic.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20516#pullrequestreview-2267689489
PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1735573603

From dholmes at openjdk.org  Thu Aug 29 05:13:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Aug 2024 05:13:21 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v2]
In-Reply-To: <oC2ZnKYlfMA194YjGSF56KfBfmP3nVD2qbYh3hEE8pk=.74999fc0-00fe-481b-89be-0fd6146a7649@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <EeFA_XcicxNG31_1NvccLJieHtjUQm2FPUnnWPCNkw4=.6b00686a-021f-4129-8809-fe4a0fabcc6a@github.com>
 <oC2ZnKYlfMA194YjGSF56KfBfmP3nVD2qbYh3hEE8pk=.74999fc0-00fe-481b-89be-0fd6146a7649@github.com>
Message-ID: <4oKtHm2hR1CyyDh9TImcbTcfe0FhrWNnZsY915494cE=.b8a662b6-b1f2-44a7-9bf1-5e3dfccc7547@github.com>

On Thu, 29 Aug 2024 05:05:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Fixed copyright dates
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jep-483-step-01-8338017-add-aot-command-line-aliases
>>  - Merge branch 'master' into jep-483-step-01-8338017-add-aot-command-line-aliases
>>  - Fixed whitespaces
>>  - 8338017: Add AOT command-line flag aliases
>
> src/java.base/share/native/libjli/java.c line 1521:
> 
>> 1519:             dumpSharedSpaces = JNI_TRUE;
>> 1520:         }
>> 1521:         if (JLI_StrCmp(arg, "-XX:AOTMode=create") == 0) {
> 
> This is inappropriate - the launcher does not, and should not, process hotspot -XX options. Any aliasing should happen in the hotspot argument processing logic.

I realize this poses a problem with communicating to the launcher that this is a "terminal" flag. Maybe AOT should have -X flags instead of -XX?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1735576562

From stuefe at openjdk.org  Thu Aug 29 05:28:21 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 29 Aug 2024 05:28:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
Message-ID: <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>

On Wed, 28 Aug 2024 15:42:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
>> 
>> Tested with tier1-8.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'anon' of github.com:coleenp/jdk into anon
>  - Fix copyright

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp line 79:

> 77: 
> 78: static bool can_compress_element(const Klass* klass) {
> 79:   return Metaspace::is_in_class_space(klass) &&

Suggestion:

  return (Metaspace::is_in_class_space(klass) || Metaspace::is_in_shared_metaspace(klass)) &&

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1735585478

From jbhateja at openjdk.org  Thu Aug 29 05:42:58 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 29 Aug 2024 05:42:58 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
Message-ID: <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>

> Hi All,
> 
> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
> 
> 
> Declaration:-
>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
> 
> 
> Semantics:-
>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
> 
> Summary of changes:
> -  Java side implementation of new selectFrom API.
> -  C2 compiler IR and inline expander changes.
> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
> -  Optimized x86 backend implementation for AVX512 and legacy target.
> -  Function tests covering new API.
> 
> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
> 
> 
>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
> SelectFromBenchmark.selectFromIntVector         2048  thrpt    2   5398.2...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Adding descriptive comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20508/files
  - new: https://git.openjdk.org/jdk/pull/20508/files/408a8694..8d71f175

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20508&range=05-06

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20508/head:pull/20508

PR: https://git.openjdk.org/jdk/pull/20508

From jbhateja at openjdk.org  Thu Aug 29 05:46:24 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 29 Aug 2024 05:46:24 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v6]
In-Reply-To: <xlVrS0Hg4mltPvLyPNXa1idkQqwmcmPo1KDmrdorOF4=.e5be0b95-9cac-4cb9-b3aa-b8a6f4c85249@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <SbWS4YOn-u1WfNT4AwWVAvEGa1z_YDsX2DnQ9M0wWDE=.39687e9e-d72c-4151-a835-7645b5670c83@github.com>
 <xlVrS0Hg4mltPvLyPNXa1idkQqwmcmPo1KDmrdorOF4=.e5be0b95-9cac-4cb9-b3aa-b8a6f4c85249@github.com>
Message-ID: <upSsrkToSl4LaV9gJtBUIUeJFMNqyNlOjOm--bTrN8o=.32091003-964f-44db-95e6-28690c71ff97@github.com>

On Tue, 27 Aug 2024 20:00:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> My comment was related to understanding what `SelectFromTwoVectorNode::Ideal` and `VectorRearrangeNode::Ideal` are doing - the former lowers, if needed, into the rearrange expression and the latter adjusts, if needed, the index vector (a comment describing this transformation would be useful, like you have in the former method).

Done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20508#issuecomment-2316759572

From swen at openjdk.org  Thu Aug 29 06:04:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 06:04:46 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant
Message-ID: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>

This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.

* current

CodeBuilder {
    default CodeBuilder loadConstant(ConstantDesc value) { ... }
}

java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

-------------

Commit messages:
 - since 24
 - optimize loadConstant

Changes: https://git.openjdk.org/jdk/pull/20761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339217
  Stats: 67 lines in 2 files changed: 36 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/20761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20761/head:pull/20761

PR: https://git.openjdk.org/jdk/pull/20761

From liach at openjdk.org  Thu Aug 29 06:04:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 06:04:46 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <zaJrWdwGMY9NggEJi3_9okj8N6KFNds4JwcOd6BcBZk=.91169623-f4dd-47d9-92a8-d6cbbc75038f@github.com>

On Thu, 29 Aug 2024 05:01:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

The primitive overloads of `loadConstant` avoid extraneous boxing. ?

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 646:

> 644:         if (value instanceof Float     ) return loadConstant((float)  value);
> 645:         if (value instanceof Double    ) return loadConstant((double) value);
> 646:         else                             return ldc(value);

I think we need to rearrange this to follow the code style, like:

if (value instanceof Number) {
    if (value instanceof Integer i)
        return loadConstant(i);
    if (value instanceof Long l)
        return loadConstant(l);
    if (value instanceof Float f)
        return loadConstant(f);
    if (value instanceof Double d)
        return loadConstant(d);
}
if (value == null || value == ConstantDescs.NULL)
    return aconst_null();
return ldc(value);

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 653:

> 651:      * @param value the constant value
> 652:      * @return this builder
> 653:      * @since 23

These are technically since 24.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20761#pullrequestreview-2267692194
PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1735577199
PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1735575357

From swen at openjdk.org  Thu Aug 29 06:04:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 06:04:46 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant
In-Reply-To: <zaJrWdwGMY9NggEJi3_9okj8N6KFNds4JwcOd6BcBZk=.91169623-f4dd-47d9-92a8-d6cbbc75038f@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <zaJrWdwGMY9NggEJi3_9okj8N6KFNds4JwcOd6BcBZk=.91169623-f4dd-47d9-92a8-d6cbbc75038f@github.com>
Message-ID: <lZFXWsc_SvO1ijvr6G-4qJjATlKLcFlSao00w8M1de4=.ad03cc55-1ac3-4a2f-8be5-120f4e7b9dd3@github.com>

On Thu, 29 Aug 2024 05:11:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 646:
> 
>> 644:         if (value instanceof Float     ) return loadConstant((float)  value);
>> 645:         if (value instanceof Double    ) return loadConstant((double) value);
>> 646:         else                             return ldc(value);
> 
> I think we need to rearrange this to follow the code style, like:
> 
> if (value instanceof Number) {
>     if (value instanceof Integer i)
>         return loadConstant(i);
>     if (value instanceof Long l)
>         return loadConstant(l);
>     if (value instanceof Float f)
>         return loadConstant(f);
>     if (value instanceof Double d)
>         return loadConstant(d);
> }
> if (value == null || value == ConstantDescs.NULL)
>     return aconst_null();
> return ldc(value);

Many parts of the existing JDK code are written in this style, which looks clean and easy to read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1735605374

From asotona at openjdk.org  Thu Aug 29 07:10:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 Aug 2024 07:10:20 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v3]
In-Reply-To: <Fr2Q9FINC96w4JPjxPw_pN1XDjJQ5_ABP_DdqpkF6W8=.4dd875d1-4aa1-490a-a598-b9debe76045a@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
 <Fr2Q9FINC96w4JPjxPw_pN1XDjJQ5_ABP_DdqpkF6W8=.4dd875d1-4aa1-490a-a598-b9debe76045a@github.com>
Message-ID: <UjMju_mp8JAMfDRjU4vBRdKlgr_RTcaNXD1eB_C8-5w=.3f56c1ae-ea1b-43ea-8b37-3f642cbeb831@github.com>

On Wed, 28 Aug 2024 21:24:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
>> 
>> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
>> 
>> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
>> 
>> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 564:

> 562:                 case INT -> {
> 563:                     switch (computationalFrom) {
> 564:                         case FLOAT -> f2i();

Actual implementation shows complete conversion table as nested switches.
What is the advantage of the proposed change?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20737#discussion_r1735680790

From asotona at openjdk.org  Thu Aug 29 07:30:21 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 Aug 2024 07:30:21 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects [v3]
In-Reply-To: <MI1RpfmLOIWHXp9DzkFbwnWnUwS68bP7akDFqc1yHC4=.f4ecaa47-dcf2-43a6-bf77-b29f9cc04d69@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
 <MI1RpfmLOIWHXp9DzkFbwnWnUwS68bP7akDFqc1yHC4=.f4ecaa47-dcf2-43a6-bf77-b29f9cc04d69@github.com>
Message-ID: <6EBxkLeICCPnii9fFkmJtGHgwM9r2vSEzBmwFLEOZ9I=.e7b4ddaf-cb41-4324-94b6-30dd505bf205@github.com>

On Wed, 28 Aug 2024 21:14:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.
>
> 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:
> 
>  - Remove redundant qualification, avoid boxing in b/sipush validation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cob-direct-methods
>  - Use uppercase L for long literals
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Moar fixes
>  - More direct code builder

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20738#pullrequestreview-2267897550

From ihse at openjdk.org  Thu Aug 29 07:32:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 07:32:21 GMT
Subject: Integrated: 8339120: Use more fine-granular gcc unused warnings
In-Reply-To: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
References: <bPTIWLOcLLjCudpGXY4aYnJPmwcEl_0AbY1ovtu03nQ=.5c15e5eb-cb09-403e-ae48-9183883ab0cb@github.com>
Message-ID: <Qm02HXx8S59SmKB7eiZfw3CPSU-emBr3GMjaXS3DSfI=.c704e468-dc4d-4d65-ab56-74cd42b9b57c@github.com>

On Tue, 27 Aug 2024 20:04:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in gcc, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

This pull request has now been integrated.

Changeset: 362f9ce0
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/362f9ce077baa900ed81a0473ec0187efde132ef
Stats:     61 lines in 17 files changed: 39 ins; 0 del; 22 mod

8339120: Use more fine-granular gcc unused warnings

Reviewed-by: jwaters, kbarrett, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/20733

From alanb at openjdk.org  Thu Aug 29 08:20:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Aug 2024 08:20:21 GMT
Subject: RFR: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix [v2]
In-Reply-To: <QPZ6oo0iv1tozJ9fOfyGsq4yvdALnpZkwvcp0Hq7kso=.a31128c2-437d-4c31-8d89-bc8650ee1bcd@github.com>
References: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
 <QPZ6oo0iv1tozJ9fOfyGsq4yvdALnpZkwvcp0Hq7kso=.a31128c2-437d-4c31-8d89-bc8650ee1bcd@github.com>
Message-ID: <GR-nO0KTvw0Qkq9FLpVGbSwI3yOCLtJ3-J327p2DaDQ=.505c9533-be35-4c73-9386-2bbf4f0bbc03@github.com>

On Fri, 2 Aug 2024 16:26:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add some verbiage indicating that an `IOException` will be thrown if a file with a name generated from the supplied prefix and suffix according to the described algorithm cannot be generated by the underlying system, whether that be due to the presence of one of more characters not supported by the underlying system or for some other reason.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6426678: having the generated name -> with the generated name

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20435#pullrequestreview-2268014306

From ihse at openjdk.org  Thu Aug 29 08:29:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 08:29:20 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <rTdJslX26f6JU-5aDKAg7RE2eASsK8rZ5lFQnRnHfSM=.6a7ff6b7-eb57-4593-a710-16517805b34b@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

Okay. Unless I misunderstand something, there were no additional authors to be credited for these two commits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317008624

From redestad at openjdk.org  Thu Aug 29 11:28:22 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 29 Aug 2024 11:28:22 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <_Sx5LfivNb9FSJt-2nwE7WmAoqsaNwmjCbHRmpOsjTQ=.b6e04e84-e340-430b-8985-8611e1ba6298@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

Needs to mask with `& 0xFF` in these places, otherwise you're changing semantics.

-------------

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20748#pullrequestreview-2268433476

From eirbjo at openjdk.org  Thu Aug 29 11:28:25 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 11:28:25 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v9]
In-Reply-To: <PxxFpha2Q6oIz6a1QRjyFNLgkv8zecZy-NTtUeDx0yM=.edf54b62-fef1-480b-b35e-c2ee69ff813b@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <uCe-ROsBsSqWzakkOT1bIP0RyKuPNDRzKg3mQsEWcUE=.ed7fdaed-8285-4062-ba97-495f0ccc9278@github.com>
 <qQ8-D2YKHinhumPCTNMmR9TdBt86tYtpp0_GvGWZqaA=.22ca2687-9814-4c24-bf3c-8d925f433b8d@github.com>
 <rai3hHx1M5D6S24ugOsgm_oCeRYaVuCOU01D8SpiMng=.257fa6c4-6ece-4e39-a492-46f16e5a8111@github.com>
 <PxxFpha2Q6oIz6a1QRjyFNLgkv8zecZy-NTtUeDx0yM=.edf54b62-fef1-480b-b35e-c2ee69ff813b@github.com>
Message-ID: <k5debH-Xd4WFqbi9sNgl-gf2pjcswg_If0b2gPJ7dzM=.ec70ec12-80d0-491e-8320-09944a16377a@github.com>

On Wed, 28 Aug 2024 19:56:04 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Sounds good. How would you like to do that?
>> 
>> E.g. we could just remove the words "In particular, some GZIP compression tools function by partitioning the input, compressing each partition separately, and then concatenating the resulting compressed data streams. To support this kind of input".  We could also remove "In the latter case, the number of additional bytes that were read is unspecified." Or something else (what would you suggest?)
>> 
>> Thanks.
>
>> Sounds good. How would you like to do that?
>> 
>> E.g. we could just remove the words "In particular, some GZIP compression tools function by partitioning the input, compressing each partition separately, and then concatenating the resulting compressed data streams. To support this kind of input". We could also remove "In the latter case, the number of additional bytes that were read is unspecified." Or something else (what would you suggest?)
>> 
>> Thanks.
> 
> Yes, no reason to talk about gzip tools.  The focus should be that this method can read concatenated gzip streams when there is a gzip header immediately after the gzip trailer, otherwise additional bytes are treated as End of stream

I'm reluctant to make this PR even longer lived. But perhaps this could be made even shorter by dropping the 'self-delimiting' term and its definition?

Could something like this work?

_In the GZIP file format, compressed data payloads are preceded by a header and followed by a trailer. If a new header immediately follows a trailer, this class continues to decode compressed data as a single, concatenated stream; otherwise, any additional bytes are ignored as if the end of stream is reached._

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736027146

From liach at openjdk.org  Thu Aug 29 11:34:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 11:34:20 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v3]
In-Reply-To: <UjMju_mp8JAMfDRjU4vBRdKlgr_RTcaNXD1eB_C8-5w=.3f56c1ae-ea1b-43ea-8b37-3f642cbeb831@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
 <Fr2Q9FINC96w4JPjxPw_pN1XDjJQ5_ABP_DdqpkF6W8=.4dd875d1-4aa1-490a-a598-b9debe76045a@github.com>
 <UjMju_mp8JAMfDRjU4vBRdKlgr_RTcaNXD1eB_C8-5w=.3f56c1ae-ea1b-43ea-8b37-3f642cbeb831@github.com>
Message-ID: <U_lwar_4_Rhu1zno1pBxdOzjB1LjSsLwb9Cg9ZityRU=.d71324e5-cab7-4af7-9713-ca2f133a6d38@github.com>

On Thu, 29 Aug 2024 07:07:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space
>
> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 564:
> 
>> 562:                 case INT -> {
>> 563:                     switch (computationalFrom) {
>> 564:                         case FLOAT -> f2i();
> 
> Actual implementation shows complete conversion table as nested switches.
> What is the advantage of the proposed change?

Smaller switches reduce code size. A single switch case in the range adds 4 bytes to the size. This may be further optimized later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20737#discussion_r1736034410

From coleenp at openjdk.org  Thu Aug 29 11:40:27 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Aug 2024 11:40:27 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
Message-ID: <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>

On Thu, 29 Aug 2024 05:24:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'anon' of github.com:coleenp/jdk into anon
>>  - Fix copyright
>
> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp line 79:
> 
>> 77: 
>> 78: static bool can_compress_element(const Klass* klass) {
>> 79:   return Metaspace::is_in_class_space(klass) &&
> 
> Suggestion:
> 
>   return (Metaspace::is_in_class_space(klass) || Metaspace::is_in_shared_metaspace(klass)) &&

Is this right?  If UseCompressedClassPointers is off, then the shared metaspace isn't in compressed space?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736041738

From duke at openjdk.org  Thu Aug 29 11:55:20 2024
From: duke at openjdk.org (duke)
Date: Thu, 29 Aug 2024 11:55:20 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <50ON6F3l-S5iZTRhb0guqPG0PJ31VwEa9aZwLAFUPYc=.c298e19c-9939-4a57-a56c-c1b493170fe8@github.com>

On Wed, 28 Aug 2024 13:12:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

@wenshao 
Your change (at version 3c58fab74c9f78b7f3008c4f6fa32a7aab79f053) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20747#issuecomment-2317429520

From swen at openjdk.org  Thu Aug 29 11:55:49 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 11:55:49 GMT
Subject: RFR: 8339241: Optimize LambdaForm#basicType(Class)
Message-ID: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>

A small optimization to simplify the implementation logic of LambdaForm$BasicType#basicType method can reduce the call stack and reduce the overall bytecode size.

Below is the compiler log

* baseline

 @ 1   java.lang.invoke.LambdaForm$BasicType::basicType (8 bytes)   inline
   @ 1   sun.invoke.util.Wrapper::basicTypeChar (18 bytes)   inline
     @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
     @ 11   sun.invoke.util.Wrapper::forPrimitiveType (122 bytes)   failed to inline: callee is too large
     @ 14   sun.invoke.util.Wrapper::basicTypeChar (5 bytes)   inline


* current

java.lang.invoke.LambdaForm$BasicType::basicType (59 bytes)   failed to inline: callee is too large

-------------

Commit messages:
 - from @liach's suggestion
 - optimize LambdaForm#basicType(Class)

Changes: https://git.openjdk.org/jdk/pull/20759/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20759&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339241
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20759/head:pull/20759

PR: https://git.openjdk.org/jdk/pull/20759

From liach at openjdk.org  Thu Aug 29 11:55:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 11:55:49 GMT
Subject: RFR: 8339241: Optimize LambdaForm#basicType(Class)
In-Reply-To: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
References: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
Message-ID: <Uo2wlBSKu8RXo2biCn1t6iGuW3U6ccag6WBEoFcU0MY=.f696e125-5671-4c97-a931-90c02dadadc1@github.com>

On Thu, 29 Aug 2024 01:30:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to simplify the implementation logic of LambdaForm$BasicType#basicType method can reduce the call stack and reduce the overall bytecode size.
> 
> Below is the compiler log
> 
> * baseline
> 
>  @ 1   java.lang.invoke.LambdaForm$BasicType::basicType (8 bytes)   inline
>    @ 1   sun.invoke.util.Wrapper::basicTypeChar (18 bytes)   inline
>      @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>      @ 11   sun.invoke.util.Wrapper::forPrimitiveType (122 bytes)   failed to inline: callee is too large
>      @ 14   sun.invoke.util.Wrapper::basicTypeChar (5 bytes)   inline
> 
> 
> * current
> 
> java.lang.invoke.LambdaForm$BasicType::basicType (59 bytes)   failed to inline: callee is too large

What about this:

if (!type.isPrimitive()) return L_TYPE;
if (type == long.class) return J_TYPE;
if (type == float.class) return F_TYPE;
if (type == double.class) return D_TYPE;
if (type == void.class) return V_TYPE;
return I_TYPE; // int, short, byte, char, boolean

Is this even smaller?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20759#issuecomment-2316646898

From coleenp at openjdk.org  Thu Aug 29 12:08:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Aug 2024 12:08:37 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v5]
In-Reply-To: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
Message-ID: <0VQJugX9IulwqoN4WWxCixyhPRhfGs-48Vm5DB0s-VU=.334232df-93b0-453a-aba7-0cf26cecf8d1@github.com>

> This change stores InstanceKlass for interface and abstract classes in the non-class metaspace, since class metaspace will have limits on number of classes that can be represented when Lilliput changes go in.  Classes that have no instances created for them don't require compressed class pointers.  The generated LambdaForm classes are also AllStatic, and changing them to abstract moves them to non-class metaspace too.  It's not technically great to make them abstract and not final but you can't have both.  Java classfile access flags have no way of specifying something like AllStatic.
> 
> Tested with tier1-8.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add function in Metaspace to tell you if Klass pointer is in compressible space.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19157/files
  - new: https://git.openjdk.org/jdk/pull/19157/files/1382ced0..ce96165e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19157&range=03-04

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19157/head:pull/19157

PR: https://git.openjdk.org/jdk/pull/19157

From swen at openjdk.org  Thu Aug 29 12:23:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 12:23:22 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <rM-j2Er1CK_cpCN7knnbiFGz2MCSt5BMDZ9rLqP3wlo=.a5593820-1097-48a1-904a-bde9ad928044@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

The general way of writing should be like this:

elems[offset++] = (byte) (intValue >>> 8 * (intSize - i - 1));
``` 


* now

(byte) ((x >> 8) & 0xFF)


Is the & 0xFF here redundant? I am confused

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20748#issuecomment-2317491283

From liach at openjdk.org  Thu Aug 29 12:23:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 12:23:23 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <5TThg73qqoMijDN7l-fIQX6Wvon3jo_cl5mXsHx-Wu0=.d5d0c3f9-3fcf-4aba-a13f-a30a7db6b1c5@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
 <5TThg73qqoMijDN7l-fIQX6Wvon3jo_cl5mXsHx-Wu0=.d5d0c3f9-3fcf-4aba-a13f-a30a7db6b1c5@github.com>
Message-ID: <WiHbTzwg7ynFbrbyfdq-zS7Rzb7IsL91ZkRGh_ACMTA=.2d0e2738-7778-48c1-bc38-9c98516c4e2d@github.com>

On Wed, 28 Aug 2024 18:38:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.
>
> I made an off-list suggestion along this line some time before integration. IIRC it was a decent win back then, and with the merge store optimizations in place it might be even more impactful now.

@cl4es this is already downcasted to a byte, which is done via truncation like `& 0xFF` so I think the original `& 0xFF` is redundant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20748#issuecomment-2317496731

From liach at openjdk.org  Thu Aug 29 12:26:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 12:26:21 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <sHKha15jQ4aEnKK5FUYnO2C2a-GAo0-grYErFZ-n5UY=.c736be91-55d8-46f9-9fe2-73e0913ccd55@github.com>

On Thu, 29 Aug 2024 05:01:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 651:

> 649:     /**
> 650:      * Generate an instruction pushing a constant onto the operand stack
> 651:      * @param value the constant value

Can you change the wording to "pushing an int onto"... "the int value" etc, for all int/long/float/double versions of `loadConstant`?

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 653:

> 651:      * @param value the constant value
> 652:      * @return this builder
> 653:      * @since 24

Actually we can probably omit the `@since` tags since we will finalize, and `CodeBuilder` itself will be `@since 24`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1736101900
PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1736102662

From eirbjo at openjdk.org  Thu Aug 29 12:31:25 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 12:31:25 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v10]
In-Reply-To: <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
Message-ID: <84DXi_Gi0jxfc2gEQtGVBMxzW7vLf8K8NLtM8RXZLg0=.9de96ea8-4782-412d-9205-a9ce8abac6a7@github.com>

On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten the description of concatenation behavior per review comments.

src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 37:

> 35: 
> 36: /**
> 37:  * This class implements a stream filter for reading compressed data in the GZIP file format.

I think you could keep this leading paragraph unchanged, including the line break. Similarly, it would be nice to keep the introduced text within 80 character lines as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736110591

From redestad at openjdk.org  Thu Aug 29 12:44:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 29 Aug 2024 12:44:19 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <mDeV3NoRCriyCejepj37UYcdO9a6D-W1oZGQh2u-fcE=.00900130-d325-4a41-86f7-8c85f3dd8579@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

Ok, I did some adhoc testing to convince me that these are equivalent for these cases. Masking in line with intended semantics doesn't add any real runtime cost, though, it's mainly a declaration of intent, but if you prefer it like this then go ahead.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20748#pullrequestreview-2268614060

From stuefe at openjdk.org  Thu Aug 29 13:20:25 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 29 Aug 2024 13:20:25 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
Message-ID: <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>

On Thu, 29 Aug 2024 11:37:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdKlassQueue.cpp line 79:
>> 
>>> 77: 
>>> 78: static bool can_compress_element(const Klass* klass) {
>>> 79:   return Metaspace::is_in_class_space(klass) &&
>> 
>> Suggestion:
>> 
>>   return (Metaspace::is_in_class_space(klass) || Metaspace::is_in_shared_metaspace(klass)) &&
>
> Is this right?  If UseCompressedClassPointers is off, then the shared metaspace isn't in compressed space?

If UseCompressedClassPointers is off, we don't have a compressed class space. If its on, Klass from CDS and from class space are compressable. With your patch, interfaces will live in normal metaspace, not int class space, so those are excluded now.

TBH, I am not really sure what this code here does, but I assume it tries to reduce the size of a JFR recording by using a compressed identifier for X if X can be expressed by such. Maybe a JFR person should look at this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736193248

From redestad at openjdk.org  Thu Aug 29 13:28:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 29 Aug 2024 13:28:20 GMT
Subject: RFR: 8339241: Optimize LambdaForm#basicType(Class)
In-Reply-To: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
References: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
Message-ID: <9Hpyyo1SFyTbxYeqak1pWsHnFpBxTrTbfZfz6cDJ3UI=.325c1cd1-d991-44a5-b5b5-0a83165c348c@github.com>

On Thu, 29 Aug 2024 01:30:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to simplify the implementation logic of LambdaForm$BasicType#basicType method can reduce the call stack and reduce the overall bytecode size.
> 
> Below is the compiler log
> 
> * baseline
> 
>  @ 1   java.lang.invoke.LambdaForm$BasicType::basicType (8 bytes)   inline
>    @ 1   sun.invoke.util.Wrapper::basicTypeChar (18 bytes)   inline
>      @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>      @ 11   sun.invoke.util.Wrapper::forPrimitiveType (122 bytes)   failed to inline: callee is too large
>      @ 14   sun.invoke.util.Wrapper::basicTypeChar (5 bytes)   inline
> 
> 
> * current
> 
> java.lang.invoke.LambdaForm$BasicType::basicType (59 bytes)   failed to inline: callee is too large

If this is a startup play can you provide numbers and analysis on some relevant startup benchmark? C2 inlining behavior might be a poor guide to optimizing libraries which are mostly bootstrap sensitive.

`Class::isPrimitive` is a native method, which IIRC can be relatively slow in the interpreter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20759#issuecomment-2317655533

From asotona at openjdk.org  Thu Aug 29 13:44:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 Aug 2024 13:44:19 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v3]
In-Reply-To: <Fr2Q9FINC96w4JPjxPw_pN1XDjJQ5_ABP_DdqpkF6W8=.4dd875d1-4aa1-490a-a598-b9debe76045a@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
 <Fr2Q9FINC96w4JPjxPw_pN1XDjJQ5_ABP_DdqpkF6W8=.4dd875d1-4aa1-490a-a598-b9debe76045a@github.com>
Message-ID: <BcFhaNvNeYvWRr5ZYu44XAd8vHfg9mjoBUl3qVR5-5Q=.efc01f39-400b-4443-a23c-0cd1efbaf81b@github.com>

On Wed, 28 Aug 2024 21:24:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
>> 
>> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
>> 
>> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
>> 
>> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20737#pullrequestreview-2268803998

From eirbjo at openjdk.org  Thu Aug 29 13:58:24 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 13:58:24 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v10]
In-Reply-To: <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
Message-ID: <uQrOhEKYFJlD4tmWk2Me3UFE0OL_oBUkqF2DMBAP1RA=.d37efc2c-c6d7-4a19-9de5-e710cd06c931@github.com>

On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten the description of concatenation behavior per review comments.

I think the `testScenario` method would be easier to read if we dropped the assigments to the `input` and `output` variables, and if the `testDecomp` method was split into separate methods for expecting a successful vs. failing deompression. See comments for details.

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 48:

> 46:         // Test concat vs. non-concat, garbage vs. no-garbage, and various buffer sizes on random data
> 47:         Random random = new Random();
> 48:         final ArrayList<List<Object>> scenarios = new ArrayList<>();

Suggestion:

        List<List<Object>> scenarios = new ArrayList<>();

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 49:

> 47:         Random random = new Random();
> 48:         final ArrayList<List<Object>> scenarios = new ArrayList<>();
> 49:         for (int size = 1; size < 1024; size += random.nextInt(32) + 1) {

It's not obviously clear that `size` is the buffer size passed to GZIPInputStream here and not related to the size of the uncompressed input data.

Perhaps rename this to `bufferSize` and/or document the parameters via a comment?

`// Parameters: byte[] data, int bufferSize`

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 69:

> 67:         // Decompress a single stream with no extra garbage - should always work
> 68:         byte[] input = compressed;
> 69:         byte[] output = uncompressed;

The assignment of `input` and `output` variables in this method add a lot of noise. Could this be simplified to something like this?


        // Compress the test data
        byte[] compressed = deflate(uncompressed);

        // Decompress a single stream with no extra garbage - should always work
        testDecomp(compressed, uncompressed);

        // Decompress a truncated GZIP header
        testDecompFail(oneByteShort(gzipHeader()), EOFException.class);

        // Decompress a single stream that is one byte short - should always fail
        testDecompFail(oneByteShort(compressed), EOFException.class);

        // Decompress a single stream with one byte of extra garbage (trying all 256 possible values)
        for (int extra = 0; extra < 0x100; extra++) {
            testDecomp(oneByteLong(compressed, extra), uncompressed);
        }

        // Decompress a single stream followed by a truncated GZIP header
        testDecomp(concat(compressed, oneByteShort(gzipHeader())), uncompressed);

        // Decompress a single stream followed by another stream that is one byte short
        testDecompFail(concat(compressed, oneByteShort(compressed)), IOException.class);

        // Decompress two streams concatenated
        testDecomp(concat(compressed, compressed), concat(uncompressed, uncompressed));

        // Decompress three streams concatenated
        testDecomp(concat(compressed, compressed, compressed),
                concat(uncompressed, uncompressed, uncompressed));

        // Decompress three streams concatenated followed by a truncated GZIP header
        testDecomp(concat(compressed, compressed, compressed, oneByteShort(gzipHeader())),
                concat(uncompressed, uncompressed, uncompressed));

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 142:

> 140:         System.arraycopy(array, 0, array2, 0, array.length);
> 141:         array2[array.length] = (byte)value;
> 142:         return array2;

Would it make sense to do the following here?

Suggestion:

        return concat(array, new byte[] {(byte) value});

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 167:

> 165: 
> 166:     // GZIP compress data
> 167:     public static byte[] deflate(byte[] data) throws IOException {

The returned data is in the GZIP format, not the DEFLATE format. So could be `gzip` rather than `deflate`.

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 176:

> 174: 
> 175:     // GZIP decompress data
> 176:     public byte[] inflate(InputStream in) throws IOException {

The stream here is in the GZIP format, not the DEFLATE format. So could be `gunzip` rather than `inflate`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18385#pullrequestreview-2268596523
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736128032
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736160530
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736229023
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736125278
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736119267
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736120221

From mbaesken at openjdk.org  Thu Aug 29 14:01:27 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 29 Aug 2024 14:01:27 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java fails
 on AIX and Linux ppc64le after JDK-8336856
Message-ID: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>

We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
Failure output :
java.lang.RuntimeException: unloadedClassCount is zero
at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:573)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1575)

Ergonomics sets on these platforms the heap to 32M 

[0.045s][info ][gc,init ] Heap Min Capacity: 32M
[0.045s][info ][gc,init ] Heap Initial Capacity: 32M
[0.045s][info ][gc,init ] Heap Max Capacity: 32M

So we need more iterations in the test to trigger the class unloading.

-------------

Commit messages:
 - JDK-8339166

Changes: https://git.openjdk.org/jdk/pull/20771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339166
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20771/head:pull/20771

PR: https://git.openjdk.org/jdk/pull/20771

From ihse at openjdk.org  Thu Aug 29 14:21:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 14:21:54 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
Message-ID: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>

Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.

We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.

This is similar to what has been done for gcc in JDK-8339120.

-------------

Commit messages:
 - 8339156: Use more fine-granular clang unused warnings

Changes: https://git.openjdk.org/jdk/pull/20770/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20770&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339156
  Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20770/head:pull/20770

PR: https://git.openjdk.org/jdk/pull/20770

From duke at openjdk.org  Thu Aug 29 14:33:08 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 29 Aug 2024 14:33:08 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v3]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <KO3_0ziw1FT2vVj8QFVspqhERNcaLaDNSQeK6CsnKRs=.5a10b6b8-1205-4737-bfcf-f49375b6c581@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19702/files
  - new: https://git.openjdk.org/jdk/pull/19702/files/1d8f1b22..2a734c5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From duke at openjdk.org  Thu Aug 29 14:40:24 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 29 Aug 2024 14:40:24 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory
In-Reply-To: <-hWR8SELSSfdXbSKq5oeo7dN-w1Hi8ClUbteaSuttUg=.6bfb1f64-116d-4b0d-94e7-9657b40c2767@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <-hWR8SELSSfdXbSKq5oeo7dN-w1Hi8ClUbteaSuttUg=.6bfb1f64-116d-4b0d-94e7-9657b40c2767@github.com>
Message-ID: <MtDufL5f8I8CcxNM1NdwZfY6iR4YuOQVaJvDmdk5We0=.386cb08f-2cfb-4607-a151-07c6f2a364a3@github.com>

On Mon, 12 Aug 2024 18:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The tests should include serializing some sample JDK classes that include a hierarchy of 2-4 levels. It would help fles any interactions in the sequencing of calling the default serialization for each of a concrete class's supertypes.

I'm having some difficulty with this, first of all finding a good candidate JDK class which would be accessible from the test which has multiple levels of serializable hierarchy. Secondly AFAICT this change doesn't relate in any way to sub/superclass calling sequencing (that would be the caller's responsibility). The API deals strictly with a single level of a class hierarchy at a time. So, I'm not quite clear on what else to check; the tests I have presently will verify that the method meets its contract, but if there's some subtlety I missed (very possible) then I'd like to add tests for those case(s).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2317905907

From jiangli at openjdk.org  Thu Aug 29 15:00:21 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 29 Aug 2024 15:00:21 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <rTdJslX26f6JU-5aDKAg7RE2eASsK8rZ5lFQnRnHfSM=.6a7ff6b7-eb57-4593-a710-16517805b34b@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <rTdJslX26f6JU-5aDKAg7RE2eASsK8rZ5lFQnRnHfSM=.6a7ff6b7-eb57-4593-a710-16517805b34b@github.com>
Message-ID: <WDs803DQdxoaBmK4lKspnKzkgy3YAKzHU5VnXUU0U6Y=.d345bccd-03ee-43fe-9333-1ee967fd509a@github.com>

On Thu, 29 Aug 2024 08:26:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Okay. Unless I misunderstand something, there were no additional authors to be credited for these two commits.

That's correct for these.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2317982354

From eirbjo at openjdk.org  Thu Aug 29 15:09:24 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 15:09:24 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v10]
In-Reply-To: <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
Message-ID: <WEABkmuTvcrK0H4DZaOXJ6yQZlsyGTYszWjLf-vtWUE=.195cc60f-562a-4506-9880-640edda7f82b@github.com>

On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten the description of concatenation behavior per review comments.

The parameter source methods in both tests could benefit from using the `Arguments` class in JUnit, see comments for details.

test/jdk/java/util/zip/GZIP/GZIPInputStreamConcat.java line 44:

> 42:     private int bufsize;
> 43: 
> 44:     public static Stream<Object[]> testScenarios() throws IOException {

I think the best practice for JUnit 5 when providing more than one argument is to return a `Stream<Arguments>`. (IntelliJ IDEA also suggests this in a code inspection)

So, something like:


    public static Stream<Arguments> testScenarios() throws IOException {
        // Test concat vs. non-concat, garbage vs. no-garbage, and various buffer sizes on random data
        Random random = new Random();
        List<Arguments> scenarios = new ArrayList<>();
        for (int bufsize = 1; bufsize < 1024; bufsize += random.nextInt(32) + 1) {
            scenarios.add(Arguments.of(randomData(0, 100), bufsize));
        }
        return scenarios.stream();
    }

test/jdk/java/util/zip/GZIP/GZIPInputStreamGzipCommand.java line 44:

> 42: 
> 43:     public static Stream<String[]> gzipScenarios() throws IOException {
> 44:         final ArrayList<String[]> scenarios = new ArrayList();

Similar to the comment for the other test, this could be:


return Stream.of(Arguments.of(expected, hex),  Arguments.of(expected, hex), ...);

test/jdk/java/util/zip/GZIP/GZIPInputStreamGzipCommand.java line 122:

> 120: 
> 121:         // Get expected result
> 122:         final byte[] expected = input.getBytes(StandardCharsets.UTF_8);

IMHO the use of `final` for local variables in this method adds visual clutter without providing much value.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18385#pullrequestreview-2269041615
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736385638
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736394966
PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1736428169

From mbaesken at openjdk.org  Thu Aug 29 15:24:30 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 29 Aug 2024 15:24:30 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
Message-ID: <s_VEg2QDRw1iCAFaRqaYe0NBIviTnKnnwVBfjfaBTgw=.2ff29af7-a5c5-4d49-a0db-3a0fb2f59463@github.com>

On Wed, 28 Aug 2024 16:13:07 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 10 additional commits since the last revision:
> 
>  - Add root check for SystemdMemoryAwarenessTest.java
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

test/hotspot/jtreg/containers/systemd/SystemdMemoryAwarenessTest.java line 58:

> 56:         SystemdRunOptions opts = SystemdTestUtils.newOpts("HelloSystemd");
> 57:         // 1 GB memory
> 58:         opts.memoryLimit("1000M");

Just wondering - is 1G here possible (the comment states 1 GB / 1024M) ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1736474134

From acobbs at openjdk.org  Thu Aug 29 15:33:29 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 29 Aug 2024 15:33:29 GMT
Subject: Withdrawn: 8322256: Define and document GZIPInputStream concatenated
 stream semantics
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: <_QRPv7rel-h8_G0pwaqJV8JIcugdn555mHcxkBOG27w=.daaed6b7-c34b-439a-a28d-93cfe7d96e5c@github.com>

On Tue, 19 Mar 2024 21:48:14 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> `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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/18385

From acobbs at openjdk.org  Thu Aug 29 15:33:29 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 29 Aug 2024 15:33:29 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v10]
In-Reply-To: <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
References: <gY-AA8TllF5gxe8rGL0ZQCCUWrnvN7xkTTdkmRVSS_A=.f05b9bf9-6049-4261-84cd-939e02c05d60@github.com>
 <8qf_WMSNThxzb6qn9CLonz1SDHCTqGMbEIbFNbuKI1o=.ef3bbf3e-6f4a-4431-9c57-0d257b8fd7a4@github.com>
Message-ID: <Obog1O10WdydMmCL9rsZYpu1ghAs3KtdlA2T-HaqJXs=.0f3e17fb-775c-4494-9722-12a1423ef31c@github.com>

On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In order to do this, after a GZIP trailer frame is read, it attempts to read a GZIP header frame and, if successful, proceeds onward to decompress the new stream. If the attempt to decode a GZIP header frame fails, or happens to trigger an `IOException`, it just ignores the trailing garbage and/or the `IOException` and returns EOF.
>> 
>> There are several issues with this:
>> 
>> 1. The behaviors of (a) supporting concatenated streams and (b) ignoring trailing garbage are not documented, much less precisely specified.
>> 2. Ignoring trailing garbage is dubious because it could easily hide errors or other data corruption that an application would rather be notified about. Moreover, the API claims that a `ZipException` will be thrown when corrupt data is read, but obviously that doesn't happen in the trailing garbage scenario (so N concatenated streams where the last one has a corrupted header frame is indistinguishable from N-1 valid streams).
>> 3. There's no way to create a `GZIPInputStream` that does _not_ support stream concatenation.
>> 
>> On the other hand, `GZIPInputStream` is an old class with lots of existing usage, so it's important to preserve the existing behavior, warts and all (note: my the definition of "existing behavior" here includes the bug fix in [JDK-7036144](https://bugs.openjdk.org/browse/JDK-7036144)).
>> 
>> So this patch adds a new constructor that takes two new parameters `allowConcatenation` and `allowTrailingGarbage`. The legacy behavior is enabled by setting both to true; otherwise, they do what they sound like. In particular, when `allowTrailingGarbage` is false, then the underlying input must contain exactly one (if `allowConcatenation` is false) or exactly N (if `allowConcatenation` is true) concatenated GZIP data streams, otherwise an exception is guaranteed.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten the description of concatenation behavior per review comments.

Thanks for all the helpful comments. Unfortunately due to unrelated/personal reasons I need to pause working on this issue.

Closing this PR for now but will plan to possibly reopen sometime in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18385#issuecomment-2318155817

From swen at openjdk.org  Thu Aug 29 15:35:32 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 15:35:32 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v2]
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <MYgqso2eOzA5zBr4dHIQsNDtNVRtshZLrvoShVW5jQ8=.33e422e9-8774-4733-a86e-a8da8361523c@github.com>

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

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/20761/files
  - new: https://git.openjdk.org/jdk/pull/20761/files/e24ae903..46f10606

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20761/head:pull/20761

PR: https://git.openjdk.org/jdk/pull/20761

From liach at openjdk.org  Thu Aug 29 15:40:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 15:40:19 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v2]
In-Reply-To: <MYgqso2eOzA5zBr4dHIQsNDtNVRtshZLrvoShVW5jQ8=.33e422e9-8774-4733-a86e-a8da8361523c@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <MYgqso2eOzA5zBr4dHIQsNDtNVRtshZLrvoShVW5jQ8=.33e422e9-8774-4733-a86e-a8da8361523c@github.com>
Message-ID: <bbK6O3_FiAJ0k4-pDYChrbHeb6_FOjfM2GRsXbeunB4=.732ca6e7-bc59-4eea-b047-1717117105ff@github.com>

On Thu, 29 Aug 2024 15:35:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 650:

> 648: 
> 649:     /**
> 650:      * pushing an int onto the operand stack

Sorry, I didn't mean to truncate the sentence. The full sentence should be:

Generate an instruction pushing a constant int value onto the operand stack.

And so on for the other methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20761#discussion_r1736520046

From coleenp at openjdk.org  Thu Aug 29 15:48:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Aug 2024 15:48:28 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
Message-ID: <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>

On Thu, 29 Aug 2024 13:17:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Is this right?  If UseCompressedClassPointers is off, then the shared metaspace isn't in compressed space?
>
> If UseCompressedClassPointers is off, we don't have a compressed class space. If its on, Klass from CDS and from class space are compressable. With your patch, interfaces will live in normal metaspace, not int class space, so those are excluded now.
> 
> TBH, I am not really sure what this code here does, but I assume it tries to reduce the size of a JFR recording by using a compressed identifier for X if X can be expressed by such. Maybe a JFR person should look at this.

With UseCompressedClassPointers off, I think Metaspace::is_in_shared_metaspace() would still return true but I don't think he compression base is the bottom of the CDS archive.  I asked Markus to have a look.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736538545

From liach at openjdk.org  Thu Aug 29 15:48:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 15:48:27 GMT
Subject: RFR: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects [v3]
In-Reply-To: <MI1RpfmLOIWHXp9DzkFbwnWnUwS68bP7akDFqc1yHC4=.f4ecaa47-dcf2-43a6-bf77-b29f9cc04d69@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
 <MI1RpfmLOIWHXp9DzkFbwnWnUwS68bP7akDFqc1yHC4=.f4ecaa47-dcf2-43a6-bf77-b29f9cc04d69@github.com>
Message-ID: <40MBbqiENC4jL5ZZzadaQ1NZRtx78xGWrdo3i8k1-To=.275ac807-9fb2-47fd-b79b-9c69fa8ebafe@github.com>

On Wed, 28 Aug 2024 21:14:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.
>
> 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:
> 
>  - Remove redundant qualification, avoid boxing in b/sipush validation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into exp/cob-direct-methods
>  - Use uppercase L for long literals
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Moar fixes
>  - More direct code builder

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20738#issuecomment-2318190337

From liach at openjdk.org  Thu Aug 29 15:48:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 15:48:29 GMT
Subject: Integrated: 8339132: Make DirectCodeBuilder write through without
 allocating instruction objects
In-Reply-To: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
References: <_05x_BjoiHxoNlQdo1FJmmpjt2OtiEl0ZaX_wKhtbEo=.e6ff954a-aa7d-4d3d-a986-627d02d8380e@github.com>
Message-ID: <ZgrT_wsosn5GsxhOjumx6I3Uh-NU3RP04zGGshMkgvo=.9a2a4d8b-6c2f-4e08-a879-f0e681cdb031@github.com>

On Wed, 28 Aug 2024 01:49:21 GMT, Chen Liang <liach at openjdk.org> wrote:

> Make `DirectCodeBuilder` write instructions actually directly without allocating extra objects. This speed up a lot of simple Class-File building cases that never go through intermediate transforms.

This pull request has now been integrated.

Changeset: 777ed2b5
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/777ed2b5d2ef8371407cc9bf0370a7cef937cfb7
Stats:     813 lines in 4 files changed: 735 ins; 29 del; 49 mod

8339132: Make DirectCodeBuilder write through without allocating instruction objects

Reviewed-by: asotona, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20738

From sgehwolf at openjdk.org  Thu Aug 29 15:52:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Aug 2024 15:52:21 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <s_VEg2QDRw1iCAFaRqaYe0NBIviTnKnnwVBfjfaBTgw=.2ff29af7-a5c5-4d49-a0db-3a0fb2f59463@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <s_VEg2QDRw1iCAFaRqaYe0NBIviTnKnnwVBfjfaBTgw=.2ff29af7-a5c5-4d49-a0db-3a0fb2f59463@github.com>
Message-ID: <bmApdT_DlXE-Hgb3wwyMhe7up6eUanxBrO780MZXDmg=.9bb9fd65-5142-4d0f-a1cd-aa4fc09c393a@github.com>

On Thu, 29 Aug 2024 15:22:02 GMT, Matthias Baesken <mbaesken 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 10 additional commits since the last revision:
>> 
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Add Whitebox check for host cpu
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comments
>>  - 8333446: Add tests for hierarchical container support
>
> test/hotspot/jtreg/containers/systemd/SystemdMemoryAwarenessTest.java line 58:
> 
>> 56:         SystemdRunOptions opts = SystemdTestUtils.newOpts("HelloSystemd");
>> 57:         // 1 GB memory
>> 58:         opts.memoryLimit("1000M");
> 
> Just wondering - is 1G here possible (the comment states 1 GB / 1024M) ?

I probably shall fix the comment or change it to `1024M`. Either way it has to match the assertion where we look for `1048576000` bytes in the output.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1736549823

From redestad at openjdk.org  Thu Aug 29 15:55:19 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 29 Aug 2024 15:55:19 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <qJG-DT_WNC5ucEDsopJDZFgKfhQyqCrHGSpF6qHDx3I=.e4dc6078-d625-4117-b3b2-12aff87a1985@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

LGTM. On my M1 MacBook this increase total runtime of `make test TEST=.../HiddenClassUnloading.java` by 8-9s, which seems acceptable to ensure it's stable and fit for purpose on all platforms.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20771#pullrequestreview-2269300778

From liach at openjdk.org  Thu Aug 29 16:02:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 16:02:19 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <fhlVJur0n9Oyv1MC30QyE0HXeQrPD-dVwfXOwv3X5FI=.bed7c1b3-2bb1-4675-bfca-37ab9c746d83@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

Is this test still suitable as part of tier1?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20771#issuecomment-2318228878

From redestad at openjdk.org  Thu Aug 29 16:09:20 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 29 Aug 2024 16:09:20 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <flunkh7lC0nZM4DFTYkmPzx3joilj8H_RInIY683j7M=.e6dba089-3d65-4d2d-a773-584f415e178d@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

I don't think it's too long running to be a problem (for tier1). In spirit however it's a stress test/sanity check for the hidden classes defined by SCF - which might be more appropriate for some higher tier. Not sure who decides the what-goes-where on test tiers, though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20771#issuecomment-2318247130

From lancea at openjdk.org  Thu Aug 29 16:24:26 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Aug 2024 16:24:26 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java
In-Reply-To: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
Message-ID: <Tr-0uWS8tIqFm6mMUN4Gr7DJGvodcdn7J5A1vC8wU0Q=.9de52930-80c6-4b50-82a6-ba49f1d516a8@github.com>

On Wed, 28 Aug 2024 11:12:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
> 
> * The test is converted to JUnit 5
> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
> * Coverage is added for calling `available()` on a closed `ZipInputStream`
> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
> 
> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.

test/jdk/java/util/zip/Available.java line 147:

> 145:         }
> 146:     }
> 147: 

Could we collapse the two above tests  via


@ParameterizedTest
@ValueSource(strings = { "stored.txt", "delated.txt" })
void testAvailbleRemainingBytes(iString zipEntry) {
    try (ZipFile zfile = new ZipFile(zip.toFile())) {
            assertRemainingUncompressedBytes(zfile, zipEntry);
        }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20744#discussion_r1736635196

From sgehwolf at openjdk.org  Thu Aug 29 16:27:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 29 Aug 2024 16:27:22 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
Message-ID: <t9srqxRH2XGuEOYt4nRHVpQMNBQ_KjlvmqAG__z3MXQ=.4ccdcc35-dd7d-4719-80fc-64b32288f2ad@github.com>

On Wed, 28 Aug 2024 16:13:07 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 10 additional commits since the last revision:
> 
>  - Add root check for SystemdMemoryAwarenessTest.java
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

Noting here that I'll amend those tests to also cover nested hierarchical limits where the lower limit is higher up the hierarchy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2318291396

From eirbjo at openjdk.org  Thu Aug 29 16:50:56 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 16:50:56 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java [v2]
In-Reply-To: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
Message-ID: <YEAnZemdsV4AhsfDOHFreyiyqQih9Q3Aw7iVzCnQ5IU=.7191efa8-f6d2-4855-a317-5509e48a88ff@github.com>

> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
> 
> * The test is converted to JUnit 5
> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
> * Coverage is added for calling `available()` on a closed `ZipInputStream`
> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
> 
> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Collapse the ZipFile-related tests into a single, parameterized method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20744/files
  - new: https://git.openjdk.org/jdk/pull/20744/files/39e61bac..8ae9e0d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20744&range=00-01

  Stats: 58 lines in 1 file changed: 7 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20744/head:pull/20744

PR: https://git.openjdk.org/jdk/pull/20744

From erikj at openjdk.org  Thu Aug 29 16:53:19 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Aug 2024 16:53:19 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <jaXduuwskjnlK5V0p_Lk6xv6f9A_V9axTA9Kc4pVGNs=.873196ed-6f57-465a-9bd6-5e3f9c41294b@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2269506759

From eirbjo at openjdk.org  Thu Aug 29 16:53:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 16:53:19 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java [v2]
In-Reply-To: <Tr-0uWS8tIqFm6mMUN4Gr7DJGvodcdn7J5A1vC8wU0Q=.9de52930-80c6-4b50-82a6-ba49f1d516a8@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
 <Tr-0uWS8tIqFm6mMUN4Gr7DJGvodcdn7J5A1vC8wU0Q=.9de52930-80c6-4b50-82a6-ba49f1d516a8@github.com>
Message-ID: <H1jwn3RJiz798UjtKRAYT9peQ1k3vskx5jBCSfxQ8oE=.e83c2fd6-7766-47a3-92ad-7c695830e3d4@github.com>

On Thu, 29 Aug 2024 16:21:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Collapse the ZipFile-related tests into a single, parameterized method
>
> test/jdk/java/util/zip/Available.java line 147:
> 
>> 145:         }
>> 146:     }
>> 147: 
> 
> Could we collapse the two above tests  via
> 
> 
> @ParameterizedTest
> @ValueSource(strings = { "stored.txt", "delated.txt" })
> void testAvailbleRemainingBytes(iString zipEntry) {
>     try (ZipFile zfile = new ZipFile(zip.toFile())) {
>             assertRemainingUncompressedBytes(zfile, zipEntry);
>         }
> }

I like it!

I collapsed `ZipFile` related tests into the method `testZipFileStreamsRemainingBytes` and inlined the `assertRemainingUncompressedBytes` method into that.

A few minor improvements to the inlined `assertRemainingUncompressedBytes` code body:

* Added a comment saying that the `InputStream` could be `ZipFileInputStream` or `ZipFileInflaterInputStream`
* Moved the "decrement by one" assertion logic into the loop, asserting decrement on each iteration 
* Cleaned up some spacing issues in the for loop

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20744#discussion_r1736708432

From lancea at openjdk.org  Thu Aug 29 16:58:18 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Aug 2024 16:58:18 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java [v2]
In-Reply-To: <YEAnZemdsV4AhsfDOHFreyiyqQih9Q3Aw7iVzCnQ5IU=.7191efa8-f6d2-4855-a317-5509e48a88ff@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
 <YEAnZemdsV4AhsfDOHFreyiyqQih9Q3Aw7iVzCnQ5IU=.7191efa8-f6d2-4855-a317-5509e48a88ff@github.com>
Message-ID: <YdkcoeD9nyEQKx3-zTth9n0Qa_Txc34U9NouKoKi0gM=.8aefe137-1b85-4799-91cf-bcae9e342b58@github.com>

On Thu, 29 Aug 2024 16:50:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
>> 
>> * The test is converted to JUnit 5
>> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
>> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
>> * Coverage is added for calling `available()` on a closed `ZipInputStream`
>> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
>> 
>> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collapse the ZipFile-related tests into a single, parameterized method

Thank you for the additional tweaks/improvements.


Test looks much better

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20744#pullrequestreview-2269522988

From eirbjo at openjdk.org  Thu Aug 29 17:09:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 17:09:51 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java [v3]
In-Reply-To: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
Message-ID: <L673T14Sup_DArXrCSuvVd8p28rc9CWZYj4WBgtrWLA=.d55b7221-33fc-463f-81fa-62d2cc0f3d98@github.com>

> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
> 
> * The test is converted to JUnit 5
> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
> * Coverage is added for calling `available()` on a closed `ZipInputStream`
> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
> 
> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Actually make "stored.txt" use the STORED method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20744/files
  - new: https://git.openjdk.org/jdk/pull/20744/files/8ae9e0d4..0867317c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20744&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20744&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20744/head:pull/20744

PR: https://git.openjdk.org/jdk/pull/20744

From lancea at openjdk.org  Thu Aug 29 17:09:51 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 29 Aug 2024 17:09:51 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java [v3]
In-Reply-To: <L673T14Sup_DArXrCSuvVd8p28rc9CWZYj4WBgtrWLA=.d55b7221-33fc-463f-81fa-62d2cc0f3d98@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
 <L673T14Sup_DArXrCSuvVd8p28rc9CWZYj4WBgtrWLA=.d55b7221-33fc-463f-81fa-62d2cc0f3d98@github.com>
Message-ID: <sGjCBV3Z-rVU5fOobut7_6rKv1U2yGwg5jBnRWL1yAk=.2a46a6a0-24a3-427d-920f-4da91bf3718d@github.com>

On Thu, 29 Aug 2024 17:07:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
>> 
>> * The test is converted to JUnit 5
>> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
>> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
>> * Coverage is added for calling `available()` on a closed `ZipInputStream`
>> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
>> 
>> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Actually make "stored.txt" use the STORED method

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20744#pullrequestreview-2269550213

From eirbjo at openjdk.org  Thu Aug 29 17:09:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 29 Aug 2024 17:09:52 GMT
Subject: RFR: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java [v2]
In-Reply-To: <YEAnZemdsV4AhsfDOHFreyiyqQih9Q3Aw7iVzCnQ5IU=.7191efa8-f6d2-4855-a317-5509e48a88ff@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
 <YEAnZemdsV4AhsfDOHFreyiyqQih9Q3Aw7iVzCnQ5IU=.7191efa8-f6d2-4855-a317-5509e48a88ff@github.com>
Message-ID: <vIm5nveu7Sdv5xx8BxPlHjuoLjmiki9YVi9F8Fjrk5U=.e81019ef-0c1c-407a-877c-1d917897ac22@github.com>

On Thu, 29 Aug 2024 16:50:56 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
>> 
>> * The test is converted to JUnit 5
>> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
>> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
>> * Coverage is added for calling `available()` on a closed `ZipInputStream`
>> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
>> 
>> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collapse the ZipFile-related tests into a single, parameterized method

Turns out that naming a ZipEntry "stored.txt" does not actually make it stored! ? 

@LanceAndersen I'll need a re-review for the following line in `setup`:

`stored.setMethod(ZipEntry.STORED);`

I have verified using the debugger that each invocation now sees the expected ZipFile InputStream implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20744#issuecomment-2318393509

From mgronlun at openjdk.org  Thu Aug 29 17:29:21 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:29:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
Message-ID: <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>

On Thu, 29 Aug 2024 15:45:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> If UseCompressedClassPointers is off, we don't have a compressed class space. If its on, Klass from CDS and from class space are compressable. With your patch, interfaces will live in normal metaspace, not int class space, so those are excluded now.
>> 
>> TBH, I am not really sure what this code here does, but I assume it tries to reduce the size of a JFR recording by using a compressed identifier for X if X can be expressed by such. Maybe a JFR person should look at this.
>
> With UseCompressedClassPointers off, I think Metaspace::is_in_shared_metaspace() would still return true but I don't think he compression base is the bottom of the CDS archive.  I asked Markus to have a look.

The code supports the JfrTraceID load barrier that enqueues tagged Klass*. It selects a more compact representation (a single word, instead of two words), if a Klass* can be compressed (i.e. there exists a compress class scheme in place (CompressedKlassPointers::encode(const_cast<Klass*>(klass)); AND the traceid (u8) value is low enough to be represented by only 4 bytes).

struct JfrEpochQueueKlassElement {
  traceid id;
  const Klass* klass;
};

struct JfrEpochQueueNarrowKlassElement {
  u4 id;
  narrowKlass compressed_klass;
};

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736775534

From mgronlun at openjdk.org  Thu Aug 29 17:29:22 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:29:22 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
Message-ID: <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>

On Thu, 29 Aug 2024 17:24:47 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> With UseCompressedClassPointers off, I think Metaspace::is_in_shared_metaspace() would still return true but I don't think he compression base is the bottom of the CDS archive.  I asked Markus to have a look.
>
> The code supports the JfrTraceID load barrier that enqueues tagged Klass*. It selects a more compact representation (a single word, instead of two words), if a Klass* can be compressed (i.e. there exists a compress class scheme in place (CompressedKlassPointers::encode(const_cast<Klass*>(klass)); AND the traceid (u8) value is low enough to be represented by only 4 bytes).
> 
> struct JfrEpochQueueKlassElement {
>   traceid id;
>   const Klass* klass;
> };
> 
> struct JfrEpochQueueNarrowKlassElement {
>   u4 id;
>   narrowKlass compressed_klass;
> };

// Return TRUE only if UseCompressedClassPointers is True.
  static bool using_class_space() {
    return NOT_LP64(false) LP64_ONLY(UseCompressedClassPointers);
  }
  
  I see now that was wrong for 32-bit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736779802

From mgronlun at openjdk.org  Thu Aug 29 17:33:24 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:33:24 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
Message-ID: <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>

On Thu, 29 Aug 2024 17:26:57 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The code supports the JfrTraceID load barrier that enqueues tagged Klass*. It selects a more compact representation (a single word, instead of two words), if a Klass* can be compressed (i.e. there exists a compress class scheme in place (CompressedKlassPointers::encode(const_cast<Klass*>(klass)); AND the traceid (u8) value is low enough to be represented by only 4 bytes).
>> 
>> struct JfrEpochQueueKlassElement {
>>   traceid id;
>>   const Klass* klass;
>> };
>> 
>> struct JfrEpochQueueNarrowKlassElement {
>>   u4 id;
>>   narrowKlass compressed_klass;
>> };
>
> // Return TRUE only if UseCompressedClassPointers is True.
>   static bool using_class_space() {
>     return NOT_LP64(false) LP64_ONLY(UseCompressedClassPointers);
>   }
>   
>   I see now that was wrong for 32-bit.

In summary, we are agnostic about which space the Klass* is located in; we only care if a valid means exists to perform an encode() and decode() operation to compress the Klass* (for 64-bit to be clear).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736786419

From mgronlun at openjdk.org  Thu Aug 29 17:37:21 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:37:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
Message-ID: <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>

On Thu, 29 Aug 2024 17:30:26 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> // Return TRUE only if UseCompressedClassPointers is True.
>>   static bool using_class_space() {
>>     return NOT_LP64(false) LP64_ONLY(UseCompressedClassPointers);
>>   }
>>   
>>   I see now that was wrong for 32-bit.
>
> In summary, we are agnostic about which space the Klass* is located in; we only care if a valid means exists to perform an encode() and decode() operation to compress the Klass* (for 64-bit to be clear). This may now become a function of what space the Klass resides in?

Its very rare, if at all, that an abstract or an interface would be tagged in JFR. Tags are for concrete implementations, mostly InstanceKlass*.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736795292

From mgronlun at openjdk.org  Thu Aug 29 17:48:21 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:48:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
 <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
Message-ID: <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJAiXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>

On Thu, 29 Aug 2024 17:35:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> In summary, we are agnostic about which space the Klass* is located in; we only care if a valid means exists to perform an encode() and decode() operation to compress the Klass* (for 64-bit to be clear). This may now become a function of what space the Klass resides in?
>
> Its very rare, if at all, that an abstract or an interface would be tagged in JFR. Tags are for concrete implementations, mostly InstanceKlass*.

I now read the JIRA issue. JFR do process loads of  java/lang/invoke/LambdaForm$MH and derivatives.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736809566

From mgronlun at openjdk.org  Thu Aug 29 17:48:21 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:48:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJAiXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
 <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
 <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJA
 iXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>
Message-ID: <BInCJopk2cH-uwa9S-rRLRn8e7thaoakqYn48_MGUE4=.df8a2ab0-0729-4675-b9f8-7c9f9d2c5224@github.com>

On Thu, 29 Aug 2024 17:42:20 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Its very rare, if at all, that an abstract or an interface would be tagged in JFR. Tags are for concrete implementations, mostly InstanceKlass*.
>
> I now read the JIRA issue. JFR do process loads of  java/lang/invoke/LambdaForm$MH and derivatives.

It's fine to have each Klass* report whether it can be compressed. If not, it will be represented using the non-compressed version, which will be a bit more bloated, but no problems.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736814770

From coleenp at openjdk.org  Thu Aug 29 17:48:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Aug 2024 17:48:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <BInCJopk2cH-uwa9S-rRLRn8e7thaoakqYn48_MGUE4=.df8a2ab0-0729-4675-b9f8-7c9f9d2c5224@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
 <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
 <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJA
 iXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>
 <BInCJopk2cH-uwa9S-rRLRn8e7thaoakqYn48_MGUE4=.df8a2ab0-0729-4675-b9f8-7c9f9d2c5224@github.com>
Message-ID: <xf3yDeyNRrKAXbUSF-ppeKOy2hEJnAYqwuJUAZa96Dg=.1efbafca-9b31-47e3-b06c-94e64cd14fef@github.com>

On Thu, 29 Aug 2024 17:45:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I now read the JIRA issue. JFR do process loads of  java/lang/invoke/LambdaForm$MH and derivatives.
>
> It's fine to have each Klass* report whether it can be compressed. If not, it will be represented using the non-compressed version, which will be a bit more bloated, but no problems.

narrowKlass is the result of encoding Klass* with CompressedKlassPointers::encode() which is relative to the compressed base, so if UseCompressedClassPointers is false then the encoding to narrowKlass from some other (CDS?) base isn't valid.
using_class_space() above doesn't look wrong for 32 bits.  It should return false.

With this patch, interface and abstract classes cannot be encoded and decoded to yield a valid compressed narrowKlass, since they're now allocated in the non-class metaspace.  Yes, this now a function of which space the Klass resides in.  We do crash for these classes in JFR without this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736816371

From mgronlun at openjdk.org  Thu Aug 29 17:58:23 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 17:58:23 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <xf3yDeyNRrKAXbUSF-ppeKOy2hEJnAYqwuJUAZa96Dg=.1efbafca-9b31-47e3-b06c-94e64cd14fef@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
 <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
 <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJA
 iXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>
 <BInCJopk2cH-uwa9S-rRLRn8e7thaoakqYn48_MGUE4=.df8a2ab0-0729-4675-b9f8-7c9f9d2c5224@github.com>
 <xf3yDeyNRrKAXbUSF-ppeKOy2hEJnAYqwuJUAZa96Dg=.1efbafca-9b31-47e3-b06c-94e64cd14fef@github.com>
Message-ID: <MMY9exY1Rp7tVYR4lGWjIL2_1_z60TjKdmPP4MnEUPw=.ff9e85e2-9ddd-48ea-9ff7-21deb68d0819@github.com>

On Thu, 29 Aug 2024 17:46:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> It's fine to have each Klass* report whether it can be compressed. If not, it will be represented using the non-compressed version, which will be a bit more bloated, but no problems.
>
> narrowKlass is the result of encoding Klass* with CompressedKlassPointers::encode() which is relative to the compressed base, so if UseCompressedClassPointers is false then the encoding to narrowKlass from some other (CDS?) base isn't valid.
> using_class_space() above doesn't look wrong for 32 bits.  It should return false.
> 
> With this patch, interface and abstract classes cannot be encoded and decoded to yield a valid compressed narrowKlass, since they're now allocated in the non-class metaspace.  Yes, this now a function of which space the Klass resides in.  We do crash for these classes in JFR without this change.

I mean its wrong from JFRs perspective not to handle 32-bit outside of the call to using_class_space(), because that call will always be false for 32-bit, although the Klass* will still fit in 4-bytes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736834488

From mgronlun at openjdk.org  Thu Aug 29 18:33:34 2024
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 29 Aug 2024 18:33:34 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <MMY9exY1Rp7tVYR4lGWjIL2_1_z60TjKdmPP4MnEUPw=.ff9e85e2-9ddd-48ea-9ff7-21deb68d0819@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
 <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
 <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJA
 iXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>
 <BInCJopk2cH-uwa9S-rRLRn8e7thaoakqYn48_MGUE4=.df8a2ab0-0729-4675-b9f8-7c9f9d2c5224@github.com>
 <xf3yDeyNRrKAXbUSF-ppeKOy2hEJnAYqwuJUAZa96Dg=.1efbafca-9b31-47e3-b06c-94e64cd14fef@github.com>
 <MMY9exY1Rp7tVYR4lGWjIL2_1_z60TjKdmPP4MnEUPw=.ff9e85e2-9ddd-48ea-9ff7-21deb68d0819@github.com>
Message-ID: <JdfZ-5YPFRmB0SEKykedKouGeN-qaMwLN-5A-PHpOao=.d2f152c6-cb58-40a1-a464-caf1361fa585@github.com>

On Thu, 29 Aug 2024 17:55:53 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> narrowKlass is the result of encoding Klass* with CompressedKlassPointers::encode() which is relative to the compressed base, so if UseCompressedClassPointers is false then the encoding to narrowKlass from some other (CDS?) base isn't valid.
>> using_class_space() above doesn't look wrong for 32 bits.  It should return false.
>> 
>> With this patch, interface and abstract classes cannot be encoded and decoded to yield a valid compressed narrowKlass, since they're now allocated in the non-class metaspace.  Yes, this now a function of which space the Klass resides in.  We do crash for these classes in JFR without this change.
>
> I mean its wrong from JFRs perspective not to handle 32-bit outside of the call to using_class_space(), because that call will always be false for 32-bit, although the Klass* will still fit in 4-bytes. This means trying to represent the tracied (which is always 64-bit) more effectively is skipped on 32-bit.

Looks ok from a JFR perspective, Coleen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736895410

From coleenp at openjdk.org  Thu Aug 29 18:47:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Aug 2024 18:47:21 GMT
Subject: RFR: 8338526: Don't store abstract and interface Klasses in class
 metaspace [v4]
In-Reply-To: <JdfZ-5YPFRmB0SEKykedKouGeN-qaMwLN-5A-PHpOao=.d2f152c6-cb58-40a1-a464-caf1361fa585@github.com>
References: <qvPR--QtegDtJdI7fIp-VeCWp74JnBp0LCmRJOTrlV8=.8111f62c-31bc-4974-ac82-ce8c9093af10@github.com>
 <DmVfekDI_Qh2lOh7qbWoB1wJl36OjQk5aKJ2im2bIHY=.6a147fdd-3a20-4b50-8f8c-4a2c82779a94@github.com>
 <oJTdsO63aFWYmGsqP33VYYUoDdf9b49c_XockNljaIg=.cf682351-cc7a-40aa-83e1-424a2e9702fa@github.com>
 <pkxWurpSZszEPGkyUa7a2iMfM2q4lyC9k4pP92Hwql8=.3efe8a9b-7687-45d8-9eb4-eaab2b1aa837@github.com>
 <--5KRqr06ENVgu5CvmEG0zpAUvvYWUqnVHzQDL8x488=.2bc136c2-005f-4e7c-ac46-5706f189d20b@github.com>
 <_XsCkv5395DpEgFGjzEnGOaphwwu6ttYPWBx1dZDIMk=.4fc3a6e0-8935-4d19-b9bc-0cecf687b5a8@github.com>
 <7w9D5LRW8UJ2Xb9Mm7Wd5kL_T88jo6UjQDup4ntxjmk=.f84b964c-12fc-420f-982a-d86522d7e7d9@github.com>
 <k8C59Z9njdQ8zLXBzM4wk3i897PEJPzToe6f0vfHVEE=.b4a944ef-04be-49d3-9c2f-4d0944e93a72@github.com>
 <BGk4SAyVTQKYbO-vBeaVujY5HB_IXG1B7u5GDhP3WaU=.73c6b036-e767-4803-9b11-ba63fdc4943e@github.com>
 <T_HCXaJGgAQwSLv7qDJWMgn8uNYvFTB-IN9sSvXOphE=.95879430-0ba6-45f4-b02d-9dca3587c6f9@github.com>
 <q-__v_3AiSYWMVTwgIoWias-xM7BqXx0tJA
 iXiL2HXM=.97744763-f625-4464-a21b-b70ecd32afd8@github.com>
 <BInCJopk2cH-uwa9S-rRLRn8e7thaoakqYn48_MGUE4=.df8a2ab0-0729-4675-b9f8-7c9f9d2c5224@github.com>
 <xf3yDeyNRrKAXbUSF-ppeKOy2hEJnAYqwuJUAZa96Dg=.1efbafca-9b31-47e3-b06c-94e64cd14fef@github.com>
 <MMY9exY1Rp7tVYR4lGWjIL2_1_z60TjKdmPP4MnEUPw=.ff9e85e2-9ddd-48ea-9ff7-21deb68d0819@github.com>
 <JdfZ-5YPFRmB0SEKykedKouGeN-qaMwLN-5A-PHpOao=.d2f152c6-cb58-40a1-a464-caf1361fa585@github.com>
Message-ID: <mounNljxxA5aFh0Qo2tFQ4aBAHZGopklUD3IsPZowco=.fe7a6150-0209-45fa-a095-c8da916670ba@github.com>

On Thu, 29 Aug 2024 18:30:13 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> I mean its wrong from JFRs perspective not to handle 32-bit outside of the call to using_class_space(), because that call will always be false for 32-bit, although the Klass* will still fit in 4-bytes. This means trying to represent the tracied (which is always 64-bit) more effectively is skipped on 32-bit.
>
> Looks ok from a JFR perspective, Coleen.

Thank you Markus.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19157#discussion_r1736918572

From kbarrett at openjdk.org  Thu Aug 29 18:48:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Aug 2024 18:48:20 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <GK2LiZr5-psH4LxqYJzOeT7eY3lq5T7z0K1TueGzn2Q=.144dd5fd-8192-4a3e-884f-50d118a9fc06@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

Looks good.

make/autoconf/flags-cflags.m4 line 266:

> 264:       # These warnings will never be turned on, since they generate too many
> 265:       # false positives.
> 266:       DISABLED_WARNINGS="unknown-warning-option unused-parameter"

JDK-8339120 added -Wunused-const-variable=1 and -Wunused-result to gcc's
WARNINGS_ENABLE_ADDITIONAL, to "make up" for the corresponding removal of
disabling -Wunused. That isn't done here. I assume that was intentional,
probably to avoid needing more of the specific disables in this PR. That's
fine. We can do more warning option cleanups later in conjunction with
corresponding code changes.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2269819308
PR Review Comment: https://git.openjdk.org/jdk/pull/20770#discussion_r1736918417

From liach at openjdk.org  Thu Aug 29 20:21:32 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 20:21:32 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode,
 ConstantDesc)
Message-ID: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>

8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc)

-------------

Commit messages:
 - Improve specs for ConstantInstruction.ofArgument
 - 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc)

Changes: https://git.openjdk.org/jdk/pull/20779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339214
  Stats: 205 lines in 10 files changed: 7 ins; 157 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/20779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20779/head:pull/20779

PR: https://git.openjdk.org/jdk/pull/20779

From ihse at openjdk.org  Thu Aug 29 20:43:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 29 Aug 2024 20:43:20 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <GK2LiZr5-psH4LxqYJzOeT7eY3lq5T7z0K1TueGzn2Q=.144dd5fd-8192-4a3e-884f-50d118a9fc06@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
 <GK2LiZr5-psH4LxqYJzOeT7eY3lq5T7z0K1TueGzn2Q=.144dd5fd-8192-4a3e-884f-50d118a9fc06@github.com>
Message-ID: <jKYklFcR9lbszuS_j1drGdjjLFjay1E5-0T1IuuFC5E=.1216db2a-d72b-43ec-a980-90dd3b6eb70e@github.com>

On Thu, 29 Aug 2024 18:44:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>> 
>> This is similar to what has been done for gcc in JDK-8339120.
>
> make/autoconf/flags-cflags.m4 line 266:
> 
>> 264:       # These warnings will never be turned on, since they generate too many
>> 265:       # false positives.
>> 266:       DISABLED_WARNINGS="unknown-warning-option unused-parameter"
> 
> JDK-8339120 added -Wunused-const-variable=1 and -Wunused-result to gcc's
> WARNINGS_ENABLE_ADDITIONAL, to "make up" for the corresponding removal of
> disabling -Wunused. That isn't done here. I assume that was intentional,
> probably to avoid needing more of the specific disables in this PR. That's
> fine. We can do more warning option cleanups later in conjunction with
> corresponding code changes.

No, it was just not needed by clang. `-Wunused-result` is enabled by `-Wunused-value` which is enabled by `-Wunused` which is enabled by `-Wall`. Or something like that. I think it made sense, but the documentation was bad so you had to jump around to understand how things were related.

`Wunused-const-variable=1` does not exist in clang, but whatever the closest matching thing was, was enabled as well indirectly already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20770#discussion_r1737153568

From duke at openjdk.org  Thu Aug 29 21:19:18 2024
From: duke at openjdk.org (duke)
Date: Thu, 29 Aug 2024 21:19:18 GMT
Subject: RFR: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <KTw01kQTU9gvK3ElDYWihmVb6mM3xv6Re19C0CnlH0I=.17862744-dc64-4f62-8259-79a0aa561b51@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

@wenshao 
Your change (at version cd1140c1782255a5a1fcaaac89a37d21bf32582b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20748#issuecomment-2319021285

From swen at openjdk.org  Thu Aug 29 21:22:34 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 21:22:34 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v3]
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <2Fbh_rSLTNNXWkNu8-9W11k06LWksgC1BwXkIn07bPQ=.bc164a9b-3218-4429-9587-102c967e91be@github.com>

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20761/files
  - new: https://git.openjdk.org/jdk/pull/20761/files/46f10606..b6a91409

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20761/head:pull/20761

PR: https://git.openjdk.org/jdk/pull/20761

From swen at openjdk.org  Thu Aug 29 21:24:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 21:24:24 GMT
Subject: Integrated: 8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long
In-Reply-To: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
References: <BhwIfnZiTe96GrCwycKINK_3638P23ccp5Rp9KRdSdI=.c6bdc2ff-4e94-440b-84c2-dba7e3c0a808@github.com>
Message-ID: <Jqr5Xi5NHhhA9bPwWJfkzn3c5zpNEXFY-Dgbjk-G5TM=.bde9e3e7-8145-4dec-84f2-763f75e3e2b2@github.com>

On Wed, 28 Aug 2024 13:16:03 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization makes BufWriterImpl's writeU1/U2/Int/Long methods more C2-friendly and improves performance.

This pull request has now been integrated.

Changeset: b711c41d
Author:    Shaojin Wen <swen at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b711c41d442fc369a84745c0203db638e0b7e671
Stats:     42 lines in 1 file changed: 32 ins; 3 del; 7 mod

8339196: Optimize BufWriterImpl#writeU1/U2/Int/Long

Reviewed-by: liach, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/20748

From swen at openjdk.org  Thu Aug 29 21:29:30 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 Aug 2024 21:29:30 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v4]
In-Reply-To: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
Message-ID: <TJu1pU4QYbSCWjBOgSsKvkSprsc58BJ5Nfq4Wqd1DO4=.936c4183-e058-450f-a10c-dd213da9c72f@github.com>

> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
> 
> * current
> 
> CodeBuilder {
>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
> }
> 
> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large

Shaojin Wen 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 remote-tracking branch 'upstream/master' into optim_classfile_loadconstant_2020408
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
 - comments
 - fix comment
 - since 24
 - optimize loadConstant

-------------

Changes: https://git.openjdk.org/jdk/pull/20761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20761&range=03
  Stats: 87 lines in 2 files changed: 59 ins; 22 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20761/head:pull/20761

PR: https://git.openjdk.org/jdk/pull/20761

From liach at openjdk.org  Thu Aug 29 21:29:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 21:29:30 GMT
Subject: RFR: 8339217: Optimize ClassFile API loadConstant [v3]
In-Reply-To: <2Fbh_rSLTNNXWkNu8-9W11k06LWksgC1BwXkIn07bPQ=.bc164a9b-3218-4429-9587-102c967e91be@github.com>
References: <-ZEPcHBC5BHgGozMK43lt7WWsSL-1ObajxqQhAxgfxU=.ca1f26ea-0c64-45ae-805b-531f2a6c009a@github.com>
 <2Fbh_rSLTNNXWkNu8-9W11k06LWksgC1BwXkIn07bPQ=.bc164a9b-3218-4429-9587-102c967e91be@github.com>
Message-ID: <i0RE_gTVLbaQfTLMIv6qafZQ-1RZNS_cajTadd23XXo=.a7ac686a-2bdc-41ac-b62c-df3d63561f6c@github.com>

On Thu, 29 Aug 2024 21:22:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This is a large method. By splitting it into multiple methods with the same name, the caller can automatically select based on the different types of parameters, avoiding this large call that cannot be inlined, which can also improve startup performance.
>> 
>> * current
>> 
>> CodeBuilder {
>>     default CodeBuilder loadConstant(ConstantDesc value) { ... }
>> }
>> 
>> java.lang.classfile.CodeBuilder::loadConstant (465 bytes)   failed to inline: callee is too large
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

I have updated the CSR with your latest specs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20761#issuecomment-2319035051

From liach at openjdk.org  Thu Aug 29 21:32:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 21:32:29 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile
Message-ID: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>

Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.

This simplification of `ClassFile` constants improves user onramp to the Class-File API.

Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

-------------

Commit messages:
 - Compile errors; now tests are all green.
 - Move Constant Pool tags to PoolEntry
 - opcode values moved to OpcodeValues
 - Hide default class flags as well
 - Simplify SimpleVerificationTypeInfo's constant names
 - 8339260: Move rarely used constants out of ClassFile

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339260
  Stats: 2613 lines in 36 files changed: 865 ins; 905 del; 843 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

PR: https://git.openjdk.org/jdk/pull/20773

From jlu at openjdk.org  Thu Aug 29 21:45:32 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 Aug 2024 21:45:32 GMT
Subject: RFR: 8338882: Clarify matching order of MessageFormat subformat
 factory styles [v2]
In-Reply-To: <6y7WfaWdoIJGDvbj9NxDqx0RbxxFrfaLY0_AIHqrETs=.6139748e-eae0-412b-80ad-21ae7886a0c9@github.com>
References: <6y7WfaWdoIJGDvbj9NxDqx0RbxxFrfaLY0_AIHqrETs=.6139748e-eae0-412b-80ad-21ae7886a0c9@github.com>
Message-ID: <Js2eNSsF6CQmmJTlUuDg0OM7rcd7Y9kUYod5RKH3a_8=.b30d7034-4de9-4d69-b8d8-a52a790878b0@github.com>

> Please review this PR which clarifies that the matching order of format styles for MessageFormat sub formats is not guaranteed by the JDK implementation. A corresponding CSR has also been drafted.
> 
> This is relevant when a locale provides equivalent patterns for multiple format factory styles. For example, a locale X could provide some equivalent date style "xyz" for both a MEDIUM and LONG style. Thus invoking toPattern() could output `date`, `date,medium`, or `date,long` depending on the order of such matching.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  revise wording

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20695/files
  - new: https://git.openjdk.org/jdk/pull/20695/files/7953073b..8d434f29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20695&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20695&range=00-01

  Stats: 8 lines in 1 file changed: 3 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20695/head:pull/20695

PR: https://git.openjdk.org/jdk/pull/20695

From liach at openjdk.org  Thu Aug 29 21:46:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 21:46:52 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, 
 ConstantDesc) [v2]
In-Reply-To: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
Message-ID: <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>

> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and confusing. Users should almost always use `loadConstant(ConstantDesc)` for optimized instructions, or use specific factories `iconst_0` etc. or `bipush` with arguments or `LoadConstantInstruction.of` if they want to specify the exact type of LDC opcode.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Move bipush and sipush fix from Opcode cleanup to this patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20779/files
  - new: https://git.openjdk.org/jdk/pull/20779/files/8c5e6fd8..86c4104d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20779&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20779&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20779/head:pull/20779

PR: https://git.openjdk.org/jdk/pull/20779

From liach at openjdk.org  Thu Aug 29 21:59:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 21:59:27 GMT
Subject: RFR: 8339131: Remove rarely-used accessor methods from Opcode
Message-ID: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>

In offline discussion, we agreed that current fields of `Opcode` violate data oriented design to a large extent. The attributes not generic to all opcode are removed.

Up for preliminary review; needs to be reworked for #20737.

-------------

Commit messages:
 - Fix ofArgument in loadConstant patch instead, improve specs
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/opcode-clean
 - Clean up opcode fields

Changes: https://git.openjdk.org/jdk/pull/20757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339131
  Stats: 473 lines in 8 files changed: 190 ins; 79 del; 204 mod
  Patch: https://git.openjdk.org/jdk/pull/20757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20757/head:pull/20757

PR: https://git.openjdk.org/jdk/pull/20757

From naoto at openjdk.org  Thu Aug 29 22:11:19 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Aug 2024 22:11:19 GMT
Subject: RFR: 8338882: Clarify matching order of MessageFormat subformat
 factory styles [v2]
In-Reply-To: <Js2eNSsF6CQmmJTlUuDg0OM7rcd7Y9kUYod5RKH3a_8=.b30d7034-4de9-4d69-b8d8-a52a790878b0@github.com>
References: <6y7WfaWdoIJGDvbj9NxDqx0RbxxFrfaLY0_AIHqrETs=.6139748e-eae0-412b-80ad-21ae7886a0c9@github.com>
 <Js2eNSsF6CQmmJTlUuDg0OM7rcd7Y9kUYod5RKH3a_8=.b30d7034-4de9-4d69-b8d8-a52a790878b0@github.com>
Message-ID: <rEWOzI6YCZuwu70N-4AS2dGm58borS_jd49euGq6XDU=.5ea8550e-a2f8-4e02-85af-ed0ebddc9f06@github.com>

On Thu, 29 Aug 2024 21:45:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies that the matching order of format styles for MessageFormat sub formats is not guaranteed. A corresponding CSR has also been drafted.
>> 
>> This is relevant when a locale provides equivalent patterns for multiple format factory styles. For example, a locale X could provide some equivalent date style "xyz" for both a MEDIUM and LONG style. Thus invoking toPattern() could output `date`, `date,medium`, or `date,long` depending on the order of such matching.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revise wording

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20695#pullrequestreview-2270324203

From iklam at openjdk.org  Thu Aug 29 22:11:36 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 29 Aug 2024 22:11:36 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
Message-ID: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>

> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> Add the following command-line options as specified in JEP 483:
> 
> 
> - `-XX:AOTMode=off/record/create/auto/on`
> - `-XX:AOTConfiguration=<file>.aotconfig`
> - `-XX:AOTCache=<file>.aot`
> 
> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
> 
> Please see the CSR (TODO) for detailed specification.
> 
> -----
> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20516/files
  - new: https://git.openjdk.org/jdk/pull/20516/files/1fd5b154..1da2ed9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20516&range=01-02

  Stats: 12 lines in 2 files changed: 7 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20516/head:pull/20516

PR: https://git.openjdk.org/jdk/pull/20516

From iklam at openjdk.org  Thu Aug 29 22:14:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 29 Aug 2024 22:14:20 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v2]
In-Reply-To: <4oKtHm2hR1CyyDh9TImcbTcfe0FhrWNnZsY915494cE=.b8a662b6-b1f2-44a7-9bf1-5e3dfccc7547@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <EeFA_XcicxNG31_1NvccLJieHtjUQm2FPUnnWPCNkw4=.6b00686a-021f-4129-8809-fe4a0fabcc6a@github.com>
 <oC2ZnKYlfMA194YjGSF56KfBfmP3nVD2qbYh3hEE8pk=.74999fc0-00fe-481b-89be-0fd6146a7649@github.com>
 <4oKtHm2hR1CyyDh9TImcbTcfe0FhrWNnZsY915494cE=.b8a662b6-b1f2-44a7-9bf1-5e3dfccc7547@github.com>
Message-ID: <iyQHIFQvkyth1T-mOHoHHyXDol0q-PDq4yw7BTVLseo=.53744a40-ae22-4489-938d-f866668e757d@github.com>

On Thu, 29 Aug 2024 05:10:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1521:
>> 
>>> 1519:             dumpSharedSpaces = JNI_TRUE;
>>> 1520:         }
>>> 1521:         if (JLI_StrCmp(arg, "-XX:AOTMode=create") == 0) {
>> 
>> This is inappropriate - the launcher does not, and should not, process hotspot -XX options. Any aliasing should happen in the hotspot argument processing logic.
>
> I realize this poses a problem with communicating to the launcher that this is a "terminal" flag. Maybe AOT should have -X flags instead of -XX?

Hi David, thanks for the review. After off-line discussion, I think it's best to remove this check from the launcher, and exit the JVM directly when `-XX:AOTMode=create` is specified. This is the same way as how `-Xlog:help` is handled. See 

https://github.com/openjdk/jdk/blob/b711c41d442fc369a84745c0203db638e0b7e671/src/hotspot/share/runtime/arguments.cpp#L2588-L2591

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20516#discussion_r1737274460

From liach at openjdk.org  Thu Aug 29 22:33:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Aug 2024 22:33:34 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v4]
In-Reply-To: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
Message-ID: <c32KOKGermwbLmpnArWtsdCn9yXTnExmjwrRDVoY8so=.3ca05a51-7876-4f63-9465-94b4c88c1b6d@github.com>

> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
> 
> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
> 
> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
> 
> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.

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 six additional commits since the last revision:

 - Reorder float and long to match instruction order, fix compilation
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
 - space
 - More fixes, reorder constants
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
 - 8339115: Rename TypeKind enum constants to follow code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20737/files
  - new: https://git.openjdk.org/jdk/pull/20737/files/41f81fe8..3ab23576

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20737&range=02-03

  Stats: 2553 lines in 73 files changed: 2112 ins; 146 del; 295 mod
  Patch: https://git.openjdk.org/jdk/pull/20737.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20737/head:pull/20737

PR: https://git.openjdk.org/jdk/pull/20737

From sviswanathan at openjdk.org  Thu Aug 29 23:41:22 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 29 Aug 2024 23:41:22 GMT
Subject: RFR: 8338021: Support saturating vector operators in VectorAPI
 [v4]
In-Reply-To: <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
References: <g3rwFcFZZDVhGuecF8z1mKH7_M1IvtCblB5gbUtktBo=.8eef86f5-c773-4555-be7b-6e7934e477e9@github.com>
 <M9T8VWIeQzLkfX3kT3LLwaPoa-lTEoFa9sDI5bL4VQ4=.f5857029-e84b-4b7e-8592-54b4beea4c5d@github.com>
Message-ID: <VQFhSHRAW-6503NcI20jnteC3CArIEqNt8G077QG-Yo=.d77ff8fa-6067-45c5-a829-c30006ffada6@github.com>

On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support following new vector operators.
>> 
>> 
>>      . SUADD   : Saturating unsigned addition.
>>      . SADD    : Saturating signed addition. 
>>      . SUSUB   : Saturating unsigned subtraction.
>>      . SSUB    : Saturating signed subtraction.
>>      . UMAX    : Unsigned max
>>      . UMIN    : Unsigned min.
>>      
>> 
>> New vector operators are applicable to only integral types since their values wraparound in over/underflowing scenarios after setting appropriate status flags. For floating point types, as per IEEE 754 specs there are multiple schemes to handler underflow, one of them is gradual underflow which transitions the value to subnormal range. Similarly, overflow implicitly saturates the floating-point value to an Infinite value.
>> 
>> As the name suggests, these are saturating operations, i.e. the result of the computation is strictly capped by lower and upper bounds of the result type and is not wrapped around in underflowing or overflowing scenarios.
>> 
>> Summary of changes:
>> - Java side implementation of new vector operators.
>> - Add new scalar saturating APIs for each of the above saturating vector operator in corresponding primitive box classes, fallback implementation of vector operators is based over it.
>> - C2 compiler IR and inline expander changes.
>> - Optimized x86 backend implementation for new vector operators and their predicated counterparts.
>> - Extends existing VectorAPI Jtreg test suite to cover new operations.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> PS: Intrinsification and auto-vectorization of new core-lib API will be addressed separately in a follow-up patch.
>> 
>> [1] https://mail.openjdk.org/pipermail/panama-dev/2024-May/020408.html
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments resolutions.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6674:

> 6672:   // Res = Mask ? Zero : Res
> 6673:   evmovdqu(etype, ktmp, dst, dst, false, vlen_enc);
> 6674: }

We could directly do masked evpsubd/evpsubq here with merge as false.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6698:

> 6696:   // Unsigned values ranges comprise of only +ve numbers, thus there exist only an upper bound saturation.
> 6697:   // overflow = ((UMAX - MAX(SRC1 & SRC2)) <u MIN(SRC1, SRC2)) >>> 31 == 1
> 6698:   // Res = Signed Add INP1, INP2

The >>> 31 is not coded so comment could be improved to match the code.
Comment has SRC1/INP1 term mixed.
Also, could overflow not be implemented based on much simpler Java scalar algo:
Overflow = Res <u  (INP1 | INP2)
This is much straight forward, also evex supports unsigned comparison.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6716:

> 6714: //
> 6715: // Adaptation of unsigned addition overflow detection from hacker's delight
> 6716: // section 2-13 : overflow = ((a & b) | ((a | b) & ~(s))) >>> 31 == 1

Not clear what is s here?  I think it is s = a + b. Could you please update the comments to indicate this.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6738:

> 6736:                                                        XMMRegister xtmp1, XMMRegister xtmp2, XMMRegister xtmp3,
> 6737:                                                        XMMRegister xtmp4, int vlen_enc) {
> 6738:   // Res = Signed Add INP1, INP2

Wondering if we could implement overflow here also based on much simpler Java scalar algo:
Overflow = Res <u (INP1 | INP2) which is same as:
                   Res <s ((INP1 + MIN) | (INP2 + MIN))

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6745:

> 6743:   vpcmpeqd(xtmp3, xtmp3, xtmp3, vlen_enc);
> 6744:   // T2 = ~Res
> 6745:   vpxor(xtmp2, xtmp3, dst, vlen_enc);

Did you mean this to be T3 = ~Res

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6749:

> 6747:   vpor(xtmp2, xtmp2, src2, vlen_enc);
> 6748:   // Compute mask for muxing T1 with T3 using SRC1.
> 6749:   vpsign_extend_dq(etype, xtmp4, src1, vlen_enc);

I don't think we need to do the sign extension. The blend instruction uses most significant bit to do the blend.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6932:

> 6930: 
> 6931:   // Sign-extend to compute overflow detection mask.
> 6932:   vpsign_extend_dq(etype, xtmp3, xtmp2, vlen_enc);

Sign extend to lower bits not needed as blend uses msbit only.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 6939:

> 6937: 
> 6938:   // Compose saturating min/max vector using first input polarity mask.
> 6939:   vpsign_extend_dq(etype, xtmp4, src1, vlen_enc);

Sign extend to lower bits not needed as blend uses msbit only.

src/hotspot/cpu/x86/x86.ad line 10656:

> 10654:   match(Set dst (SaturatingSubVI src1 src2));
> 10655:   match(Set dst (SaturatingSubVL src1 src2));
> 10656:   effect(TEMP ktmp);

This needs TEMP dst as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737116841
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737272705
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737306541
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737307396
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737325898
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737338765
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737467234
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737467902
PR Review Comment: https://git.openjdk.org/jdk/pull/20507#discussion_r1737489758

From dholmes at openjdk.org  Fri Aug 30 00:38:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Aug 2024 00:38:19 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
Message-ID: <u-KZrR9alcIeU_f3C7xq9gUAxxM49Jnvz_sXcNtrg5E=.9ff9b72e-bdfa-4acd-a0f9-f9d5c1b6177f@github.com>

On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

Looks good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20516#pullrequestreview-2270696172

From swen at openjdk.org  Fri Aug 30 00:55:42 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 00:55:42 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo
Message-ID: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>

Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

-------------

Commit messages:
 - bug fix
 - optimize Utf8EntryImpl#writeTo

Changes: https://git.openjdk.org/jdk/pull/20772/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339290
  Stats: 70 lines in 5 files changed: 32 ins; 1 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

PR: https://git.openjdk.org/jdk/pull/20772

From swen at openjdk.org  Fri Aug 30 01:17:37 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 01:17:37 GMT
Subject: RFR: 8339241: Optimize LambdaForm#basicType(Class) [v2]
In-Reply-To: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
References: <4a10PtE0rNPPNme-JaP2lf2YfEdK7IOYyJOnGPxNDUs=.9dea6ea5-191d-488d-ad7b-99145123db99@github.com>
Message-ID: <BG-Lhrt-fFWDcAESpuKKyK1GGXeE7faryGUbeg6_jTw=.2847a896-4b52-47a0-86fc-af0c79a826f5@github.com>

> A small optimization to simplify the implementation logic of LambdaForm$BasicType#basicType method can reduce the call stack and reduce the overall bytecode size.
> 
> Below is the compiler log
> 
> * baseline
> 
>  @ 1   java.lang.invoke.LambdaForm$BasicType::basicType (8 bytes)   inline
>    @ 1   sun.invoke.util.Wrapper::basicTypeChar (18 bytes)   inline
>      @ 1   java.lang.Class::isPrimitive (0 bytes)   intrinsic
>      @ 11   sun.invoke.util.Wrapper::forPrimitiveType (122 bytes)   failed to inline: callee is too large
>      @ 14   sun.invoke.util.Wrapper::basicTypeChar (5 bytes)   inline
> 
> 
> * current
> 
> java.lang.invoke.LambdaForm$BasicType::basicType (87 bytes)   failed to inline: callee is too large

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Suggestions from @cl4es

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20759/files
  - new: https://git.openjdk.org/jdk/pull/20759/files/5ac70bda..bd109c3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20759&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20759&range=00-01

  Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20759.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20759/head:pull/20759

PR: https://git.openjdk.org/jdk/pull/20759

From duke at openjdk.org  Fri Aug 30 02:00:31 2024
From: duke at openjdk.org (duke)
Date: Fri, 30 Aug 2024 02:00:31 GMT
Subject: Withdrawn: 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: <SXmg-2wjpNL4ARmyh_bYmdaoDIqEnnL7uefzU2J0dQs=.59c8d873-acb7-44bb-ba2a-507f1954a583@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.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19281

From dholmes at openjdk.org  Fri Aug 30 02:13:57 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Aug 2024 02:13:57 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths
Message-ID: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>

This is the implementation of a new method added to the JNI specification.

>From the CSR request:

The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.

**The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.

Solution

Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.

---

We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni

There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.

Testing:
 - new test added
 - tiers 1-3 sanity

Thanks

-------------

Commit messages:
 - Test adjustments
 - 8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths
 - Merge
 - Initial commit before splitting out UTF8 changes

Changes: https://git.openjdk.org/jdk/pull/20784/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328877
  Stats: 203 lines in 7 files changed: 180 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/20784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20784/head:pull/20784

PR: https://git.openjdk.org/jdk/pull/20784

From liach at openjdk.org  Fri Aug 30 02:23:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 02:23:22 GMT
Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API
 [v2]
In-Reply-To: <KNW3RT0O2GNm36Gx8XkpAjI4vUtbBI1WqyDafW9gUSk=.bdf41809-790f-41ad-9f0c-25259ba1e18f@github.com>
References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com>
 <KNW3RT0O2GNm36Gx8XkpAjI4vUtbBI1WqyDafW9gUSk=.bdf41809-790f-41ad-9f0c-25259ba1e18f@github.com>
Message-ID: <_r8pj1DMNQ9Q6-OwMNofQdLBs0sdciSKo6aHT2sNEr4=.4082b3bc-5691-4121-993e-30b0e67b96c6@github.com>

On Thu, 6 Jun 2024 18:48:58 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.
>
> 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

This is becoming more necessary as valhalla brings changes to signature format.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-2319704590

From alanb at openjdk.org  Fri Aug 30 04:40:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 04:40:20 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

I wonder if there should be JBS issues for the specific source files/warnings so they can be looked at more closely (or maybe you've looked at them all already). Just wondering about the maintainability of DISABLED_WARNINGS_xxx values that list specific files as I assume they can bit rot quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320021124

From liach at openjdk.org  Fri Aug 30 04:42:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 04:42:20 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <xvwI863x52rdhIeIMJMWvCLskxY2W9FBizvYO2D7c8Y=.22f86b49-0010-47eb-b72e-a2676782fa53@github.com>

On Wed, 28 Aug 2024 13:12:35 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

@cl4es Observed that `slotSize` will only get a `CD_void` at method return type; so we can make the non-return-type (so field type and method parameter type) usages of `slotSize` to `isDoubleSlot() ? 2 : 1`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20747#issuecomment-2320023615

From liach at openjdk.org  Fri Aug 30 04:45:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 04:45:21 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <F4uAY9VOPLL8dMMyNJOsG8QX-GopZ2hrOP3T2EqQGnI=.2ec28f7e-972b-4ca4-9daa-c5656cd127aa@github.com>

On Thu, 29 Aug 2024 14:38:20 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 394:

> 392:     void inflateBytesToChars(byte[] src, int srcOff, char[] dst, int dstOff, int len);
> 393: 
> 394:     boolean hasNegativeOrZeros(String s);

Can you add some javadoc? All other methods here has javadoc for usage notes.

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 441:

> 439:                 }
> 440:                 else {
> 441:                     int charLength = stringValue.length();

In the slow loop, you can remove everything before the `else` - we don't really need that optimistic writing any more

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1737913601
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1737912744

From kbarrett at openjdk.org  Fri Aug 30 05:09:18 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Aug 2024 05:09:18 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
 <1lG4XEx1lF8Hu6csMsC9jNvDImrf9Pd5_xblOGlOyh4=.26a4c1cc-cc26-4581-8236-107ec28fe840@github.com>
Message-ID: <ncITSE1Vu3Ct9KiNcU2z19oYGsrapHuPSIfvibE1NJ8=.080efae6-8a96-4da2-a273-c41ba706f887@github.com>

On Fri, 30 Aug 2024 04:37:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if there should be JBS issues for the specific source files/warnings so they can be looked at more closely (or maybe you've looked at them all already). Just wondering about the maintainability of DISABLED_WARNINGS_xxx values that list specific files as I assume they can bit rot quickly.

The idea, from the build component POV, is that teams responsible for the various parts of the code where warnings
are being suppressed are responsible for filing issues to address them and scheduling the work to do so.  Different
teams have different approaches to backlog issues, how they prioritize them, and whether they keep them open or
close as WNF because they don't see getting to them for a long time, if ever.  I personally dislike the last approach,
but it's not under my control.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320065831

From swen at openjdk.org  Fri Aug 30 05:13:33 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 05:13:33 GMT
Subject: RFR: 8339168: Optimize ClassFile Util slotSize [v2]
In-Reply-To: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
References: <aarhhZEHsu27Zt4wxabjME92z_EPSZukHTtdDR_Ahxo=.00eadd4e-88e6-4d2a-b2c9-6e6ffe84f05f@github.com>
Message-ID: <sRGOv3RPJ1qk5XBxS0cpTvaNZILptYxP_wrG4zmlyqs=.aa05bdab-a80a-4371-95c7-2dba8c15c415@github.com>

> A small optimization to improve the performance of jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Suggestions from @cl4es

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20747/files
  - new: https://git.openjdk.org/jdk/pull/20747/files/3c58fab7..a0aa9eac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20747&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20747&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20747/head:pull/20747

PR: https://git.openjdk.org/jdk/pull/20747

From cjplummer at openjdk.org  Fri Aug 30 05:14:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 Aug 2024 05:14:23 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths
In-Reply-To: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
Message-ID: <qii8Y2zd_o1GUzZ4UuJIGn1yDK8RIIhaSzbxcw_GKZ8=.17a77764-ab3f-4491-8b6d-35166e8b415e@github.com>

On Fri, 30 Aug 2024 02:07:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This is the implementation of a new method added to the JNI specification.
> 
> From the CSR request:
> 
> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
> 
> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
> 
> Solution
> 
> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
> 
> ---
> 
> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
> 
> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
> 
> Testing:
>  - new test added
>  - tiers 1-3 sanity
> 
> Thanks

test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java line 27:

> 25:  * @bug 8328877
> 26:  * @summary Test warning for GetStringUTFLength and functionality of GetStringUTFLengthAsLong
> 27:  * @library /test/lib

Shouldn't this test have:

`@requires vm.bits == 64
`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20784#discussion_r1737942541

From dholmes at openjdk.org  Fri Aug 30 05:21:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Aug 2024 05:21:54 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
Message-ID: <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>

> This is the implementation of a new method added to the JNI specification.
> 
> From the CSR request:
> 
> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
> 
> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
> 
> Solution
> 
> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
> 
> ---
> 
> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
> 
> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
> 
> Testing:
>  - new test added
>  - tiers 1-3 sanity
> 
> Thanks

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Exclude test on 32-bit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20784/files
  - new: https://git.openjdk.org/jdk/pull/20784/files/9a8964b8..73174e64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20784&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20784&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20784.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20784/head:pull/20784

PR: https://git.openjdk.org/jdk/pull/20784

From dholmes at openjdk.org  Fri Aug 30 05:21:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Aug 2024 05:21:54 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <qii8Y2zd_o1GUzZ4UuJIGn1yDK8RIIhaSzbxcw_GKZ8=.17a77764-ab3f-4491-8b6d-35166e8b415e@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <qii8Y2zd_o1GUzZ4UuJIGn1yDK8RIIhaSzbxcw_GKZ8=.17a77764-ab3f-4491-8b6d-35166e8b415e@github.com>
Message-ID: <mQimwN-3XuPlDa5eEMY_4YXLR49hz3uo_uytquuWBeM=.28738905-59bc-4a5c-81a4-f9e46d807520@github.com>

On Fri, 30 Aug 2024 05:11:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exclude test on 32-bit
>
> test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java line 27:
> 
>> 25:  * @bug 8328877
>> 26:  * @summary Test warning for GetStringUTFLength and functionality of GetStringUTFLengthAsLong
>> 27:  * @library /test/lib
> 
> Shouldn't this test have:
> 
> `@requires vm.bits == 64
> `

Thanks for taking a look @plummercj . Yep I suppose it should.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20784#discussion_r1737947827

From swen at openjdk.org  Fri Aug 30 05:24:58 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 05:24:58 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v2]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <GpfamiXMNcfcDh-itQPCLzPlkAQ2DEo1iw5EVrsolmA=.abd330ca-6c76-4c49-b47e-f538b1ffd8ac@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

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/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/5a7b334a..28bd454c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

PR: https://git.openjdk.org/jdk/pull/20772

From swen at openjdk.org  Fri Aug 30 05:24:58 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 05:24:58 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v2]
In-Reply-To: <F4uAY9VOPLL8dMMyNJOsG8QX-GopZ2hrOP3T2EqQGnI=.2ec28f7e-972b-4ca4-9daa-c5656cd127aa@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <F4uAY9VOPLL8dMMyNJOsG8QX-GopZ2hrOP3T2EqQGnI=.2ec28f7e-972b-4ca4-9daa-c5656cd127aa@github.com>
Message-ID: <uDJUJvwUGMH53BgnXa-8e-h8o92852eQsvNolVZSshI=.149dc38d-7835-4009-b288-e16e32a094df@github.com>

On Fri, 30 Aug 2024 04:41:15 GMT, Chen Liang <liach 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/classfile/impl/AbstractPoolEntry.java line 441:
> 
>> 439:                 }
>> 440:                 else {
>> 441:                     int charLength = stringValue.length();
> 
> In the slow loop, you can remove everything before the `else` - we don't really need that optimistic writing any more

The code of the slow path is complex and difficult to understand. Can the simplified work be used as a follow-up action?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1737952771

From liach at openjdk.org  Fri Aug 30 05:33:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 05:33:18 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v2]
In-Reply-To: <uDJUJvwUGMH53BgnXa-8e-h8o92852eQsvNolVZSshI=.149dc38d-7835-4009-b288-e16e32a094df@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <F4uAY9VOPLL8dMMyNJOsG8QX-GopZ2hrOP3T2EqQGnI=.2ec28f7e-972b-4ca4-9daa-c5656cd127aa@github.com>
 <uDJUJvwUGMH53BgnXa-8e-h8o92852eQsvNolVZSshI=.149dc38d-7835-4009-b288-e16e32a094df@github.com>
Message-ID: <-GLIamN4smBxLH326yb2luzyJcxL2_SovxbSvnIH9xE=.1ccb7c33-a182-416e-b5e9-c4d0e2aaa6a0@github.com>

On Fri, 30 Aug 2024 05:21:46 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 441:
>> 
>>> 439:                 }
>>> 440:                 else {
>>> 441:                     int charLength = stringValue.length();
>> 
>> In the slow loop, you can remove everything before the `else` - we don't really need that optimistic writing any more
>
> The code of the slow path is complex and difficult to understand. Can the simplified work be used as a follow-up action?

Sure! Good to focus on the improvement here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1737960819

From eirbjo at openjdk.org  Fri Aug 30 06:24:22 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 30 Aug 2024 06:24:22 GMT
Subject: Integrated: 8339154: Cleanups and JUnit conversion of
 test/jdk/java/util/zip/Available.java
In-Reply-To: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
References: <SsWPrI3j0xfecrKxTh9D3V-vKVAcET4DYgAMSYlUivY=.87591274-4a45-47ec-aaa0-f22d40b2bd9d@github.com>
Message-ID: <TGCOfydU4JBvAgj3D_cnNSTDZM2FmRW4ASClwvM33uI=.1887eb36-7f4b-4dc6-8fea-92e23b4e69c9@github.com>

On Wed, 28 Aug 2024 11:12:42 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which addresses several issues with the `test/jdk/java/util/zip/Available.java` test:
> 
> * The test is converted to JUnit 5
> * The test now creates its own test vector programmatically instead of relying on a binary `input.jar` test vector 
> * Coverage is added for calling `available()` after calling `ZipInputStream.closeEntry`, as expected by the API specification for `ZipInputStream.available`
> * Coverage is added for calling `available()` on a closed `ZipInputStream`
> * Coverage is added for the unspecified, but long-standing behavior of `ZipFileInputStream.available()` (The InputStream returned for `STORED` entries)
> 
> Additionally, the test is split into multiple methods, adding javadoc comments for each of them.

This pull request has now been integrated.

Changeset: f927c121
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f927c1210ee0675bb1196572177ffb505826d57a
Stats:     119 lines in 1 file changed: 76 ins; 9 del; 34 mod

8339154: Cleanups and JUnit conversion of test/jdk/java/util/zip/Available.java

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/20744

From mbaesken at openjdk.org  Fri Aug 30 06:59:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Aug 2024 06:59:20 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <9zTorQdd0klZaGBwj0yVxOCzcMmD3jfhw2vYFWY1GlE=.c4ecaa23-9939-4a45-8aec-27295f503933@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

The test is still rather fast. If speed is a concern, we could use 12000 on the ppc64-platforms (and add a comment) and 2000 on the others.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20771#issuecomment-2320263456

From pminborg at openjdk.org  Fri Aug 30 08:59:54 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 30 Aug 2024 08:59:54 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v8]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <aSicnfKyF_T26Ck6inLZhywEqVI2tBVQWOlywc61sZY=.37a460a6-620a-4b39-a004-e0acbdd8e971@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Move logic to ScopedMemoryAccess for improved performance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/78eb92a6..fc0e1aee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=06-07

  Stats: 102 lines in 4 files changed: 58 ins; 25 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From pminborg at openjdk.org  Fri Aug 30 09:09:57 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 30 Aug 2024 09:09:57 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v9]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <xTJpycVnk3j5dFHiMrjdN_EQGXxbXoVVnY6gD-e68CE=.bf4d3fde-e3e1-41e5-964c-ef5a8bd791e0@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg 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/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/fc0e1aee..e3c0417b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From duke at openjdk.org  Fri Aug 30 09:28:20 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 30 Aug 2024 09:28:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v9]
In-Reply-To: <xTJpycVnk3j5dFHiMrjdN_EQGXxbXoVVnY6gD-e68CE=.bf4d3fde-e3e1-41e5-964c-ef5a8bd791e0@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <xTJpycVnk3j5dFHiMrjdN_EQGXxbXoVVnY6gD-e68CE=.bf4d3fde-e3e1-41e5-964c-ef5a8bd791e0@github.com>
Message-ID: <vDwzOBLzusTvJ9Tpw-rSllTozvG3fn6rZhele2eVVTo=.a5f3a766-7caa-4530-b854-e1cbf6b01e60@github.com>

On Fri, 30 Aug 2024 09:09:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Changes requested by franz1981 at github.com (no known OpenJDK username).

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 210:

> 208:                 // Handle smaller segments directly without transitioning to native code
> 209:                 final long u = Byte.toUnsignedLong(value);
> 210:                 final long longValue = u << 56 | u << 48 | u << 40 | u << 32 | u << 24 | u << 16 | u << 8 | u;

this can be `u * 0xFFFFFFFFFFFFL` if `value != 0` and just `0L` if not: not sure if fast(er), need to measure.

Most of the time filling is happy with 0 since zeroing is the most common case

-------------

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2271723714
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1738292680

From mdoerr at openjdk.org  Fri Aug 30 09:59:18 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 30 Aug 2024 09:59:18 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <BctyFjdGbZHSyTAx6vq8bofh44-HgNL697slE8ofhXI=.a868eeb1-aa15-4d5f-9e82-020c38dc7b6e@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20771#pullrequestreview-2271807783

From mcimadamore at openjdk.org  Fri Aug 30 10:05:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 10:05:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v9]
In-Reply-To: <xTJpycVnk3j5dFHiMrjdN_EQGXxbXoVVnY6gD-e68CE=.bf4d3fde-e3e1-41e5-964c-ef5a8bd791e0@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <xTJpycVnk3j5dFHiMrjdN_EQGXxbXoVVnY6gD-e68CE=.bf4d3fde-e3e1-41e5-964c-ef5a8bd791e0@github.com>
Message-ID: <LwmcBwWccl80NOYCS4xlG7nPVTFCGH8Vg5F4igwbvJc=.2c761de0-2307-4bd6-b0e0-a307ba75d9b7@github.com>

On Fri, 30 Aug 2024 09:09:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 200:

> 198: 
> 199:     @ForceInline @Scoped
> 200:     private void setMemoryInternal(AbstractMemorySegmentImpl segment, long length, byte value) {

All this logic should be in the memory segment impl class, and the calls to `UNSAFE` replaced with calls to `SCOPED_MEMORY_ACCESS`. This logic is complex for a scoped method, and you risk running into limitations of scoped methods (they cannot exceed 10 Java frames). In general, scoped methods are really meant to be wrappers around some JVM intrinsics.

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 206:

> 204:                 session.checkValidStateRaw();
> 205:             }
> 206:             // 0...0X...XXXX implies: 0 <= length < FILL_NATIVE_LIMIT

I would also recommend against "ultra" fine tuning and have limits that are different from platform to platform. It seems like we're using a different limit here because of https://bugs.openjdk.org/browse/JDK-8338975. But I'm not sure working around that is in the scope of the current PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1738351494
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1738354035

From alanb at openjdk.org  Fri Aug 30 10:07:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 10:07:23 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
Message-ID: <sTrTkqq0pYei2TvKybXAvMcxFs49UdBgRkzAZTpWR5g=.669af597-8982-4ea6-9a91-b58144656c44@github.com>

On Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a preparation for Hermetic Java, we need to have a way to look up during runtime if we are using a statically linked library or not.
>> 
>> This change will be the first step needed towards compiling the object files only once, and then link them into either dynamic or static libraries. (The only exception will be the linktype.c[pp] files, which needs to be compiled twice, once for the dynamic libraries and once for the static libraries.) Getting there will require further work though. 
>> 
>> This is part of the changes that make up the draft PR https://github.com/openjdk/jdk/pull/19478, which I have broken out.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update build to link properly

I think the approach is pragmatic and okay. I agree it looks a bit unusual to be testing the image type at runtime but it doesn't seem to be measurable and not a concern right now. In the future, I suspect we will have many places in the libraries that will need to test this at runtime for 30+ other reasons.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20666#pullrequestreview-2271829178

From mbaesken at openjdk.org  Fri Aug 30 10:21:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Aug 2024 10:21:23 GMT
Subject: Integrated: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <9kbcXFnBxYEjCYZSnrWbQwEBn1iCzmo11XXq1O_gW0E=.4dc47f8a-6940-45d4-bfc8-2762e2c75e42@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

This pull request has now been integrated.

Changeset: 92c4704e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92c4704edf75534b825765d156a7f70377ccb3bb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8339166: java/lang/String/concat/HiddenClassUnloading.java fails on AIX and Linux ppc64le after JDK-8336856

Reviewed-by: redestad, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/20771

From mbaesken at openjdk.org  Fri Aug 30 10:21:22 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Aug 2024 10:21:22 GMT
Subject: RFR: 8339166: java/lang/String/concat/HiddenClassUnloading.java
 fails on AIX and Linux ppc64le after JDK-8336856
In-Reply-To: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
References: <-6bqcIhtNrwutbb2qFiNwTE9bexH8qD_K32IjafxsoU=.258b96a2-0da6-4067-a9d8-7b48b45b5766@github.com>
Message-ID: <ILuBoj6q01uN-xRK1wdNNbS07sLaf9EImHlkqDon7T8=.0800435b-a43d-43fa-8299-7025e9ddb7aa@github.com>

On Thu, 29 Aug 2024 13:55:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We see HiddenClassUnloading.java failing on the ppc64 based platforms. On AIX it seems to fail always; Linux ppc64le sometimes.
> Failure output :
> java.lang.RuntimeException: unloadedClassCount is zero
> at HiddenClassUnloading.main(HiddenClassUnloading.java:66)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> Ergonomics sets on these platforms the heap to 32M (even with the -Xmx8M -Xms8M settings), see the Xlog UL output
> 
> 
> [0.045s][info ][gc,init ] Heap Min Capacity: 32M
> [0.045s][info ][gc,init ] Heap Initial Capacity: 32M
> [0.045s][info ][gc,init ] Heap Max Capacity: 32M
> 
> 
> So we need more iterations in the test to trigger the class unloading.

Hi Martin and Claes, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20771#issuecomment-2320759844

From eirbjo at openjdk.org  Fri Aug 30 10:31:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 30 Aug 2024 10:31:48 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics
In-Reply-To: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
Message-ID: <BGECb2-H0-iIkSjjSJ3G2USa6Ai6xP1rMav6lQWloXg=.b59b7e3f-e807-47a3-a2d9-4824b732de7d@github.com>

On Fri, 30 Aug 2024 07:27:11 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR with picks up on the excellent work done by @archiecobbs in #18385
> 
> The proposed changes aim to solve two issues with the current `java.util.zip.GZIPInputStream`:
> 
> *  The class parses multiple concatenated GZIP files as a single stream. This behavior is not documented in the API  specification.
> *  Any additional bytes following a trailer which do not form a valid header are discarded and the stream behaves as if the end of stream has been reached. This behavior is not documented in the API  specification.
> 
> Testing:
> 
> * A new test `GZIPInputStreamConcat` verifies the behaviors being specified in this PR 
> * A new test `GZIPInputStreamGzipCommand` verifies decompression of various GZIP files created using the `gzip` command.

@LanceAndersen @jaikiran 

I have updated the API documentation in this PR inspired by the following comment from @jaikiran in Archie's PR:

https://github.com/openjdk/jdk/pull/18385#issuecomment-2265378324

I aimed to keep this at a high level, avoiding any details of the GZIP file format and the parsing logic involved in the implementation:


 * <p>
 * The InputStream passed to the constructor of this class may represent a
 * single GZIP file or multiple consecutive GZIP files. When the end of a
 * GZIP file is immediately followed by a new GZIP file, this class continues
 * to decode compressed data into a single, concatenated stream of uncompressed
 * data. Otherwise, any additional trailing bytes following a GZIP file are
 * discarded as if the end of stream is reached.


What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2320776918

From eirbjo at openjdk.org  Fri Aug 30 10:31:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 30 Aug 2024 10:31:48 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated stream
 semantics
Message-ID: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>

Please review this PR with picks up on the excellent work done by @archiecobbs in #18385

The proposed changes aim to solve two issues with the current `java.util.zip.GZIPInputStream`:

*  The class parses multiple concatenated GZIP files as a single stream. This behavior is not documented in the API  specification.
*  Any additional bytes following a trailer which do not form a valid header are discarded and the stream behaves as if the end of stream has been reached. This behavior is not documented in the API  specification.

Testing:

* A new test `GZIPInputStreamConcat` verifies the behaviors being specified in this PR 
* A new test `GZIPInputStreamGzipCommand` verifies decompression of various GZIP files created using the `gzip` command.

-------------

Commit messages:
 - Adjusting line breaks
 - Reduce the focus on technical details of the GZIP file format
 - Keep references to header and trailer in the order of appearance in the file format
 - Various cleanups in the test code
 - Shorten the note explaining concatenated GZIP stream behavior
 - Merge branch 'master' into JDK-8322256
 - Shorten the description of concatenation behavior per review comments.
 - Revert all functional changes, leaving only tests & Javadoc.
 - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java).
 - Add GZIP input test for various gzip(1) command outputs.
 - ... and 16 more: https://git.openjdk.org/jdk/compare/5671f836...fc2b57e6

Changes: https://git.openjdk.org/jdk/pull/20787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322256
  Stats: 306 lines in 3 files changed: 306 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20787/head:pull/20787

PR: https://git.openjdk.org/jdk/pull/20787

From eirbjo at openjdk.org  Fri Aug 30 10:50:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 30 Aug 2024 10:50:37 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
Message-ID: <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>

> Please review this PR with picks up on the excellent work done by @archiecobbs in #18385
> 
> The proposed changes aim to solve two issues with the current `java.util.zip.GZIPInputStream`:
> 
> *  The class parses multiple concatenated GZIP files as a single stream. This behavior is not documented in the API  specification.
> *  Any additional bytes following a trailer which do not form a valid header are discarded and the stream behaves as if the end of stream has been reached. This behavior is not documented in the API  specification.
> 
> Testing:
> 
> * A new test `GZIPInputStreamConcat` verifies the behaviors being specified in this PR 
> * A new test `GZIPInputStreamGzipCommand` verifies decompression of various GZIP files created using the `gzip` command.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Use {@code InputStream}

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20787/files
  - new: https://git.openjdk.org/jdk/pull/20787/files/fc2b57e6..a4ce2b83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20787&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20787&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20787/head:pull/20787

PR: https://git.openjdk.org/jdk/pull/20787

From pminborg at openjdk.org  Fri Aug 30 10:51:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 30 Aug 2024 10:51:59 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
Message-ID: <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>

> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
> 
> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
> 
> Here is how the `MemorySegment::fill` performance is improved by this PR:
> 
> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
> 
> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
> 
> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Revert copyright year
 - Move logic back to AMSI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20712/files
  - new: https://git.openjdk.org/jdk/pull/20712/files/e3c0417b..5c2ce6ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20712&range=08-09

  Stats: 82 lines in 2 files changed: 40 ins; 36 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20712/head:pull/20712

PR: https://git.openjdk.org/jdk/pull/20712

From ihse at openjdk.org  Fri Aug 30 10:54:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 10:54:20 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
Message-ID: <eQv90nmAArKzh8kjaZ1oGg5jInJTI6J7jxJ8sjIxEXI=.a8ba6456-c192-44eb-8bad-f6ee245239e8@github.com>

On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Also update build to link properly
>
> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.

@dholmes-ora This PR now has three reviewers approving it. You say you are "not a fan". Does this mean you want to veto this change? Or can you be willing to accept it, even if you do not like it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2320832777

From mbaesken at openjdk.org  Fri Aug 30 11:05:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Aug 2024 11:05:20 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
Message-ID: <SGwJOZu_Bvq1HlC901vsV8CEE9gJaB6cmXjWPHlKzMM=.61e99f79-35d1-46c5-984e-45ac369aa788@github.com>

On Wed, 28 Aug 2024 16:13:07 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 10 additional commits since the last revision:
> 
>  - Add root check for SystemdMemoryAwarenessTest.java
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

src/hotspot/share/prims/whitebox.cpp line 2507:

> 2505: WB_END
> 2506: 
> 2507: // Physical cpus of the host machine (including containers), Linux only.

Isn't the comment a bit misleading ?  From what I see , ` os::Linux::active_processor_count()` can use various mechanisms to get number of processor info, if it uses https://linux.die.net/man/2/sched_getaffinity it gives the 'set of CPUs on which it is eligible to run.'   That might be different from what the host has.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1738427318

From mbaesken at openjdk.org  Fri Aug 30 11:08:23 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Aug 2024 11:08:23 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
Message-ID: <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>

On Wed, 28 Aug 2024 16:13:07 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 10 additional commits since the last revision:
> 
>  - Add root check for SystemdMemoryAwarenessTest.java
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Add Whitebox check for host cpu
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>  - Fix comments
>  - 8333446: Add tests for hierarchical container support

Looking through the coding it looks more or less okay to me; but if you really need to run it under user 'root'  I think we will not have so much use for this in our test environments  because we use other test users.
Not saying that this is a very bad thing,  maybe it is just the way it is, that 'root' is needed ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2320865740

From alanb at openjdk.org  Fri Aug 30 11:10:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 11:10:23 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
 <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
Message-ID: <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>

On Fri, 30 Aug 2024 10:50:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR with picks up on the excellent work done by @archiecobbs in #18385
>> 
>> The proposed changes aim to solve two issues with the current `java.util.zip.GZIPInputStream`:
>> 
>> *  The class parses multiple concatenated GZIP files as a single stream. This behavior is not documented in the API  specification.
>> *  Any additional bytes following a trailer which do not form a valid header are discarded and the stream behaves as if the end of stream has been reached. This behavior is not documented in the API  specification.
>> 
>> Testing:
>> 
>> * A new test `GZIPInputStreamConcat` verifies the behaviors being specified in this PR 
>> * A new test `GZIPInputStreamGzipCommand` verifies decompression of various GZIP files created using the `gzip` command.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use {@code InputStream}

I wonder if we can dig up the discussion on JDK-4691425. I can't find the CSR (or "CCC" at the time) that would have captured the reasoning for supporting this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2320873616

From lancea at openjdk.org  Fri Aug 30 11:21:18 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Aug 2024 11:21:18 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
 <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
 <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>
Message-ID: <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>

On Fri, 30 Aug 2024 11:07:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wonder if we can dig up the discussion on JDK-4691425. I can't find the CSR (or "CCC" at the time) that would have captured the reasoning for supporting this.

The gnu.org docs cover this(concatenating gzip files)  as part of its [advanced usage of gzip](https://github.com/openjdk/jdk/pull/20787#issuecomment-2320873616), so I don'r think we need to do any more archeology

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2320900471

From ihse at openjdk.org  Fri Aug 30 11:35:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 11:35:51 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings [v2]
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <b8OW9mnHcvmbpUGxL2Lz2OH598ndK_MUnup0LOIcDO8=.0918f694-df17-40e2-92db-c064d5329f91@github.com>

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into finegranular-clang-unused
 - 8339156: Use more fine-granular clang unused warnings

-------------

Changes: https://git.openjdk.org/jdk/pull/20770/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20770&range=01
  Stats: 60 lines in 16 files changed: 42 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20770.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20770/head:pull/20770

PR: https://git.openjdk.org/jdk/pull/20770

From ihse at openjdk.org  Fri Aug 30 11:35:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 11:35:51 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <pMZLlp2I8S-tuWZvmM9vE-WienVIK5IJLN7-gOCm6ec=.0de975f3-bb99-444e-a0fb-2e37c82a5c7d@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

As Kim says. I can pave the way for the component teams to fix the warnings as smoothly as possible, but I cannot and will not try to fix the actual issue. (When I embarked on the journey to try and improve the warning situation, I na?vely tried to fix some "simple" warnings, thinking that would be easier than to turn off the warning... Heh! Just let me say, I'm not doing that again.)

I used to file a JBS issue whenever I disabled a warning on a component, but they were mostly just ignored or closed after several years without any action, so I got tired of doing all the paperwork for nothing.

Maybe we can try to raise some general awareness that teams should check up what warnings they have disabled and see if they can fix them? I know some teams, like client-libs, have tons of warnings, are well aware of the fact, but do not have the manpower to be able to address them. Other teams might just be oblivious to the situations, however, but I have no way to tell which way it is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20770#issuecomment-2320924437

From asotona at openjdk.org  Fri Aug 30 11:37:19 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Aug 2024 11:37:19 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, 
 ConstantDesc) [v2]
In-Reply-To: <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
 <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
Message-ID: <W9WioGJVVrEp0vybbm-IC8ESis3YDDulJyEPSMgMlcI=.8e998074-e16b-4175-a2ed-d7b7ad47906b@github.com>

On Thu, 29 Aug 2024 21:46:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and confusing. Users should almost always use `loadConstant(ConstantDesc)` for optimized instructions, or use specific factories `iconst_0` etc. or `bipush` with arguments or `LoadConstantInstruction.of` if they want to specify the exact type of LDC opcode.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move bipush and sipush fix from Opcode cleanup to this patch

Looks good to me.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20779#pullrequestreview-2272018426

From lancea at openjdk.org  Fri Aug 30 11:41:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Aug 2024 11:41:20 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
 <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
 <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>
 <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>
Message-ID: <KnobgGAOTTHZyEdARZqz_r7Wr5TbfyZmK9K43uvT4uI=.926ad04e-ff06-4eda-926e-b9db06df6074@github.com>

On Fri, 30 Aug 2024 11:18:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I wonder if we can dig up the discussion on JDK-4691425. I can't find the CSR (or "CCC" at the time) that would have captured the reasoning for supporting this.
>
>> I wonder if we can dig up the discussion on JDK-4691425. I can't find the CSR (or "CCC" at the time) that would have captured the reasoning for supporting this.
> 
> The gnu.org docs cover this(concatenating gzip files)  as part of its [advanced usage of gzip](https://github.com/openjdk/jdk/pull/20787#issuecomment-2320873616), so I don'r think we need to do any more archeology

> @LanceAndersen @jaikiran
> 
> I have updated the API documentation in this PR inspired by the following comment from @jaikiran in Archie's PR:
> 
> [#18385 (comment)](https://github.com/openjdk/jdk/pull/18385#issuecomment-2265378324)
> 
> I aimed to keep this at a high level, avoiding any details of the GZIP file format and the parsing logic involved in the implementation:
> 
> ```
>  * <p>
>  * The {@code InputStream} passed to the constructor of this class may represent
>  * a single GZIP file or multiple consecutive GZIP files. When the end of a
>  * GZIP file is immediately followed by a new GZIP file, this class continues
>  * to decode compressed data into a single, concatenated stream of uncompressed
>  * data. Otherwise, any additional trailing bytes following a GZIP file are
>  * discarded as if the end of stream is reached
> ```
> 
> I also made a pass over the tests with my suggested improvement from the previous PR.
> 
> What do you think?

I think we are closer and this reads much better.,  I still think we can add a mention the GZIP header/trailer similar to  what we did for ZipInputStream:

> The [getNextEntry()](https://download.java.net/java/early_access/jdk23/docs/api/java.base/java/util/zip/ZipInputStream.html#getNextEntry()) method is used to read the next ZIP file entry (Local file (LOC) header record in the ZIP format)

Thank you for picking this up.  Will look at the test a bit later this morning my time after some coffee :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2320951192

From sgehwolf at openjdk.org  Fri Aug 30 11:43:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Aug 2024 11:43:21 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <SGwJOZu_Bvq1HlC901vsV8CEE9gJaB6cmXjWPHlKzMM=.61e99f79-35d1-46c5-984e-45ac369aa788@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <SGwJOZu_Bvq1HlC901vsV8CEE9gJaB6cmXjWPHlKzMM=.61e99f79-35d1-46c5-984e-45ac369aa788@github.com>
Message-ID: <gEBipl5nJtEKXA-iH9LTpMhOxY-yI2Ds4mOal695hPw=.7be47334-df52-4132-8258-dc0c2a2383b2@github.com>

On Fri, 30 Aug 2024 11:02:52 GMT, Matthias Baesken <mbaesken 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 10 additional commits since the last revision:
>> 
>>  - Add root check for SystemdMemoryAwarenessTest.java
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Add Whitebox check for host cpu
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Merge branch 'master' into jdk-8333446-systemd-slice-tests
>>  - Fix comments
>>  - 8333446: Add tests for hierarchical container support
>
> src/hotspot/share/prims/whitebox.cpp line 2507:
> 
>> 2505: WB_END
>> 2506: 
>> 2507: // Physical cpus of the host machine (including containers), Linux only.
> 
> Isn't the comment a bit misleading ?  From what I see , ` os::Linux::active_processor_count()` can use various mechanisms to get number of processor info, if it uses https://linux.die.net/man/2/sched_getaffinity it gives the 'set of CPUs on which it is eligible to run.'   That might be different from what the host has.

Yes. See #20768 for an attempt to unify it. I'll change the comment with the update that I have for nested hierarchies. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1738475745

From alanb at openjdk.org  Fri Aug 30 11:46:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 11:46:19 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
 <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
 <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>
 <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>
Message-ID: <5TIVJ2h7GO_nP_oiO2YbuDe_EG4NdzmaQQzA84vQRPE=.745c2d4f-a31f-45b3-b4c0-fb88e6791a34@github.com>

On Fri, 30 Aug 2024 11:18:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> The gnu.org docs cover this(concatenating gzip files) as part of its [advanced usage of gzip](https://github.com/openjdk/jdk/pull/20787#issuecomment-2320873616), so I don'r think we need to do any more archeology

Okay, but just very surprising that support was added in JDK 7 without changes to the API docs or other documentation (from a quick search).

If we are retrofitting the APIs docs then I think treat "GZIP" as a file format. It may require adding overrides so there is a place to document the behavior when reading an entry roll over into the next stream.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2320965700

From sgehwolf at openjdk.org  Fri Aug 30 11:49:18 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Aug 2024 11:49:18 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
Message-ID: <VNuBcgbEVT92Cb5be_P1zpTigy4PS0iDGVyqFnQRiWw=.ffb0a776-a449-4a35-9590-1e53c221a9de@github.com>

On Fri, 30 Aug 2024 11:05:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Not saying that this is a very bad thing, maybe it is just the way it is, that 'root' is needed ?

I'll do some more research whether or not that is a hard requirement. Thanks for the comments so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2320970507

From asotona at openjdk.org  Fri Aug 30 11:53:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Aug 2024 11:53:17 GMT
Subject: RFR: 8339131: Remove rarely-used accessor methods from Opcode
In-Reply-To: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
References: <XKElW9KQVitWClUcEohSpO89IHOkYU9UrfLyOu6kS64=.c5308076-6c0c-4714-a396-7d3c4f0e5307@github.com>
Message-ID: <I9Dmx02d9e6jjn2owzp8kX9oI_pxtHB51WQiXrKQPaY=.5b8a3b83-db44-45a3-b485-c32b34750417@github.com>

On Wed, 28 Aug 2024 22:41:59 GMT, Chen Liang <liach at openjdk.org> wrote:

> In offline discussion, we agreed that current fields of `Opcode` violate data oriented design to a large extent. The attributes not generic to all opcode are removed.
> 
> Up for preliminary review; needs to be reworked for #20737.

Looks good to me. 
I'm surprised by the minimal impact of the removal.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20757#pullrequestreview-2272049037

From pminborg at openjdk.org  Fri Aug 30 12:18:20 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 30 Aug 2024 12:18:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
 <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
Message-ID: <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>

On Wed, 28 Aug 2024 15:32:40 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>>> How fast do we need to be here given we are measuring in a few nanoseconds per operation?
>>> 
>>> What if the goal is not to regress from say explicitly filling in a small sized segment or a comparable array (e.g., < 8 bytes) then maybe a loop suffices and the code is simple?
>> 
>> Fair question. I have another version (called "patch bits" below) that is based on bit logic (first doing int ops, then short and lastly byte, similar to `ArraySupport::vectorizedMismatch`). This has slightly worse performance but is more scalable and perhaps simpler.
>> 
>> ![image](https://github.com/user-attachments/assets/292c75aa-0df8-4bb7-b45f-426d0f8470d9)
>
> @minborg Hi! I didn't checked the numbers with the benchmark I've written at https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is meant to stress the branch predictor (without enough `samples` i.e. past 128K on my machine) - can you give it a shot with M1 ? ?

@franz1981 Here is what I get if I run your performance test on my M1 Mac (unfortunately no -perf data):


Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score       Error  Units
TestBranchFill.heap_segment_fill       1024      false  avgt   30     3695.815 ?    24.615  ns/op
TestBranchFill.heap_segment_fill       1024       true  avgt   30     3938.582 ?   124.510  ns/op
TestBranchFill.heap_segment_fill     128000      false  avgt   30   420845.301 ?  1605.080  ns/op
TestBranchFill.heap_segment_fill     128000       true  avgt   30  1778362.506 ? 39250.756  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2321048180

From swen at openjdk.org  Fri Aug 30 12:20:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 12:20:31 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer
Message-ID: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>

A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

-------------

Commit messages:
 - Suggestions from @cl4es
 - fix build error
 - remove BufWriter#patchInt
 - optimize BufWriterImpl#patchInt

Changes: https://git.openjdk.org/jdk/pull/20780/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20780&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339317
  Stats: 48 lines in 8 files changed: 28 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20780.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20780/head:pull/20780

PR: https://git.openjdk.org/jdk/pull/20780

From liach at openjdk.org  Fri Aug 30 12:20:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 12:20:31 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <UMsdrjFJL-7IEh91Bs0EpcAG6BZK4dIavpHEGTDHK4E=.05cb0872-2324-4bcd-96a4-5f25eb5ea487@github.com>

On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

`patchInt` isn't that frequently used in workloads. I doubt this specialized version provides much value; maybe @cl4es can evaluate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20780#issuecomment-2319108184

From swen at openjdk.org  Fri Aug 30 12:20:31 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 12:20:31 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <JF-wjBfD4FS8TOTUlS1A_ijdMCqv_1RSCI-yC7tBde0=.075f9170-41f4-44b8-aaf4-4b716065f4e9@github.com>

On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

I debugged the code and watched the compile log, patchInt calls are frequent. For example, the following call stack:


patchInt:164, BufWriterImpl (jdk.internal.classfile.impl)
writeTo:856, UnboundAttribute$AdHocAttribute (jdk.internal.classfile.impl)
writeAttribute:233, Util (jdk.internal.classfile.impl)
writeAttributes:240, Util (jdk.internal.classfile.impl)
writeTo:53, AttributeHolder (jdk.internal.classfile.impl)
writeTo:153, DirectMethodBuilder (jdk.internal.classfile.impl)
writeList:247, Util (jdk.internal.classfile.impl)
build:187, DirectClassBuilder (jdk.internal.classfile.impl)
build:125, ClassFileImpl (jdk.internal.classfile.impl)
build:332, ClassFile (java.lang.classfile)
classFileSetup:261, InvokerBytecodeGenerator (java.lang.invoke)
generateCustomizedCodeBytes:540, InvokerBytecodeGenerator (java.lang.invoke)
generateCustomizedCode:518, InvokerBytecodeGenerator (java.lang.invoke)
compileToBytecode:845, LambdaForm (java.lang.invoke)
makePreparedLambdaForm:302, DirectMethodHandle (java.lang.invoke)
preparedLambdaForm:230, DirectMethodHandle (java.lang.invoke)
preparedLambdaForm:215, DirectMethodHandle (java.lang.invoke)
preparedLambdaForm:224, DirectMethodHandle (java.lang.invoke)
make:106, DirectMethodHandle (java.lang.invoke)
make:127, DirectMethodHandle (java.lang.invoke)
make:132, DirectMethodHandle (java.lang.invoke)
basicInvoker:96, Invokers (java.lang.invoke)
<init>:1102, LambdaForm$NamedFunction (java.lang.invoke)
<init>:1354, LambdaForm$Name (java.lang.invoke)
makeReinvokerForm:160, DelegatingMethodHandle (java.lang.invoke)
makeReinvokerForm:120, DelegatingMethodHandle (java.lang.invoke)
chooseDelegatingForm:112, DelegatingMethodHandle (java.lang.invoke)
<init>:50, DelegatingMethodHandle (java.lang.invoke)
<init>:465, MethodHandleImpl$AsVarargsCollector (java.lang.invoke)
<init>:462, MethodHandleImpl$AsVarargsCollector (java.lang.invoke)
makeVarargsCollector:453, MethodHandleImpl (java.lang.invoke)
asVarargsCollector:1516, MethodHandle (java.lang.invoke)
withVarargs:1201, MethodHandle (java.lang.invoke)
setVarargs:1720, MethodHandle (java.lang.invoke)
getDirectMethodCommon:4122, MethodHandles$Lookup (java.lang.invoke)
getDirectMethodNoSecurityManager:4065, MethodHandles$Lookup (java.lang.invoke)
getDirectMethodForConstant:4314, MethodHandles$Lookup (java.lang.invoke)
linkMethodHandleConstant:4262, MethodHandles$Lookup (java.lang.invoke)
linkMethodHandleConstant:628, MethodHandleNatives (java.lang.invoke)
concat6String:167, StringConcat (jmh)
concat6String:174, StringConcatTest (jmh)
main:239, StringConcatTest (jmh)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20780#issuecomment-2319149595

From redestad at openjdk.org  Fri Aug 30 12:20:32 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 30 Aug 2024 12:20:32 GMT
Subject: RFR: 8339317: Optimize ClassFile writeBuffer
In-Reply-To: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
References: <R-jGlqYYVojR5Jx00tDa67D3M5XltxzEHq-rK2HDbuk=.89819f1b-1a47-46e3-a839-dea5e5bc32f1@github.com>
Message-ID: <lxuerDnjYR7JXy2zhUSB24Yrix4rn17D1wFoUTS4LCM=.a557a2b7-439b-4c1e-baa7-94bed924b9bc@github.com>

On Thu, 29 Aug 2024 21:49:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small optimization, optimize the BufferWriter implementation and use of ClassFile, provide faster patchInt and skip

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractAttributeMapper.java line 68:

> 66:         BufWriterImpl buf = (BufWriterImpl) writer;
> 67:         buf.writeIndex(buf.constantPool().utf8Entry(name));
> 68:         buf.writeInt(0);

Since this is the int we're patching later it might be reasonable to have a buf.skip(int) method which just increases buf.offset. Applicable at least here and in `UnboundAttribute::writeTo`

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 476:

> 474:                     bytecodesBufWriter.patchU2(dl.labelPc, branchOffset);
> 475:                 } else {
> 476:                     bytecodesBufWriter.patchInt(dl.labelPc, branchOffset);

Should assert or test that `dl.size == 4` here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1737537176
PR Review Comment: https://git.openjdk.org/jdk/pull/20780#discussion_r1737532837

From swen at openjdk.org  Fri Aug 30 12:30:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 12:30:46 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate
Message-ID: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>

A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

-------------

Commit messages:
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - Suggestions from @liach
 - fix build error
 - optimize Utf8EntryImpl inflate

Changes: https://git.openjdk.org/jdk/pull/20767/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20767&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339320
  Stats: 75 lines in 1 file changed: 22 ins; 20 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/20767.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20767/head:pull/20767

PR: https://git.openjdk.org/jdk/pull/20767

From liach at openjdk.org  Fri Aug 30 12:30:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 12:30:46 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate
In-Reply-To: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
Message-ID: <VQ7Ng5lasPoc1bcKntnkNzBzwpquCYtWf5n5cVZW0AA=.bd4ca92c-c6ca-41cc-9313-6d1fdfbeb4ee@github.com>

On Thu, 29 Aug 2024 11:44:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

Java's UTF8 entry cannot use the 4-byte format in regular UTF8. You can check out how DataInputStream read UTF8 strings instead.

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 402:

> 400:                 return JLA.regionMatches(s, rawBytes, LATIN1, offset, charLen);
> 401:             } else {
> 402:                 return JLA.regionMatches(s, chars, UTF16, 0, charLen);

I think instead of making our internal representation complex to speed up this regionMatches, we should ask the VM side if they can provide a Java API for ArraysSupport.mismatch that operates on a byte array and a char array.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20767#pullrequestreview-2268548164
PR Review Comment: https://git.openjdk.org/jdk/pull/20767#discussion_r1736590160

From duke at openjdk.org  Fri Aug 30 12:30:46 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 30 Aug 2024 12:30:46 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate
In-Reply-To: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
Message-ID: <kanVtGYMJIaBUquLj7MuJZrfz7fmt0dLGfnx0uwsVw0=.9f30923c-dd54-43fc-a13f-0f80144a9dcc@github.com>

On Thu, 29 Aug 2024 11:44:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR

Typo (`HCAR`???`CHAR`):

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 235:

> 233:                 state = State.BYTE;
> 234:             } else {
> 235:                 inflateHCAR(singleBytes, hash);

Suggestion:

                inflateCHAR(singleBytes, hash);

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 239:

> 237:         }
> 238: 
> 239:         private void inflateHCAR(int singleBytes, int hash) {

Suggestion:

        private void inflateCHAR(int singleBytes, int hash) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/20767#pullrequestreview-2270677504
PR Review Comment: https://git.openjdk.org/jdk/pull/20767#discussion_r1737542852
PR Review Comment: https://git.openjdk.org/jdk/pull/20767#discussion_r1737543008

From liach at openjdk.org  Fri Aug 30 12:30:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 12:30:46 GMT
Subject: RFR: 8339320: Optimize ClassFile Utf8EntryImpl#inflate
In-Reply-To: <VQ7Ng5lasPoc1bcKntnkNzBzwpquCYtWf5n5cVZW0AA=.bd4ca92c-c6ca-41cc-9313-6d1fdfbeb4ee@github.com>
References: <Yy0WHB1yoKHW8VfwLU8AAkMNRYCug5v00nbFzhpfImQ=.546b293e-0ba6-48b0-a656-25da400ea1a7@github.com>
 <VQ7Ng5lasPoc1bcKntnkNzBzwpquCYtWf5n5cVZW0AA=.bd4ca92c-c6ca-41cc-9313-6d1fdfbeb4ee@github.com>
Message-ID: <sbT4yuIeuFhZ8Q6KKjf70QjlbqklAw3dIrkNke-L2U8=.d3e754ef-105a-4219-a318-847a4d9b9611@github.com>

On Thu, 29 Aug 2024 16:03:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A very small optimization, split the large method inflate, split the infrequently used paths into a method inflateCHAR
>
> src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 402:
> 
>> 400:                 return JLA.regionMatches(s, rawBytes, LATIN1, offset, charLen);
>> 401:             } else {
>> 402:                 return JLA.regionMatches(s, chars, UTF16, 0, charLen);
> 
> I think instead of making our internal representation complex to speed up this regionMatches, we should ask the VM side if they can provide a Java API for ArraysSupport.mismatch that operates on a byte array and a char array.

Just looked at `ArraysSupport`; we don't need to ask the VM; we can already duplicate `mismatch(char[], int, char[], int, int)`, make one of its `char[]` parameter `byte[]` and proceed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20767#discussion_r1736601972

From sgehwolf at openjdk.org  Fri Aug 30 12:54:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Aug 2024 12:54:22 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <VNuBcgbEVT92Cb5be_P1zpTigy4PS0iDGVyqFnQRiWw=.ffb0a776-a449-4a35-9590-1e53c221a9de@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <WdEe_NIIPH9gMgX0OhzCNF16SrUUJ33U4_fMnobaOCo=.0447ffa7-589f-45f2-b0f1-7e137cd33ebc@github.com>
 <VNuBcgbEVT92Cb5be_P1zpTigy4PS0iDGVyqFnQRiWw=.ffb0a776-a449-4a35-9590-1e53c221a9de@github.com>
Message-ID: <ZQoLKByTWvKWI0yRPALw1X0BLmH1IkCVlbDpgVTs1Hw=.2bd85a9a-459e-49b0-9bab-b845640c9e23@github.com>

On Fri, 30 Aug 2024 11:46:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > Not saying that this is a very bad thing, maybe it is just the way it is, that 'root' is needed ?
> 
> I'll do some more research whether or not that is a hard requirement. Thanks for the comments so far.

It turns out it works on cgroups v2 as non-root. I shall amend the test so that it at least runs OK on non-root and cgroups v2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2321150231

From lancea at openjdk.org  Fri Aug 30 13:05:19 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Aug 2024 13:05:19 GMT
Subject: RFR: 8322256: Define and document GZIPInputStream concatenated
 stream semantics [v2]
In-Reply-To: <5TIVJ2h7GO_nP_oiO2YbuDe_EG4NdzmaQQzA84vQRPE=.745c2d4f-a31f-45b3-b4c0-fb88e6791a34@github.com>
References: <iN99H94qOjDukPxj99zkHtWMN-uFZB-N_LeV7_m68IY=.31361ed9-eef7-4116-9305-0a5ceeb2c52b@github.com>
 <1LCpq5BdI6RVtoUAlgMVLondc1nudCguI_x_xq1m-c8=.7c2a12ba-3475-4482-b5c7-03c972be2bfb@github.com>
 <A4ZmtGpvSviFQcMwIBOr-aimR5MyvqG0n17-qsFNJdE=.e70cbf70-4f08-472b-b1ea-91c3a85a1392@github.com>
 <Znzg_hiGuEknVnkryA-zfEgPubYv4zBNf4Y1mRGQNvM=.52fe4e6f-217b-4d46-9e0a-3ebc991e9219@github.com>
 <5TIVJ2h7GO_nP_oiO2YbuDe_EG4NdzmaQQzA84vQRPE=.745c2d4f-a31f-45b3-b4c0-fb88e6791a34@github.com>
Message-ID: <OVD2D6d2_bPSKfSCaJUCkfiL6z0n6IGl24iED1xymWo=.d72afea5-ce00-46c0-80db-afd90b753cd5@github.com>

On Fri, 30 Aug 2024 11:44:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The gnu.org docs cover this(concatenating gzip files) as part of its [advanced usage of gzip](https://github.com/openjdk/jdk/pull/20787#issuecomment-2320873616), so I don'r think we need to do any more archeology
> 
> Okay, but just very surprising that support was added in JDK 7 without changes to the API docs or other documentation (from a quick search).
> 

I am not sure either but the implementation is pretty much in line with gzip/gunzip

> If we are retrofitting the APIs docs then I think treat "GZIP" as a file format. It may require adding overrides so there is a place to document the behavior when reading an entry roll over into the next stream.

Perhaps, an  additional blurb(or APINote) in the existing GZIPInputStream::read, but I think the verbiage that is being proposed with a couple tweaks covers the behavior.

BTW, this is what gzip/gunzip does:


bats % ls
Bruce.txt       Robin.txt       batman.txt      hello.txt    

bats % gzip -c batman.txt  > iambatman.gz
bats % gzip -c Bruce.txt  >> iambatman.gz
bats % gzip -c hello.txt  >> iambatman.gz
bats % gzip -c Robin.txt >> iambatman.gz   
bats % gunzip -c iambatman.gz 
I am batman
Bruce Wayne here
hello
Robin here

bats % gzip -c batman.txt  > iambrokenbat.gz
bats % gzip -c Bruce.txt >> iambrokenbat.gz 
bats % cat hello.txt >> iambrokenbat.gz 
bats % gzip -c Robin.txt >> iambrokenbat.gz

bats % gunzip -c iambrokenbat
I am batman
Bruce Wayne here
gunzip: iambrokenbat.gz: trailing garbage ignored


bats % gunzip iambatman    

bats % ls
Bruce.txt       Robin.txt       batman.txt      batman.txt.orig hello.txt       iambatman       iambrokenbat.gz
bats % cat iambatman 
I am batman
Bruce Wayne here
hello
Robin here

bats % gunzip iambrokenbat    
gunzip: iambrokenbat.gz: trailing garbage ignored
bats % ls
Bruce.txt       Robin.txt       batman.txt      batman.txt.orig hello.txt       iambatman       iambrokenbat
bats % cat iambrokenbat 
I am batman
Bruce Wayne here

bats %  gunzip -l iambatman.gz 
  compressed uncompressed  ratio uncompressed_name
         167           11 -99.9% iambatman

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20787#issuecomment-2321182631

From liach at openjdk.org  Fri Aug 30 13:40:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 13:40:21 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v4]
In-Reply-To: <c32KOKGermwbLmpnArWtsdCn9yXTnExmjwrRDVoY8so=.3ca05a51-7876-4f63-9465-94b4c88c1b6d@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
 <c32KOKGermwbLmpnArWtsdCn9yXTnExmjwrRDVoY8so=.3ca05a51-7876-4f63-9465-94b4c88c1b6d@github.com>
Message-ID: <x6mYMahDFUlAaLKMEe56S-wUa-HWzr7Bb7wXH8P_wcM=.e249a6b0-5132-45ff-88c4-ddc27131cae6@github.com>

On Thu, 29 Aug 2024 22:33:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
>> 
>> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
>> 
>> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
>> 
>> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.
>
> 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 six additional commits since the last revision:
> 
>  - Reorder float and long to match instruction order, fix compilation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
>  - space
>  - More fixes, reorder constants
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
>  - 8339115: Rename TypeKind enum constants to follow code style

Requesting a review because I reordered `LONG` and `FLOAT`. They are now in the order of the instructions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20737#issuecomment-2321289110

From duke at openjdk.org  Fri Aug 30 13:56:19 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 30 Aug 2024 13:56:19 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
Message-ID: <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>

On Fri, 30 Aug 2024 10:51:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert copyright year
>  - Move logic back to AMSI

Changes requested by franz1981 at github.com (no known OpenJDK username).

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 208:

> 206:             }
> 207:             final long u = Byte.toUnsignedLong(value);
> 208:             final long longValue = u << 56 | u << 48 | u << 40 | u << 32 | u << 24 | u << 16 | u << 8 | u;

this can be u * 0xFFFFFFFFFFFFL if value != 0 and just 0L if not: not sure if fast(er), need to measure.

Most of the time filling is happy with 0 since zeroing is the most common case

-------------

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2272430113
PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1738721722

From sgehwolf at openjdk.org  Fri Aug 30 14:14:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Aug 2024 14:14:05 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v7]
In-Reply-To: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
Message-ID: <4LqgwosLUnfbgYVsRmdcIln9NOplSeSum_iSX0-ri4w=.f2413f2d-08b5-4053-9795-279838c4226c@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 incrementally with four additional commits since the last revision:

 - Fix comment of WB::host_cpus()
 - Handle non-root + CGv2
 - Add nested hierarchy to test framework
 - Revert "Add root check for SystemdMemoryAwarenessTest.java"
   
   This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19530/files
  - new: https://git.openjdk.org/jdk/pull/19530/files/7e8d9ed4..a98fd7d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19530&range=05-06

  Stats: 232 lines in 4 files changed: 167 ins; 35 del; 30 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 mcimadamore at openjdk.org  Fri Aug 30 14:14:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 14:14:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
Message-ID: <StiUj2l8ziigqHUx-yI2UGOyFcUd0oIngLadtEuFpNM=.c786c3e2-6cae-4af0-abb4-5b09379c8042@github.com>

On Fri, 30 Aug 2024 10:51:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert copyright year
>  - Move logic back to AMSI

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 200:

> 198:         checkReadOnly(false);
> 199:         // 0...0X...XXXX implies: 0 <= length < FILL_NATIVE_LIMIT
> 200:         if ((length & -FILL_NATIVE_THRESHOLD) == 0) {

Looks great - few notes:
* adding `@ForceInline` here might help
* I'd suggest to move the `length == 0` outside in its own `if` branch (and drop the `return` from there). E.g.


if (length == 0) { ... }
else if (length & -FILL...) { ... }
else { ... }
return this;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1738755601

From asotona at openjdk.org  Fri Aug 30 14:18:22 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Aug 2024 14:18:22 GMT
Subject: RFR: 8339115: Rename TypeKind enum constants to follow code style
 [v4]
In-Reply-To: <c32KOKGermwbLmpnArWtsdCn9yXTnExmjwrRDVoY8so=.3ca05a51-7876-4f63-9465-94b4c88c1b6d@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
 <c32KOKGermwbLmpnArWtsdCn9yXTnExmjwrRDVoY8so=.3ca05a51-7876-4f63-9465-94b4c88c1b6d@github.com>
Message-ID: <8sM_xO8MuZN5t-qio_0YAuP1023tsR71Jmb8TsLs1BA=.231c3266-238e-4a4c-9868-7f573ca5aeac@github.com>

On Thu, 29 Aug 2024 22:33:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
>> 
>> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
>> 
>> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
>> 
>> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.
>
> 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 six additional commits since the last revision:
> 
>  - Reorder float and long to match instruction order, fix compilation
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
>  - space
>  - More fixes, reorder constants
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typekind
>  - 8339115: Rename TypeKind enum constants to follow code style

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20737#pullrequestreview-2272494468

From duke at openjdk.org  Fri Aug 30 14:21:21 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 30 Aug 2024 14:21:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
 <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
 <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
Message-ID: <dXdGV_cs8cRM1k5jfGKpm4aFqB11KCYmZqDhVOozWyU=.070a1596-a067-45a0-81cc-6256ff9622f4@github.com>

On Fri, 30 Aug 2024 12:15:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> @minborg Hi! I didn't checked the numbers with the benchmark I've written at https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is meant to stress the branch predictor (without enough `samples` i.e. past 128K on my machine) - can you give it a shot with M1 ? ?
>
> @franz1981 Here is what I get if I run your performance test on my M1 Mac (unfortunately no -perf data):
> 
> 
> Base
> Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score        Error  Units
> TestBranchFill.heap_segment_fill       1024      false  avgt   30    58597.625 ?   1871.313  ns/op
> TestBranchFill.heap_segment_fill       1024       true  avgt   30    64309.859 ?   1164.360  ns/op
> TestBranchFill.heap_segment_fill     128000      false  avgt   30  7136796.445 ? 152120.060  ns/op
> TestBranchFill.heap_segment_fill     128000       true  avgt   30  7908474.120 ?  49184.950  ns/op
> 
> 
> Patch
> Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score       Error  Units
> TestBranchFill.heap_segment_fill       1024      false  avgt   30     3695.815 ?    24.615  ns/op
> TestBranchFill.heap_segment_fill       1024       true  avgt   30     3938.582 ?   124.510  ns/op
> TestBranchFill.heap_segment_fill     128000      false  avgt   30   420845.301 ?  1605.080  ns/op
> TestBranchFill.heap_segment_fill     128000       true  avgt   30  1778362.506 ? 39250.756  ns/op

Thanks @minborg to run it, so it seems that 128K, despite the additional call (due to not inlining something), makes nuking the pipeline of M1 a severe affair:

Patch
Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score       Error  Units
TestBranchFill.heap_segment_fill     128000      false  avgt   30   420845.301 ?  1605.080  ns/op
TestBranchFill.heap_segment_fill     128000       true  avgt   30  1778362.506 ? 39250.756  ns/op <----- HERE!

now the interesting thing...there's really some other non-branchy way to handle this? is it worthy?
I sadly have not much answers on this, since when I make something similar to Netty at https://github.com/netty/netty/pull/13693 I've decided for a more drastic approach, see https://github.com/netty/netty/pull/13693/files#diff-49ee8d7612d5ecfcc27b46c38a801ad32ebdb169f7d79f1577313a1de70b0fbbR639-R649

TLDR:
- modern x86 are decent to fill unaligned data in, but non-x86, not so great: that lead me to handle alignment; for off-heap memory, clearly
- use 2 loops to reduce the branches (amortize, let's say) and hope the 1-7 bytes will work decently with unrolling and placing bytes singularly - but basically leveraging `Unsafe` for both
- the cutoff value is much higher because of pre jdk 21 memset suboptimal impl (now fixed in main by @asgibbons )
- the array/heap case was already handled by `Arrays::fill`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2321405596

From mcimadamore at openjdk.org  Fri Aug 30 14:21:22 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 14:21:22 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
 <SKCPBM9dnSvKezc9TIByUmI5Ny2TrwV5V9pNAZwOOI4=.6d4c3840-325f-49c7-abef-3f74296eb15f@github.com>
Message-ID: <TBtFgEPkWuyuBLXvbavRV027HfB9_QPcpyENAkd1llE=.beffffda-09f5-4792-90d1-c5481856663b@github.com>

On Fri, 30 Aug 2024 13:53:37 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> this can be u * 0xFFFFFFFFFFFFL if value != 0 and just 0L if not: not sure if fast(er), need to measure.
> 
> Most of the time filling is happy with 0 since zeroing is the most common case

It's a clever trick. However, I was looking at similar tricks and found that the time spent here is irrelevant (e.g. I tried to always force `0` as the value, and couldn't see any difference).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20712#discussion_r1738762266

From sgehwolf at openjdk.org  Fri Aug 30 14:23:20 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Aug 2024 14:23:20 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v7]
In-Reply-To: <4LqgwosLUnfbgYVsRmdcIln9NOplSeSum_iSX0-ri4w=.f2413f2d-08b5-4053-9795-279838c4226c@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <4LqgwosLUnfbgYVsRmdcIln9NOplSeSum_iSX0-ri4w=.f2413f2d-08b5-4053-9795-279838c4226c@github.com>
Message-ID: <FNmUmCY0QjnznxVF0NslxA5DxTtvW3yfGy3o0hA0LY0=.7963be9d-8812-431f-b59f-f0ef439f41ed@github.com>

On Fri, 30 Aug 2024 14:14:05 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 incrementally with four additional commits since the last revision:
> 
>  - Fix comment of WB::host_cpus()
>  - Handle non-root + CGv2
>  - Add nested hierarchy to test framework
>  - Revert "Add root check for SystemdMemoryAwarenessTest.java"
>    
>    This reverts commit 7e8d9ed46815096ae8c4502f3320ebf5208438d5.

I've updated the patch to:

1. Run tests on cg v2 when non-root (uses `~/.config/systemd/user`) directory and `systemctl --user` as well as `systemd-run --user` in that case.
2. The framework now also sets it up so that there is a lower limit further down the hierarchy: `jdk_internal.slice.d` directory has the lowest limit. The slice files itself have a higher one. The test asserts that the lower limit is being detected correctly.
3. The framework now skips the test in the main entry point (i.e. on cg v1 and non-root).
4. Addressed review comments so far.

Tested on cg v1 and cg v2 as root and non-root each (with the patch of #20646 applied as well).

Please let me know what you think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19530#issuecomment-2321413352

From sgehwolf at openjdk.org  Fri Aug 30 14:23:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 30 Aug 2024 14:23:22 GMT
Subject: RFR: 8333446: Add tests for hierarchical container support [v6]
In-Reply-To: <gEBipl5nJtEKXA-iH9LTpMhOxY-yI2Ds4mOal695hPw=.7be47334-df52-4132-8258-dc0c2a2383b2@github.com>
References: <gu9zW7xFuwfD7EyhkHQYadnHoB0DlCtSlkg8ddja9lQ=.523cfe54-5b05-44a2-9030-1dbc78797e7e@github.com>
 <-Ff0X6wkJWy78vOGT8F1m939z9Aoq8VjbUi_OTNoxko=.9447519f-8e98-4d9d-9c94-86cdbbbe3ae1@github.com>
 <SGwJOZu_Bvq1HlC901vsV8CEE9gJaB6cmXjWPHlKzMM=.61e99f79-35d1-46c5-984e-45ac369aa788@github.com>
 <gEBipl5nJtEKXA-iH9LTpMhOxY-yI2Ds4mOal695hPw=.7be47334-df52-4132-8258-dc0c2a2383b2@github.com>
Message-ID: <kGy_V5WxttK84K0JpO86hFDLfG7qLtSYu17ZI2s8bhM=.2936027d-a14f-43ed-a8a7-af2c5658667b@github.com>

On Fri, 30 Aug 2024 11:40:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/share/prims/whitebox.cpp line 2507:
>> 
>>> 2505: WB_END
>>> 2506: 
>>> 2507: // Physical cpus of the host machine (including containers), Linux only.
>> 
>> Isn't the comment a bit misleading ?  From what I see , ` os::Linux::active_processor_count()` can use various mechanisms to get number of processor info, if it uses https://linux.die.net/man/2/sched_getaffinity it gives the 'set of CPUs on which it is eligible to run.'   That might be different from what the host has.
>
> Yes. See #20768 for an attempt to unify it. I'll change the comment with the update that I have for nested hierarchies. Thanks!

I've changed the comment.

>> test/hotspot/jtreg/containers/systemd/SystemdMemoryAwarenessTest.java line 58:
>> 
>>> 56:         SystemdRunOptions opts = SystemdTestUtils.newOpts("HelloSystemd");
>>> 57:         // 1 GB memory
>>> 58:         opts.memoryLimit("1000M");
>> 
>> Just wondering - is 1G here possible (the comment states 1 GB / 1024M) ?
>
> I probably shall fix the comment or change it to `1024M`. Either way it has to match the assertion where we look for `1048576000` bytes in the output.

This should be fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1738770335
PR Review Comment: https://git.openjdk.org/jdk/pull/19530#discussion_r1738770983

From duke at openjdk.org  Fri Aug 30 14:27:23 2024
From: duke at openjdk.org (fitzsim)
Date: Fri, 30 Aug 2024 14:27:23 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v3]
In-Reply-To: <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <eHm38XmMraAHknb8McrFqtonHuYGpl5uod8m0iCwF8w=.8c7e6efc-1e13-477c-875b-1a4dca95c10a@github.com>
Message-ID: <cap1_4Xng0bpJYQBFOfUKO8uMkKYZ4GSQrwQGryf6I0=.d896dcad-2949-4a6c-a71d-4434dc323d29@github.com>

On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim <duke at openjdk.org> wrote:

>> 8334048: -Xbootclasspath can not read some ZIP64 zip files
>
> fitzsim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootClassPathZipFileTest: Switch to createClassBytes, createZip static functions

Commenting in response to the inactivity prompt; I am still watching this one, waiting for a reviewer.  I am ready to take action on any feedback I receive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2321429353

From mcimadamore at openjdk.org  Fri Aug 30 14:34:21 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 14:34:21 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
Message-ID: <TqkRLfyI_BXzPOQ6S0e92EdeixJA6g_-KtG9z_Ayb-k=.c16f9fb9-0bc4-4963-a3b2-05280742f889@github.com>

On Fri, 30 Aug 2024 10:51:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert copyright year
>  - Move logic back to AMSI

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20712#pullrequestreview-2272542786

From epeter at openjdk.org  Fri Aug 30 15:02:26 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 30 Aug 2024 15:02:26 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
Message-ID: <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>

On Thu, 29 Aug 2024 05:42:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> As per the discussion on panama-dev mailing list[1], patch adds the support for following new two vector permutation APIs.
>> 
>> 
>> Declaration:-
>>     Vector<E>.selectFrom(Vector<E> v1, Vector<E> v2)
>> 
>> 
>> Semantics:-
>>     Using index values stored in the lanes of "this" vector, assemble the values stored in first (v1) and second (v2) vector arguments. Thus, first and second vector serves as a table, whose elements are selected based on index value vector. API is applicable to all integral and floating-point types.  The result of this operation is semantically equivalent to expression v1.rearrange(this.toShuffle(), v2). Values held in index vector lanes must lie within valid two vector index range [0, 2*VLEN) else an IndexOutOfBoundException is thrown.  
>> 
>> Summary of changes:
>> -  Java side implementation of new selectFrom API.
>> -  C2 compiler IR and inline expander changes.
>> -  In absence of direct two vector permutation instruction in target ISA, a lowering transformation dismantles new IR into constituent IR supported by target platforms. 
>> -  Optimized x86 backend implementation for AVX512 and legacy target.
>> -  Function tests covering new API.
>> 
>> JMH micro included with this patch shows around 10-15x gain over existing rearrange API :-
>> Test System: Intel(R) Xeon(R) Platinum 8480+ [ Sapphire Rapids Server]
>> 
>> 
>>   Benchmark                                     (size)   Mode  Cnt      Score   Error   Units
>> SelectFromBenchmark.rearrangeFromByteVector     1024  thrpt    2   2041.762          ops/ms
>> SelectFromBenchmark.rearrangeFromByteVector     2048  thrpt    2   1028.550          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      1024  thrpt    2    962.605          ops/ms
>> SelectFromBenchmark.rearrangeFromIntVector      2048  thrpt    2    479.004          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     1024  thrpt    2    359.758          ops/ms
>> SelectFromBenchmark.rearrangeFromLongVector     2048  thrpt    2    178.192          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    1024  thrpt    2   1463.459          ops/ms
>> SelectFromBenchmark.rearrangeFromShortVector    2048  thrpt    2    727.556          ops/ms
>> SelectFromBenchmark.selectFromByteVector        1024  thrpt    2  33254.830          ops/ms
>> SelectFromBenchmark.selectFromByteVector        2048  thrpt    2  17313.174          ops/ms
>> SelectFromBenchmark.selectFromIntVector         1024  thrpt    2  10756.804          ops/ms
>> S...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding descriptive comments

I left a few comments, hopefully I can spend some more time on this next week

src/hotspot/cpu/x86/matcher_x86.hpp line 215:

> 213:   }
> 214: 
> 215:   static bool vector_indexes_needs_massaging(BasicType ety, int vlen) {

The name "massaging" sounds quite vague. Can we have something more expressive / descriptive? Is it the vector that "needs" massaging or the indices that "need" massaging?

Why `ety` and not `bt`? Is that not the name we use most often?

src/hotspot/cpu/x86/x86.ad line 10490:

> 10488: 
> 10489: 
> 10490: instruct selectFromTwoVec_evex(vec dst, vec src1, vec src2)

You could rename `dst` -> `mask_and_dst`. That would maybe help the reader to more quickly know that it is an input-mask and output-dst.

src/hotspot/share/opto/vectorIntrinsics.cpp line 2716:

> 2714:   C->set_max_vector_size(MAX2(C->max_vector_size(), (uint)(num_elem * type2aelembytes(elem_bt))));
> 2715:   return true;
> 2716: }

The code in these methods are extremely duplicated. Unboxing and boxing in every method around here. Maybe not your problem in this PR.

BTW: your error logging used `v1` in all 3 cases `op1-3`, you probably want to give them useful names. `v1-3` probably?

All this copy-pasting makes it easy to miss updating some cases... like it happenend here.

src/hotspot/share/opto/vectornode.cpp line 2090:

> 2088:   int num_elem = vect_type()->length();
> 2089:   BasicType elem_bt = vect_type()->element_basic_type();
> 2090:   if (Matcher::match_rule_supported_vector(Op_SelectFromTwoVector, num_elem, elem_bt)) {

Suggestion:

  // Keep the node if it is supported, else lower it to other nodes.
  if (Matcher::match_rule_supported_vector(Op_SelectFromTwoVector, num_elem, elem_bt)) {

src/hotspot/share/opto/vectornode.cpp line 2095:

> 2093:   Node* index_vec = in(1);
> 2094:   Node* src1  = in(2);
> 2095:   Node* src2  = in(3);

Suggestion:

  Node* src1 = in(2);
  Node* src2 = in(3);

unnecessary spaces

src/hotspot/share/opto/vectornode.cpp line 2101:

> 2099:   //     (VectorBlend
> 2100:   //         (VectorRearrange SRC1, INDEX)
> 2101:   //         (VectorRearrange SRC2, NORM_INDEX)

Suggestion:

  //         (VectorRearrange SRC1 INDEX)
  //         (VectorRearrange SRC2 NORM_INDEX)

Either consistently use commas or none at all ;)

src/hotspot/share/opto/vectornode.cpp line 2104:

> 2102:   //         MASK)
> 2103:   // This shall prevent an intrinsification failure and associated argument
> 2104:   // boxing penalties.

A quick comment about how the mask is computed could be nice.
`MASK = INDEX < num_elem`

src/hotspot/share/opto/vectornode.cpp line 2126:

> 2124:       case T_FLOAT:
> 2125:         return phase->transform(new VectorCastF2XNode(index_vec, TypeVect::make(T_INT, num_elem)));
> 2126:       break;

`break` after `return`?

src/hotspot/share/opto/vectornode.cpp line 2141:

> 2139:       default: return elem_bt;
> 2140:     }
> 2141:   };

This is definitely a style question. But it might be nice to make these functions member functions. They now kinda disrupt the flow of the `::Ideal` method. And in some cases you use the captured variables, and in other cases you pass them in explicitly, even though they already exist in the captured scope... consistency would be nice.

src/hotspot/share/opto/vectornode.cpp line 2148:

> 2146: 
> 2147:   BoolTest::mask pred = BoolTest::lt;
> 2148:   ConINode* pred_node = (ConINode*)phase->makecon(TypeInt::make(pred));

Would `as_ConI()` be a better alternative to the `(ConINode*)` cast?

src/hotspot/share/opto/vectornode.cpp line 2149:

> 2147:   BoolTest::mask pred = BoolTest::lt;
> 2148:   ConINode* pred_node = (ConINode*)phase->makecon(TypeInt::make(pred));
> 2149:   Node* lane_cnt = phase->makecon(lane_count_type());

Hmm. I don't like to have different names for the same thing. `num_elem` and `lane_count` and `lane_cnt`.

What about a method `make_num_elem_node`, returns a `ConNode*`.
Then you pass it around as `num_elem_scalar`, and broadcast it to `num_elem_vector`.

src/hotspot/share/opto/vectornode.cpp line 2159:

> 2157: 
> 2158:   vmask_type = TypeVect::makemask(elem_bt, num_elem);
> 2159:   mask = phase->transform(new VectorMaskCastNode(mask, vmask_type));

I would just have two variables, and not overwrite it: `integral_vmask_type` and `vmask_type`. Maybe also `mask` could be split into two variables?

src/hotspot/share/opto/vectornode.cpp line 2181:

> 2179:         default: return elem_bt;
> 2180:       }
> 2181:     };

You are now using this twice. Is there not some method that already does this?

src/hotspot/share/opto/vectornode.cpp line 2183:

> 2181:     };
> 2182:     // Targets emulating unsupported permutation for certain vector types
> 2183:     // may need to message the indexes to match the users intent.

Suggestion:

    // may need to massage the indexes to match the users intent.

src/hotspot/share/opto/vectornode.hpp line 1272:

> 1270: };
> 1271: 
> 1272: 

spurious newline

src/hotspot/share/opto/vectornode.hpp line 1621:

> 1619: public:
> 1620:   SelectFromTwoVectorNode(Node* in1, Node* in2, Node* in3, const TypeVect* vt)
> 1621:   : VectorNode(in1, in2, in3, vt) {}

I would prefer more expressive variable names and a short specification what the node does. Otherwise one always has to reverse-engineer what inputs are acceptable etc. I mean you could even require `VectorNode*` as inputs.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20508#pullrequestreview-2272308274
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738648483
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738738172
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738759799
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738767466
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738768205
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738765017
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738823939
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738808199
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738781635
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738787762
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738806978
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738814420
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738838073
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738835911
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738729168
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738866021

From epeter at openjdk.org  Fri Aug 30 15:02:27 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Fri, 30 Aug 2024 15:02:27 GMT
Subject: RFR: 8338023: Support two vector selectFrom API [v7]
In-Reply-To: <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
References: <28KQHru1heR-YOVsRVo8Ffj_4D29IV8vD2tombvTHdI=.dba80ac3-9804-4074-ac0f-8acb9b042a08@github.com>
 <bsoZ-zYQIlSfn__EALTPic-73TRxIh2KOXYDTOaFuZs=.98554ee9-f51a-478a-86e8-18b9f4d19855@github.com>
 <ZlRonIp3-6V8jUAAPrijiUtlPQYo1h3us4bSPoubV7Q=.a931a203-2851-4a90-8d80-4f27d14b307e@github.com>
Message-ID: <tzd9C0Mpn-SIVqeg-446ZA9PJhNl9qcsbgH3E7q-_IY=.55d0c7eb-ec36-4e37-a4e4-9ed42c35866e@github.com>

On Fri, 30 Aug 2024 13:17:26 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding descriptive comments
>
> src/hotspot/cpu/x86/matcher_x86.hpp line 215:
> 
>> 213:   }
>> 214: 
>> 215:   static bool vector_indexes_needs_massaging(BasicType ety, int vlen) {
> 
> The name "massaging" sounds quite vague. Can we have something more expressive / descriptive? Is it the vector that "needs" massaging or the indices that "need" massaging?
> 
> Why `ety` and not `bt`? Is that not the name we use most often?

Hmm, I see that `ety` is used in other places here. What does it stand for?

> src/hotspot/share/opto/vectornode.cpp line 2183:
> 
>> 2181:     };
>> 2182:     // Targets emulating unsupported permutation for certain vector types
>> 2183:     // may need to message the indexes to match the users intent.
> 
> Suggestion:
> 
>     // may need to massage the indexes to match the users intent.

This optimization for now seems quite specific to your `SelectFromTwoVectorNode::Ideal` lowering code. Can this conversion not be done there already?

What is the semantics of `VectorRearrangeNode`? Should its shuffle vector always be bytes, and we now violated that "for a quick second"? Or is it going to be generally the idea to create all sorts of shuffle types and then fix that up? But then why do we need the `vector_indexes_needs_massaging`?

Can you help me understand the concept/strategy behind this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738714401
PR Review Comment: https://git.openjdk.org/jdk/pull/20508#discussion_r1738862138

From redestad at openjdk.org  Fri Aug 30 15:10:23 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 30 Aug 2024 15:10:23 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v2]
In-Reply-To: <GpfamiXMNcfcDh-itQPCLzPlkAQ2DEo1iw5EVrsolmA=.abd330ca-6c76-4c49-b47e-f538b1ffd8ac@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <GpfamiXMNcfcDh-itQPCLzPlkAQ2DEo1iw5EVrsolmA=.abd330ca-6c76-4c49-b47e-f538b1ffd8ac@github.com>
Message-ID: <sivgvle4s7Xx-41EUTOSxCfv2I5rv88hlqJjPyyfi2o=.608523d1-b5b2-4175-9c1f-c6276872eb17@github.com>

On Fri, 30 Aug 2024 05:24:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Do you have any benchmark numbers of note to support this?

src/java.base/share/classes/java/lang/StringCoding.java line 37:

> 35:     private StringCoding() { }
> 36: 
> 37:     public static boolean hasNegativeOrZeros(byte[] ba) {

Wait a second.. since you're only interested in and calling this when `s.coder == LATIN1` then values can't be negative. Which means all you really need is something like this:


  public static boolean isLatin1WithNoZeros(String s) {
      return s.isLatin() && s.indexOf(0) < 0;
  }


`indexOf` have intrinsic support and might perform better than a simple for-loop.

src/java.base/share/classes/java/lang/System.java line 2598:

> 2596: 
> 2597:             public boolean hasNegativeOrZeros(String s) {
> 2598:                 return s.coder() == String.UTF16 || StringCoding.hasNegativeOrZeros(s.value());

Avoid adding logic to methods in `*Access` bridges, define `hasNonPositives(String s)` (or `isLatin1WithNoZeros(String)`) in `StringCoding` instead.

-------------

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2272579498
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1738816044
PR Review Comment: https://git.openjdk.org/jdk/pull/20772#discussion_r1738821539

From duke at openjdk.org  Fri Aug 30 15:12:32 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 30 Aug 2024 15:12:32 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc typo
 and clarifications
Message-ID: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>

Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.

-------------

Commit messages:
 - 8339329: ConstantPoolBuilder#constantValueEntry method doc typo and clarifications

Changes: https://git.openjdk.org/jdk/pull/20796/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20796&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339329
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20796.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20796/head:pull/20796

PR: https://git.openjdk.org/jdk/pull/20796

From mcimadamore at openjdk.org  Fri Aug 30 15:26:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 15:26:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
 <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
 <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
Message-ID: <QUYohlnul_-0Kizau6sBGK2eJQ-oq-waa6F8HYsPCpw=.82701e45-7d6d-4f1b-b7e0-863234427a2c@github.com>

On Fri, 30 Aug 2024 12:15:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> @minborg Hi! I didn't checked the numbers with the benchmark I've written at https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is meant to stress the branch predictor (without enough `samples` i.e. past 128K on my machine) - can you give it a shot with M1 ? ?
>
> @franz1981 Here is what I get if I run your performance test on my M1 Mac (unfortunately no -perf data):
> 
> 
> Base
> Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score        Error  Units
> TestBranchFill.heap_segment_fill       1024      false  avgt   30    58597.625 ?   1871.313  ns/op
> TestBranchFill.heap_segment_fill       1024       true  avgt   30    64309.859 ?   1164.360  ns/op
> TestBranchFill.heap_segment_fill     128000      false  avgt   30  7136796.445 ? 152120.060  ns/op
> TestBranchFill.heap_segment_fill     128000       true  avgt   30  7908474.120 ?  49184.950  ns/op
> 
> 
> Patch
> Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score       Error  Units
> TestBranchFill.heap_segment_fill       1024      false  avgt   30     3695.815 ?    24.615  ns/op
> TestBranchFill.heap_segment_fill       1024       true  avgt   30     3938.582 ?   124.510  ns/op
> TestBranchFill.heap_segment_fill     128000      false  avgt   30   420845.301 ?  1605.080  ns/op
> TestBranchFill.heap_segment_fill     128000       true  avgt   30  1778362.506 ? 39250.756  ns/op

> Thanks @minborg to run it, so it seems that 128K, despite the additional call (due to not inlining something), makes nuking the pipeline of M1 a severe affair:

If I understand correctly, this benchmark attempts to call `fill` with different segment sizes (in a loop) - correct? It's understandable that, in this case, we can't optimize as well, because we have different branches which get taken or not in a less predictable fashion. The important question is (for this PR): does the work proposed here cause a _regression_ in the case you have in mind? E.g. is the `setMemory` intrinsics better than the branchy logic we have here?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2321596145

From kvn at openjdk.org  Fri Aug 30 15:33:20 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 30 Aug 2024 15:33:20 GMT
Subject: RFR: 8338017: Add AOT command-line flag aliases [v3]
In-Reply-To: <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
References: <9mkqNIOuSD1ts7Stm0BlKb7YxQNFPXkwr7lhk1Cd_Cg=.a74b8df5-e202-484b-81a2-78ec59310bf4@github.com>
 <0niPo0lMQPnLlUxCrIWNcPnzy6-4y7kBmO_kKiK2twU=.5e2d4404-f4e9-4b9c-a5c7-9b3b1042b029@github.com>
Message-ID: <X-oMdt2LU4xadEz4R9_fASa1blNKNIB-O0lkHHOV3Fs=.2fc4f483-c99b-4cdf-b676-bd93c8dc687d@github.com>

On Thu, 29 Aug 2024 22:11:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 1st PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> Add the following command-line options as specified in JEP 483:
>> 
>> 
>> - `-XX:AOTMode=off/record/create/auto/on`
>> - `-XX:AOTConfiguration=<file>.aotconfig`
>> - `-XX:AOTCache=<file>.aot`
>> 
>> These options are implemented as aliases to existing command-line flags such as `-Xshare:dump`, `-XX:SharedArchiveFile`, `-XX:DumpLoadedClassesList`, etc.
>> 
>> Please see the CSR (TODO) for detailed specification.
>> 
>> -----
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments: do not check for -XX:AOTMode=create in JLI java.c

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20516#pullrequestreview-2272769166

From duke at openjdk.org  Fri Aug 30 15:35:20 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 30 Aug 2024 15:35:20 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <QUYohlnul_-0Kizau6sBGK2eJQ-oq-waa6F8HYsPCpw=.82701e45-7d6d-4f1b-b7e0-863234427a2c@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
 <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
 <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
 <QUYohlnul_-0Kizau6sBGK2eJQ-oq-waa6F8HYsPCpw=.82701e45-7d6d-4f1b-b7e0-863234427a2c@github.com>
Message-ID: <SXsdTrBQikLZGm2vcIgeWxPJryXqi5vG9okm0hlZBaE=.c7976609-d3e1-45fb-a591-ffe1cae37b9d@github.com>

On Fri, 30 Aug 2024 15:21:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>  in this case, we can't optimize as well, because we have different branches which get taken or not in a less predictable fashion.

Exactly - It has been designed to show the case when the conditions materialize (because are taken) and are performed in a non predictable sequence. 
I couldn't find an easier way to make it happen reliably if not by making the root method not been inlined, with the limit that the actuall call of this root method is now part of the cost, but should be order of magnitude less important than a pipeline nuke.
I could have made the method being C2 compiled in the setup with all the branches taken and "probably" I could have dropped the DONTINLINE in the root method - but I'm not sure.

> The important question is (for this PR): does the work proposed here cause a regression in the case you have in mind? E.g. is the setMemory intrinsics better than the branchy logic we have here?

good point: relatively to the baseline, nope, cause the new version improve regardless, even when the new version got high branch misses

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2321630093

From mcimadamore at openjdk.org  Fri Aug 30 16:42:23 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 16:42:23 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
 <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
 <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
Message-ID: <4-cvlYbGEOdEjIF1A6vKHAEZb6MDdEKFGa0XTRZl-N4=.c8b123e6-bcd4-4e65-a835-09e2e3a53fb2@github.com>

On Fri, 30 Aug 2024 12:15:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> @minborg Hi! I didn't checked the numbers with the benchmark I've written at https://github.com/openjdk/jdk/pull/20712#discussion_r1732802685 which is meant to stress the branch predictor (without enough `samples` i.e. past 128K on my machine) - can you give it a shot with M1 ? ?
>
> @franz1981 Here is what I get if I run your performance test on my M1 Mac (unfortunately no -perf data):
> 
> 
> Base
> Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score        Error  Units
> TestBranchFill.heap_segment_fill       1024      false  avgt   30    58597.625 ?   1871.313  ns/op
> TestBranchFill.heap_segment_fill       1024       true  avgt   30    64309.859 ?   1164.360  ns/op
> TestBranchFill.heap_segment_fill     128000      false  avgt   30  7136796.445 ? 152120.060  ns/op
> TestBranchFill.heap_segment_fill     128000       true  avgt   30  7908474.120 ?  49184.950  ns/op
> 
> 
> Patch
> Benchmark                         (samples)  (shuffle)  Mode  Cnt        Score       Error  Units
> TestBranchFill.heap_segment_fill       1024      false  avgt   30     3695.815 ?    24.615  ns/op
> TestBranchFill.heap_segment_fill       1024       true  avgt   30     3938.582 ?   124.510  ns/op
> TestBranchFill.heap_segment_fill     128000      false  avgt   30   420845.301 ?  1605.080  ns/op
> TestBranchFill.heap_segment_fill     128000       true  avgt   30  1778362.506 ? 39250.756  ns/op

> > Thanks @minborg to run it, so it seems that 128K, despite the additional call (due to not inlining something), makes nuking the pipeline of M1 a severe affair:
> 
> If I understand correctly, this benchmark attempts to call `fill` with different segment sizes (in a loop) - correct? It's understandable that, in this case, we can't optimize as well, because we have different branches which get taken or not in a less predictable fashion. The important question is (for this PR): does the work proposed here cause a _regression_ in the case you have in mind? E.g. is the `setMemory` intrinsics better than the branchy logic we have here?

@franz1981 It would be interesting to compare the overhead you measured in your shuffle benchmark with `Array::fill` - which is, I think, where we'd like to get at.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2321936437

From erikj at openjdk.org  Fri Aug 30 16:46:30 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 30 Aug 2024 16:46:30 GMT
Subject: RFR: 8339156: Use more fine-granular clang unused warnings [v2]
In-Reply-To: <b8OW9mnHcvmbpUGxL2Lz2OH598ndK_MUnup0LOIcDO8=.0918f694-df17-40e2-92db-c064d5329f91@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
 <b8OW9mnHcvmbpUGxL2Lz2OH598ndK_MUnup0LOIcDO8=.0918f694-df17-40e2-92db-c064d5329f91@github.com>
Message-ID: <EWPT7AGQaUN8olIWoahROKnS7mts9XX6WAGJxjEw9bw=.c33d39e3-d1a4-41a2-b25b-b7be6ec005cf@github.com>

On Fri, 30 Aug 2024 11:35:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
>> 
>> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
>> 
>> This is similar to what has been done for gcc in JDK-8339120.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into finegranular-clang-unused
>  - 8339156: Use more fine-granular clang unused warnings

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20770#pullrequestreview-2273037764

From ihse at openjdk.org  Fri Aug 30 16:46:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 30 Aug 2024 16:46:31 GMT
Subject: Integrated: 8339156: Use more fine-granular clang unused warnings
In-Reply-To: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
References: <a_PWD80n_G94GarRev96bpwD8QiqGSsckAoj4WvVIPA=.77cc1050-2b32-4580-a783-a2db600e8947@github.com>
Message-ID: <jCx-fCeWrT743k3v48tHI3-aLnI988lRRZHFnrSANsE=.e23e66e8-d58d-4571-a431-9522b897ef32@github.com>

On Thu, 29 Aug 2024 13:14:35 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, we issue -Wno-unused for all files in clang, which is a rather big sledgehammer to get rid of some warnings that proliferate in a few areas of the build.
> 
> We should instead leave -Wunused turned on (as done by -Wall) and use a much more fine-grained approach to disabling specific warnings in specific files or libraries.
> 
> This is similar to what has been done for gcc in JDK-8339120.

This pull request has now been integrated.

Changeset: a528c4b3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a528c4b370be1e7730778268cf8c52ffcfd27048
Stats:     60 lines in 16 files changed: 42 ins; 1 del; 17 mod

8339156: Use more fine-granular clang unused warnings

Reviewed-by: erikj, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/20770

From swen at openjdk.org  Fri Aug 30 17:08:33 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 17:08:33 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v3]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <3G9eHYj2OVrhr62Jrle5X4_3Wj98YKTtJeABYo8bgfA=.d60e0485-dfe2-4f69-bb81-495f3b79365b@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Suggestions from @cl4es, rename hasNegativeOrZeros to isLatin1GreaterThanZero

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/28bd454c..3ca9fb52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=01-02

  Stats: 16 lines in 4 files changed: 6 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

PR: https://git.openjdk.org/jdk/pull/20772

From bpb at openjdk.org  Fri Aug 30 17:20:25 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Aug 2024 17:20:25 GMT
Subject: Integrated: 6426678: (spec) File.createTempFile(prefix, suffix,
 dir) needs clarification for illegal symbols in suffix
In-Reply-To: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
References: <WQtSq1H8bHvSY7fCO9hw8mCh-HCI1GK2QgObvr59uE0=.75b85215-bf70-44ef-9614-95b7a3d2dcbc@github.com>
Message-ID: <Wmg_4GwFXXE65bmlQviv1gkLNbhSxo69XGx7xGxcGYk=.0df04049-4e39-45c8-83a1-7220a3d29939@github.com>

On Fri, 2 Aug 2024 00:21:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add some verbiage indicating that an `IOException` will be thrown if a file with a name generated from the supplied prefix and suffix according to the described algorithm cannot be generated by the underlying system, whether that be due to the presence of one of more characters not supported by the underlying system or for some other reason.

This pull request has now been integrated.

Changeset: fef1ef7d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fef1ef7dfe1aed7729b182b2fc8d0dda7d546a56
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

6426678: (spec) File.createTempFile(prefix, suffix, dir) needs clarification for illegal symbols in suffix

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/20435

From liach at openjdk.org  Fri Aug 30 17:22:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 17:22:19 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications
In-Reply-To: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
Message-ID: <wPKCaGxwNt4IILQoqX69kBvEQJ6Azk_RxLmHsCuYlms=.1caf30c0-3950-4da5-bcd6-5a4af860fcc3@github.com>

On Fri, 30 Aug 2024 15:08:20 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.

src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 479:

> 477:      * {@return A {@link ConstantValueEntry} describing the provided
> 478:      * Integer, Long, Float, Double, or String constant}
> 479:      * The returned consant is suitable as a value for the

This information is already available on `ConstantValueEntry`. Since we already link to it on the return type, I feel like this is a redundancy.

However, `ConstantValueEntry::constantValue()` is missing a link to this API; would be nice if you can add that. And `ConstantValueEntry` is missing a link to `Attributes::constantValue()` too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20796#discussion_r1739164493

From liach at openjdk.org  Fri Aug 30 17:31:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 17:31:34 GMT
Subject: Integrated: 8339115: Rename TypeKind enum constants to follow code
 style
In-Reply-To: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
References: <PE4gAxKmGTt47D19xxdW0d4wyT3p4sD7JmKGviY7gBg=.979b0984-046f-4bd6-87fe-f7d12e2bfc66@github.com>
Message-ID: <GjHInoPi2hPRkO2fu3hkpsRYFk9yq7ORb-4KwWTfYGY=.3dbc7f26-2687-4c90-8899-ca65b3e34cdf@github.com>

On Tue, 27 Aug 2024 22:15:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> `TypeKind` enum constants are named in wrong code style; correct them before finalization.
> 
> Also improved `TypeKind` specification to talk about not mentioned `returnType`, `void`, and subword types being erased to int (and how). See the associated CSR too.
> 
> See the HTML output for the changed `JSpec` taglet's `6.5.newarray` rendering: https://cr.openjdk.org/~liach/8339115-typekind/java.base/java/lang/classfile/TypeKind.html
> 
> Note: when reviewing, please use https://cr.openjdk.org/~iris/se/23/spec/draft/java-se-23-draft-spec-37/ instead of JVMS 22 for reference; JVMS 23 has fixed a few ambiguities about subword types being absent from JVM's stack and locals.

This pull request has now been integrated.

Changeset: 25e03b52
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25e03b52094f46f89f2fe8f20e7e5622928add5f
Stats:     753 lines in 38 files changed: 116 ins; 29 del; 608 mod

8339115: Rename TypeKind enum constants to follow code style

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/20737

From duke at openjdk.org  Fri Aug 30 18:12:38 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 30 Aug 2024 18:12:38 GMT
Subject: RFR: 8339329: ConstantPoolBuilder#constantValueEntry method doc
 typo and clarifications [v2]
In-Reply-To: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
References: <UbsjLYqCDX9mrBpVYMJnVKC25uHbQ2ukA8ME7ELiyeg=.e9ffbfb9-79b3-495c-a760-c5e8b6af6da7@github.com>
Message-ID: <MBFNBCeBpUUQJlhJV6ot_BAu8gRoNLLLegac0SWUsF8=.d1402333-ccc7-4690-b98f-b470f273c696@github.com>

> Please review this small documentation change to ConstantPoolBuilder to fix a typo and clarify the usage of the `constantValueEntry` method.

David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20796/files
  - new: https://git.openjdk.org/jdk/pull/20796/files/7f20be96..03c0cc10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20796&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20796&range=00-01

  Stats: 7 lines in 3 files changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20796.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20796/head:pull/20796

PR: https://git.openjdk.org/jdk/pull/20796

From jlu at openjdk.org  Fri Aug 30 18:31:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Aug 2024 18:31:22 GMT
Subject: Integrated: 8338882: Clarify matching order of MessageFormat subformat
 factory styles
In-Reply-To: <6y7WfaWdoIJGDvbj9NxDqx0RbxxFrfaLY0_AIHqrETs=.6139748e-eae0-412b-80ad-21ae7886a0c9@github.com>
References: <6y7WfaWdoIJGDvbj9NxDqx0RbxxFrfaLY0_AIHqrETs=.6139748e-eae0-412b-80ad-21ae7886a0c9@github.com>
Message-ID: <tjL3uzwMzligTxEwOFG_ImRKIqrF3f0PM1xI0tnkRIE=.b7fa3402-8a4d-420b-877a-d6920a9c6402@github.com>

On Fri, 23 Aug 2024 19:58:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies that the matching order of format styles for MessageFormat sub formats is not guaranteed. A corresponding CSR has also been drafted.
> 
> This is relevant when a locale provides equivalent patterns for multiple format factory styles. For example, a locale X could provide some equivalent date style "xyz" for both a MEDIUM and LONG style. Thus invoking toPattern() could output `date`, `date,medium`, or `date,long` depending on the order of such matching.

This pull request has now been integrated.

Changeset: b840b130
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b840b130df7ccb64d4615460c0654a6315e9302f
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8338882: Clarify matching order of MessageFormat subformat factory styles

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/20695

From liach at openjdk.org  Fri Aug 30 18:35:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 18:35:52 GMT
Subject: RFR: 8339260: Move rarely used constants out of ClassFile [v2]
In-Reply-To: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
References: <mVtV5VO8J8z9sSMipPtYaw3WHfdExGLXLGB9XjnhgJE=.d79ba728-1e4d-4aef-8df3-a3bc2e79f831@github.com>
Message-ID: <tnUo9TMHvknWUCSh2ZTJGUfYbV8_rhl8BZu9GsIms7A=.2ee4203f-e453-4396-a6f0-467ac23bc085@github.com>

> Many constants are cluttered in `ClassFile`. However, only a few of them are ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION` constants. All other constants are specific and should live in more local locations, such as getters that return these constants.
> 
> This simplification of `ClassFile` constants improves user onramp to the Class-File API.
> 
> Notably, before, if `ClassFile` is static imported, `Opcode` enums must be qualified due to name clashes; this relocation allows `Opcode` enums to be static imported with `ACC_` flags, improving class file writing user experience.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/constant-moving
 - Compile errors; now tests are all green.
 - Move Constant Pool tags to PoolEntry
   
   Two unexpected usages in jlink raw processing, but rest is fine
 - opcode values moved to OpcodeValues
   
   less impactful than imagined, no longer need to qualify Opcode use when star importing ClassFile
 - Hide default class flags as well
 - Simplify SimpleVerificationTypeInfo's constant names
 - 8339260: Move rarely used constants out of ClassFile

-------------

Changes: https://git.openjdk.org/jdk/pull/20773/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20773&range=01
  Stats: 2615 lines in 36 files changed: 865 ins; 905 del; 845 mod
  Patch: https://git.openjdk.org/jdk/pull/20773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20773/head:pull/20773

PR: https://git.openjdk.org/jdk/pull/20773

From liach at openjdk.org  Fri Aug 30 18:48:19 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Aug 2024 18:48:19 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v3]
In-Reply-To: <3G9eHYj2OVrhr62Jrle5X4_3Wj98YKTtJeABYo8bgfA=.d60e0485-dfe2-4f69-bb81-495f3b79365b@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
 <3G9eHYj2OVrhr62Jrle5X4_3Wj98YKTtJeABYo8bgfA=.d60e0485-dfe2-4f69-bb81-495f3b79365b@github.com>
Message-ID: <rLC7afbHFALMLmjgpBKxwTBL4nJPDQJsZhTFVty6-DQ=.d91b822f-39f3-4e46-a0c5-77e0deabd701@github.com>

On Fri, 30 Aug 2024 17:08:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions from @cl4es, rename hasNegativeOrZeros to isLatin1GreaterThanZero

If a non-ascii is in the middle or the end of a string, this patch may add an overhead. Offline benchmark results show that this actually brings a regression in the startup of a jetty server.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20772#pullrequestreview-2273287184

From swen at openjdk.org  Fri Aug 30 19:39:32 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 30 Aug 2024 19:39:32 GMT
Subject: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v4]
In-Reply-To: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
References: <slxSZSeBY9Sg5UXeVVM8CivZav0lPTpgcK4kfOnXuYs=.4a4fc77f-34c4-4851-a92d-9df11ed0e146@github.com>
Message-ID: <vinSCh5ftue567kq_iaLUp1WG84KMI6wgN_jcFOq8kg=.d0756d5a-99cb-4934-9da9-c2904b2b5b8d@github.com>

> Use fast path for ascii characters 1 to 127 to improve the performance of writing Utf8Entry to BufferWriter.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  optimize Utf8EntryImpl#writeTo(UTF)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20772/files
  - new: https://git.openjdk.org/jdk/pull/20772/files/3ca9fb52..34aab42d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20772&range=02-03

  Stats: 69 lines in 2 files changed: 23 ins; 45 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20772/head:pull/20772

PR: https://git.openjdk.org/jdk/pull/20772

From duke at openjdk.org  Fri Aug 30 20:26:05 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 30 Aug 2024 20:26:05 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
Message-ID: <H3MThPP9Yv-FkzdKImDdZXXfHyWCGmv5VUY3ml6jo6Y=.99effbec-b69f-4707-99e1-00497cd45620@github.com>

> The goal of this PR is to implement an x86_64 intrinsic for java.lang.Math.tanh() using libm
> 
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Add stub initialization and extra tanh tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20657/files
  - new: https://git.openjdk.org/jdk/pull/20657/files/79766f1b..4739ad45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20657&range=00-01

  Stats: 65 lines in 2 files changed: 65 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20657/head:pull/20657

PR: https://git.openjdk.org/jdk/pull/20657

From duke at openjdk.org  Fri Aug 30 20:37:19 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 30 Aug 2024 20:37:19 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm
In-Reply-To: <k9BNHWV60-h0--5q9V-wmC9APFRNTz4DDla8LSwWcko=.fb51e30e-215a-4bb5-b543-210b227c5a0b@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <WDToV3EsXlAGIbz6og4wnktMZIQZ7GxL8IGJvTM8EJA=.5df48925-fca6-4d7f-b241-60d870e355d6@github.com>
 <5RUXvY7Tb8B_QYxg0iLNaC5d6fcNMdHUYXdEzyBoQ_U=.19f4d853-620a-459c-acc1-d57bfd6fb7bc@github.com>
 <k9BNHWV60-h0--5q9V-wmC9APFRNTz4DDla8LSwWcko=.fb51e30e-215a-4bb5-b543-210b227c5a0b@github.com>
Message-ID: <8HXosdqMZUFQZ0dFkmNbi2lBcbGSJl-pyeCZ9HsHOPg=.7d55d0d6-5aa6-4b1e-9ed2-138b8654237e@github.com>

On Tue, 27 Aug 2024 22:44:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> This PR doesn't include any additional tests. It is often appropriate to add more regression testing when introducing a new implementation of a method.
>> 
>> Thank You Joe for the suggestion. Will add more tests. (This PR passes the tier-1 tanh tests in the HyperbolicTests.Java)
>
>> > This PR doesn't include any additional tests. It is often appropriate to add more regression testing when introducing a new implementation of a method.
>> 
>> Thank You Joe for the suggestion. Will add more tests. (This PR passes the tier-1 tanh tests in the HyperbolicTests.Java)
> 
> Yes @vamsi-parasa ; running that test is a good backstop and it is written to be applicable to any implementation of {sinh, cosh, tanh} that meet the general quality-of-implementation criteria for java.lang.Math. To be explicit, the WorstCaseTests.java file, and for good measure all the java.lang.Math tests, should also be run too for a change like this.
> 
> For a hypothetical example, if an intrinsic used different polynomials for different ranges of the input, it would be a reasonable regression tests _for that implementation_ to probe around the boundary of the transition between the polynomials to make sure the monotonicity requirements were being met.
> 
> That kind of check could be written to be generally applicable and be suitable for a regression tests in java/lang/Math or could be suitable for a regression test in the HotSpot area. HTH

Hi Joe(@jddarcy)  and Andrew (@theRealAph) ,

Please see the updates below:

> This PR doesn't include any additional tests. It is often appropriate to add more regression testing when introducing a new implementation of a method.
>

Added 1500 regression tests in HyperbolicTests.java which compare the accuracy of the Math.tanh intrinsic by using StrictMath.tanh (which calls FdLibm.Tanh.compute) as a reference. The tests are passing within 2.5 ulps of the expected result. The tests are fairly exhaustive and also cover the boundary transitions.

> Yes @vamsi-parasa ; running that test is a good backstop and it is written to be applicable to any implementation of {sinh, cosh, tanh} that meet the general quality-of-implementation criteria for java.lang.Math. To be explicit, the WorstCaseTests.java file, and for good measure all the java.lang.Math tests, should also be run too for a change like this.
>
Ran the WorstCaseTests.java and all the tests in java.lang.Math and they're passing on my local machine. 

> For a hypothetical example, if an intrinsic used different polynomials for different ranges of the input, it would be a reasonable regression tests _for that implementation_ to probe around the boundary of the transition between the polynomials to make sure the monotonicity requirements were being met.
> 
Added new tests in HyperbolicTests.java which probe around the various boundaries of transition. 1500 testcases and they passed within 2.5ulps of the reference StrictMath.tanh

> That kind of check could be written to be generally applicable and be suitable for a regression tests in java/lang/Math or could be suitable for a regression test in the HotSpot area. HTH

Please let me know if anything more needs to be added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20657#issuecomment-2322295827

From duke at openjdk.org  Fri Aug 30 20:37:20 2024
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 30 Aug 2024 20:37:20 GMT
Subject: RFR: 8338694: x86_64 intrinsic for tanh using libm [v2]
In-Reply-To: <cM6_tGA-3aKQtrxZ6lc6yUyk0fg-2ud9kdwdB-f5pgE=.188b3347-38e4-49f1-9bca-d6a24e836bfd@github.com>
References: <ph5mYR6pU9oTli8bzwVvLrV7XJW5UV5ificQ_J99sR8=.d288d03e-7df4-4ebe-a0c5-ead4510dfa9a@github.com>
 <cM6_tGA-3aKQtrxZ6lc6yUyk0fg-2ud9kdwdB-f5pgE=.188b3347-38e4-49f1-9bca-d6a24e836bfd@github.com>
Message-ID: <vsgw6NPhagZ_r5G1NK6os7myuoYzVlGD-eaz61-SuBQ=.dc91ab72-c46d-40df-90b2-ea6615d5f3de@github.com>

On Wed, 28 Aug 2024 13:14:22 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add stub initialization and extra tanh tests
>
> src/hotspot/share/jvmci/jvmciCompilerToVM.hpp line 114:
> 
>> 112:     static address dcos;
>> 113:     static address dtan;
>> 114:     static address dtanh;
> 
> Could you please add the following initializing code?
> 
> diff --git a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
> index 9752d7edf99..1db9be70db0 100644
> --- a/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
> +++ b/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
> @@ -259,6 +259,17 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) {
>    SET_TRIGFUNC(dpow);
>  
>  #undef SET_TRIGFUNC
> +
> +#define SET_TRIGFUNC_OR_NULL(name)                              \
> +  if (StubRoutines::name() != nullptr) {                        \
> +    name = StubRoutines::name();                                \
> +  } else {                                                      \
> +    name = nullptr;                                             \
> +  }
> +
> +  SET_TRIGFUNC_OR_NULL(dtanh);
> +
> +#undef SET_TRIGFUNC_OR_NULL
>  }
>  
>  static jboolean is_c1_supported(vmIntrinsics::ID id){
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index fea308503cf..189c1465589 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -126,6 +126,7 @@
>    static_field(CompilerToVM::Data,             dsin,                                   address)                                      \
>    static_field(CompilerToVM::Data,             dcos,                                   address)                                      \
>    static_field(CompilerToVM::Data,             dtan,                                   address)                                      \
> +  static_field(CompilerToVM::Data,             dtanh,                                  address)                                      \
>    static_field(CompilerToVM::Data,             dexp,                                   address)                                      \
>    static_field(CompilerToVM::Data,             dlog,                                   address)                                      \
>    static_field(CompilerToVM::Data,             dlog10,                                 address)                                      \

Thank You Yudi! Please see the code updated with your suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20657#discussion_r1739390171

From cjplummer at openjdk.org  Fri Aug 30 20:47:20 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 Aug 2024 20:47:20 GMT
Subject: RFR: 8328877: [JNI] The JNI Specification needs to address the
 limitations of integer UTF-8 String lengths [v2]
In-Reply-To: <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
References: <XtqkJboO-xa4eEasMz_602GzYHuzk7tFb15FxQQ7TMg=.b4aeb416-f5c1-4a5c-bfb1-e2bb258ff597@github.com>
 <2e6s-MMPDH7HvC8BHvUV4SzjJximYjZr44OL_CnwFWc=.042e04ef-ba2c-4964-9973-4d9963a6410a@github.com>
Message-ID: <SYJj6vBnDnUNNJAXuWwWW1m_91b_eyMDf0oJp2aliYg=.1966ffb7-837b-447d-9c74-73e99d89a6e1@github.com>

On Fri, 30 Aug 2024 05:21:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of a new method added to the JNI specification.
>> 
>> From the CSR request:
>> 
>> The `GetStringUTFLength` function returns the length as a `jint` (`jsize`) value and so is limited to returning at most `Integer.MAX_VALUE`. But a Java string can itself consist of `Integer.MAX_VALUE` characters, each of which may require more than one byte to represent them in modified UTF-8 format.** It follows then that this function cannot return the correct answer for all String values and yet the specification makes no mention of this, nor of any possible error to report if this situation is encountered.
>> 
>> **The modified UTF-8 format used by the VM can require up to six bytes to represent one unicode character, but six byte characters are stored as UTF16 surrogate pairs. Hence the most bytes per character is 3, and so the maximum length is 3*`Integer.MAX_VALUE`. With compact strings this reduces to 2*`Integer.MAX_VALUE`.
>> 
>> Solution
>> 
>> Deprecate the existing JNI `GetStringUTFLength` method noting that it may return a truncated length, and add a new method, JNI `GetStringUTFLengthAsLong` that returns the string length as a `jlong` value.
>> 
>> ---
>> 
>> We also add a truncation warning to `GetStringUTFLength` under -Xcheck:jni
>> 
>> There are some incidental whitespace changes in `src/hotspot/os/posix/dtrace/hotspot_jni.d` along with the new method entries.
>> 
>> Testing:
>>  - new test added
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude test on 32-bit

Overall it looks good to me, although I don't have experience adding a new JNI API (the dtrace probes were new to me), but it seems you are following what is already in place for other functions, and the testing looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20784#pullrequestreview-2273477700

From bpb at openjdk.org  Fri Aug 30 21:05:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Aug 2024 21:05:27 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on MS
 Windows
Message-ID: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>

Return the final path derived from the string returned by `canonicalize0()`.

-------------

Commit messages:
 - 8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows

Changes: https://git.openjdk.org/jdk/pull/20801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8003887
  Stats: 48 lines in 2 files changed: 24 ins; 20 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20801/head:pull/20801

PR: https://git.openjdk.org/jdk/pull/20801

From bpb at openjdk.org  Fri Aug 30 21:05:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Aug 2024 21:05:27 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows
In-Reply-To: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
Message-ID: <UWAefqOfN9-Vmwxm72PjOtJJq7o0rEPWEqwPAyGc8N4=.d1525da3-4398-46e0-b3e2-d51df0495c82@github.com>

On Fri, 30 Aug 2024 20:59:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Return the final path derived from the string returned by `canonicalize0()`.

The variable `GetFinalPathNameByHandle_func` is removed from the native code as we no longer care about Windows versions preceding Vista.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20801#issuecomment-2322329811

From mcimadamore at openjdk.org  Fri Aug 30 21:23:25 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 30 Aug 2024 21:23:25 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v5]
In-Reply-To: <SXsdTrBQikLZGm2vcIgeWxPJryXqi5vG9okm0hlZBaE=.c7976609-d3e1-45fb-a591-ffe1cae37b9d@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <YvQbJER-uhUvUFlC8CjbzxLERsGiO2Gjz056Xmu0P6Y=.ae20f519-23e4-406e-8c6e-38c3bb90f422@github.com>
 <_d0I6wZKc04uZ0w23ZISr87h3V2t3KgTZVJwUnKrNaM=.6b8c8e63-8577-4f76-a661-5c717bdfdeda@github.com>
 <biCpvmReJMNUQve5xnlSAPK17cdXLi-WTe743FTJRds=.ae8d33cb-d1d5-4e9a-9572-41d6ec6fc2e1@github.com>
 <epQydaSbrbKCR-tlvtu8ZaTktJ3ERoMU-J94ANOvw2o=.df74bff1-cf73-493f-ac1e-e44df9618b60@github.com>
 <NzCJq9kwXq-nCqZ_W2Gko5u-yQ3wVBSpEt8F8v-ZgD8=.b9604e02-081d-484e-9792-2145e945571d@github.com>
 <QUYohlnul_-0Kizau6sBGK2eJQ-oq-waa6F8HYsPCpw=.82701e45-7d6d-4f1b-b7e0-863234427a2c@github.com>
 <SXsdTrBQikLZGm2vcIgeWxPJryXqi5vG9okm0hlZBaE=.c7976609-d3e1-45fb-a591-ffe1cae37b9d@github.com>
Message-ID: <K2QIdtzP5IKLCY4D4CNEgeFKLbX1EaHZzjxS06Xs7io=.a1943a30-f207-4fdd-85b9-4ba23e4d4ec1@github.com>

On Fri, 30 Aug 2024 15:31:26 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> good point: relatively to the baseline, nope, cause the new version improve regardless, even when the new version got high branch misses

My feeling is that the intrinsic we have under the hood must be doing some similar branching to fixup the tail of the loop. In a way, what you are measuring is the worst possible case: a method that works on segments of different sizes, but whose size is so small not to benefit much from loop optimizations. Because of that, the cost of branching dominates everything. I think it's unavoidable to have some kind of jitter for small sizes. (e.g. even if we could write a single loop using `byte` and C2 auto-vectorized all that - there's going to be a loop tail where we need to fill in the contents for some remainder size - and that logic is going to be [branchy](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java#L146)).

On the other hand, the main point of this PR is to avoid the intrinsics for segments smaller than a certain size as jumping into the intrinsics seem to have some fixed cost that doesn't make it worth it for such small segments. (a similar situation arises for `copy` and `mismatch` - to an even greater extent).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2322353850

From bpb at openjdk.org  Fri Aug 30 21:39:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 Aug 2024 21:39:47 GMT
Subject: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on
 MS Windows [v2]
In-Reply-To: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
References: <dQbsZb3ZT91yIRnomwAsCERngVZ7exlz8e20jNNKGss=.979e7ee5-d64a-4416-9233-318b15e5ebcf@github.com>
Message-ID: <7u-hEE_QjFnpdzRCAQGkreWAKRczOlSPZhEiy2YfFxs=.c594dcf2-573c-4082-8515-f8d6eef999c2@github.com>

> Return the final path derived from the string returned by `canonicalize0()`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8003887: Free value allocated in and returned by getFinalPath()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20801/files
  - new: https://git.openjdk.org/jdk/pull/20801/files/10fa297f..1cc1855b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20801&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20801&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20801/head:pull/20801

PR: https://git.openjdk.org/jdk/pull/20801

From duke at openjdk.org  Fri Aug 30 22:07:24 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 30 Aug 2024 22:07:24 GMT
Subject: RFR: 8338967: Improve performance for MemorySegment::fill [v10]
In-Reply-To: <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
References: <ZYszJlDn1YYSakfyHnI0oRjvGHcCYCD9xnbGiX125-E=.e41d1ef0-9fc6-442e-b872-a5852ba718ca@github.com>
 <qj2UVeLVwNMT4A5r_4-ivlNh0koE1mQwGCJkSe2qR14=.6df10c36-e700-4293-8995-ca1b41a93c49@github.com>
Message-ID: <4rq3-ERDHkTJqXA32I-ynjWrmZRI0ABlj-oQqkbPabg=.33dec849-fb55-4285-8861-531f149ca559@github.com>

On Fri, 30 Aug 2024 10:51:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> The performance of the `MemorySegment::fil` can be improved by replacing the `checkAccess()` method call with calling `checkReadOnly()` instead (as the bounds of the segment itself do not need to be checked).
>> 
>> Also, smaller segments can be handled directly by Java code rather than transitioning to native code.
>> 
>> Here is how the `MemorySegment::fill` performance is improved by this PR:
>> 
>> ![image](https://github.com/user-attachments/assets/ee29fdf0-a7cf-4d5b-bb6b-278b01d97e3c)
>> 
>> Operations involving 8 or more bytes are delegated to native code whereas smaller segments are handled via a switch rake.
>> 
>> It should be noted that `Arena::allocate` is using `MemorySegment::fil`. Hence, this PR will also have a positive effect on memory allocation performance.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert copyright year
>  - Move logic back to AMSI

It is a good analysis; effectively even fill will likely have to handle tail/head for reminder bytes - and this will eventually lead to, more or less, some branchy code: this can be a tight loop, a series of if and byte per byte write (7 ifs), or as it is handled in this pr.
All of these strategies are better than what we have now, probably because the existing instrinsics still perform some poor decision, but I haven't dug yet into perfasm out to see what it does wrong; maybe is something which could be fixed in the intrinsic itself?
Said that, the 3 approaches I have mentioned could be interesting to check against both predictable or not workloads, I see pros and cons in all of them, TBH, although just as an academic exercise.

One qq; by reading https://bugs.openjdk.org/browse/JDK-8139457 it appears to me that via some unsafe mechanism we could avoid being branchy;
If a single byte[] still need to be 8 bytes (or 16?) aligned, we could just use long and write past the end of the array? Is it a safe assumption?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20712#issuecomment-2322414069

From scolebourne at openjdk.org  Sat Aug 31 08:48:21 2024
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sat, 31 Aug 2024 08:48:21 GMT
Subject: RFR: 8337279: Optimize format instant [v7]
In-Reply-To: <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <WR4VFQQBMNtkhd0I01eEVRTcY5fJOpNw3XDNsvNS2dc=.e2d72550-6ad5-4a85-8185-7880357b47c3@github.com>
Message-ID: <WTcYNlHgBKuxwvSUnAb7P49OP0c-cXrMIM2KMdkOntI=.7ddb4a71-d101-4c96-ae08-0eafaa4c0752@github.com>

On Tue, 27 Aug 2024 23:49:50 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> 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 nine additional commits since the last revision:
> 
>  - Speed up Instant.toString using JavaTimeAccess
>  - add JavaTimeAccess SharedSecrets
>  - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
>  - breaking out the printNano methods
>  - copyright
>  - Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>    
>    Co-authored-by: Stephen Colebourne <scolebourne at joda.org>
>  - 1. fix handle fraction == -1
>    2. Split two methods to make codeSize less than 325
>  - add comment
>  - optimize format instant

The change looks OK from my perspective, however I would want someone with experience of `SharedSecrets` to comment

-------------

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2273791076

From egahlin at openjdk.org  Sat Aug 31 09:46:18 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sat, 31 Aug 2024 09:46:18 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, 
 ConstantDesc) [v2]
In-Reply-To: <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
 <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
Message-ID: <I9dU52-vh_fAkzFHpW6hxMStuM71XR7YMulgnl8Agd4=.fa730b6d-492a-4d4f-bbc7-f426327aa365@github.com>

On Thu, 29 Aug 2024 21:46:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and confusing. Users should almost always use `loadConstant(ConstantDesc)` for optimized instructions, or use specific factories `iconst_0` etc. or `bipush` with arguments or `LoadConstantInstruction.of` if they want to specify the exact type of LDC opcode.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move bipush and sipush fix from Opcode cleanup to this patch

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 679:

> 677:         getEventConfiguration(blockCodeBuilder);
> 678:         // stack: [EW] [EW] [EC]
> 679:         blockCodeBuilder.loadConstant(eventTypeId);

Does this means an int (single slot) can be pushed if the event type id happens to be below Integer.MAX_VALUE?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20779#discussion_r1739648107

From duke at openjdk.org  Sat Aug 31 10:21:18 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 31 Aug 2024 10:21:18 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, 
 ConstantDesc) [v2]
In-Reply-To: <I9dU52-vh_fAkzFHpW6hxMStuM71XR7YMulgnl8Agd4=.fa730b6d-492a-4d4f-bbc7-f426327aa365@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
 <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
 <I9dU52-vh_fAkzFHpW6hxMStuM71XR7YMulgnl8Agd4=.fa730b6d-492a-4d4f-bbc7-f426327aa365@github.com>
Message-ID: <3nRTm2gxI9dxuiBenhMFUsWsWciswcbexCv-uqQf_SI=.c13dc894-e66f-427e-a94b-52d6e9b2d992@github.com>

On Sat, 31 Aug 2024 09:42:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move bipush and sipush fix from Opcode cleanup to this patch
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 679:
> 
>> 677:         getEventConfiguration(blockCodeBuilder);
>> 678:         // stack: [EW] [EW] [EC]
>> 679:         blockCodeBuilder.loadConstant(eventTypeId);
> 
> Does this means an int (single slot) can be pushed if the event type id happens to be below Integer.MAX_VALUE?

No, because?the?type of?`eventTypeId` is?`long`, so?the?boxed?type is?`Long`, therefore the?only instructions are?`LDC2_W`, `LCONST_0`, and?`LCONST_1`:

https://github.com/openjdk/jdk/blob/86c4104d86d91fefae3d9dc11e4f2684d29fcde1/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L639-L642

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20779#discussion_r1739652453

From duke at openjdk.org  Sat Aug 31 10:59:29 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 31 Aug 2024 10:59:29 GMT
Subject: RFR: 8304846: Provide a shared utility to dump generated classes
 defined via Lookup API [v8]
In-Reply-To: <pxr3PU4TR2TbPviyI-iMPQ6ZtoPmAOqK5T8fWC9S5CQ=.1d814810-9e8d-4ddd-b63d-6e8648028fcb@github.com>
References: <lLamM86s9WeIZf1DFeIwo3Sz9ZykSggaQm_Y6tNs3Ng=.a3be4ab9-b8ae-4bf0-94a4-eee798b65dc0@github.com>
 <pxr3PU4TR2TbPviyI-iMPQ6ZtoPmAOqK5T8fWC9S5CQ=.1d814810-9e8d-4ddd-b63d-6e8648028fcb@github.com>
Message-ID: <7P7Gg5-zFCAyehGSUCJ31WFavgCijxmNZPkwx6X0DIk=.07706ca9-e265-4566-bded-24a4024138e4@github.com>

On Mon, 3 Apr 2023 22:32:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This implements a shared utility to dump generated classes defined as normal/hidden classes via `Lookup` API.   This replaces the implementation in `LambdaMetaFactory` and method handle implementation that dumps the hidden class bytes on disk for debugging.   
>> 
>> For classes defined via `Lookup::defineClass`, `Lookup::defineHiddenClass` and `Lookup::defineHiddenClassWithClassData`, by default they will be dumped to the path specified in `-Djava.lang.invoke.Lookup.dumpClasses=<dumpDir>` 
>> 
>> The hidden classes generated for lambdas, `LambdaForms` and method handle implementation use non-default dumper so that they can be controlled via a separate system property and path as in the current implementation.
>> 
>> To dump lambda proxy classes, set this system property:
>>    -Djdk.internal.lambda.dumpProxyClasses=<dumpDir>
>> 
>> To dump LambdaForms and method handle implementation, set this system property:
>>    -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true
>>    
>> P.S. `ProxyClassesDumper` is renamed to `ClassFileDumper` but for some reason, it's not shown as rename.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update test

src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java line 566:

> 564:          * @return the generated concrete TopClass class
> 565:          */
> 566:         @SuppressWarnings("removal")

This?`@SuppressWarnings` is?no?longer?needed:

Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13182#discussion_r1739683678

From dholmes at openjdk.org  Sat Aug 31 11:57:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 31 Aug 2024 11:57:19 GMT
Subject: RFR: 8338768: Introduce runtime lookup to check for static builds
 [v2]
In-Reply-To: <eQv90nmAArKzh8kjaZ1oGg5jInJTI6J7jxJ8sjIxEXI=.a8ba6456-c192-44eb-8bad-f6ee245239e8@github.com>
References: <Qb-hEpMNtfzU9tOBdegv0PcIbXgmtKAQXVCOdhKZN7E=.73756496-0d50-4661-89d1-d4e9cf8a12d4@github.com>
 <56GIZnufresPSrWCWHPkbY9-qCGlm20L-nbXUi5DFv8=.445586cf-37dc-45ce-9b91-9d0a6c85e5ca@github.com>
 <WjbVrrjlwa6wJw57f2FNXrGvqUUaRdwylCjEI0g1URI=.afc15190-599c-4c3f-9e0f-8990ed87823f@github.com>
 <eQv90nmAArKzh8kjaZ1oGg5jInJTI6J7jxJ8sjIxEXI=.a8ba6456-c192-44eb-8bad-f6ee245239e8@github.com>
Message-ID: <BN6thNr1y0adSkxfbgfj_d2M-bTC-o6t7sbTwwWgv00=.ad19dcd9-fc24-44a9-a9b1-58c479344bb1@github.com>

On Fri, 30 Aug 2024 10:51:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.
>
> @dholmes-ora This PR now has three reviewers approving it. You say you are "not a fan". Does this mean you want to veto this change? Or can you be willing to accept it, even if you do not like it?

@magicus There is no "veto" power in OpenJDK. You have your reviewers, I have to accept it even if I don't like it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2322873797

From liach at openjdk.org  Sat Aug 31 12:26:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 31 Aug 2024 12:26:20 GMT
Subject: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, 
 ConstantDesc) [v2]
In-Reply-To: <3nRTm2gxI9dxuiBenhMFUsWsWciswcbexCv-uqQf_SI=.c13dc894-e66f-427e-a94b-52d6e9b2d992@github.com>
References: <dkTN70iZjA1AJ742a8kcu2HVTFR3VKiYwQtDdB4MLrA=.51a7c77f-b8b7-4e01-877b-d30fdf9a3122@github.com>
 <vJLI4BR1UH2YKE3_rBHQuL_FiGwrcNZksKU3057vo4Y=.83e4eaa6-a51e-4994-9518-60c82f3c9151@github.com>
 <I9dU52-vh_fAkzFHpW6hxMStuM71XR7YMulgnl8Agd4=.fa730b6d-492a-4d4f-bbc7-f426327aa365@github.com>
 <3nRTm2gxI9dxuiBenhMFUsWsWciswcbexCv-uqQf_SI=.c13dc894-e66f-427e-a94b-52d6e9b2d992@github.com>
Message-ID: <TV4th0Tciw3BHoo3jhIxyqELTxXvbVVwA5NAnSTEeHg=.4f06698f-e471-4a25-84b6-47d983b923e9@github.com>

On Sat, 31 Aug 2024 10:16:57 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 679:
>> 
>>> 677:         getEventConfiguration(blockCodeBuilder);
>>> 678:         // stack: [EW] [EW] [EC]
>>> 679:         blockCodeBuilder.loadConstant(eventTypeId);
>> 
>> Does this means an int (single slot) can be pushed if the event type id happens to be below Integer.MAX_VALUE?
>
> No, because?the?type of?`eventTypeId` is?`long`, so?the?boxed?type is?`Long`, therefore the?only instructions are?`LDC2_W`, `LCONST_0`, and?`LCONST_1`:
> 
> https://github.com/openjdk/jdk/blob/86c4104d86d91fefae3d9dc11e4f2684d29fcde1/src/java.base/share/classes/java/lang/classfile/CodeBuilder.java#L639-L642

No, because int and long are not interchangeable in the jvm. Only subints can be replaced by ints.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20779#discussion_r1739708292

From duke at openjdk.org  Sat Aug 31 15:05:58 2024
From: duke at openjdk.org (fabioromano1)
Date: Sat, 31 Aug 2024 15:05:58 GMT
Subject: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v3]
In-Reply-To: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
References: <4m7VakgXtXYwb6jj2pDPLjE-4EeLv7_qQ1-G4W4P_Ww=.95304cda-0181-421e-8676-411eb29ff733@github.com>
Message-ID: <0o2xYGSl7InSp0WvSNE4UYhSg5jdsIM9pF8D0wAxrl8=.0cc9a8b5-f25c-4b65-a983-9f7e9b370701@github.com>

> This implementation of MutableBigInteger.leftShift(int) optimizes the current version, avoiding unnecessary copy of the MutableBigInteger's value content and performing the primitive shifting only in the original portion of the value array rather than in the value yet extended with trailing zeros.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Tests changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20008/files
  - new: https://git.openjdk.org/jdk/pull/20008/files/0f7c8f3d..cac34ef9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20008&range=01-02

  Stats: 56 lines in 4 files changed: 45 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/20008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20008/head:pull/20008

PR: https://git.openjdk.org/jdk/pull/20008