From jvernee at openjdk.org  Thu Jun  1 00:00:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 00:00:07 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <mAeCBDbrGb6TzSKT5qUxvbCOIXl3Ws-quY_tT_eh5i0=.375335d1-ec5c-4d00-972a-8dd5cd2f8589@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
 <PrwfoKow8uEdN33e5T1d34Ogys6kqezIcSaf9hlanlo=.150e96f0-e463-4f51-addc-e3589c20d175@github.com>
 <mAeCBDbrGb6TzSKT5qUxvbCOIXl3Ws-quY_tT_eh5i0=.375335d1-ec5c-4d00-972a-8dd5cd2f8589@github.com>
Message-ID: <yGDaFJm5t3xIXbjWTkJR-AiQbch8yxZmIyM3B2u_QfU=.4d669191-13a7-41de-bb07-0f670277ba03@github.com>

On Wed, 31 May 2023 23:36:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 368:
>> 
>>> 366:  * <h3 id="variadic-funcs">Variadic functions</h3>
>>> 367:  *
>>> 368:  * Variadic functions (e.g. a C function declared with a trailing ellipses {@code ...} at the end of the formal parameter
>> 
>> Optional suggestion for improvement (maybe now, or maybe later). When reading this great para, I understand that there are two things that fall under the "variadic function" umbrella. Some are declared with `...` and some with `()`. This is a very good definition and I wonder if we should expand a bit more on it - e.g. in a way, we never explain what a variadic function is - we merely define it by saying how it is declared in C. I wonder if we might very very briefly explain that in C, some functions (variadic functions) can take a variable number of parameters. Then we go on to say that these functions can be declared in two ways (e.g. ellipsis and prototype-less). Perhaps if we used a bullet-list to define the two ways in which variadic function can be declared, the definition could stand out even more?
>
> Also, should we say somewhere that, for prototype-less functions, `firstVariadicArg` should always have an index of 0 (e.g. any other value is illegal, trivially). It's not super important, just one of those little things that can reinforce understanding.

> Perhaps if we used a bullet-list to define the two ways in which variadic function can be declared, the definition could stand out even more?

Yes, I think this is a good idea. I'll do another pass.

> Also, should we say somewhere that, for prototype-less functions, firstVariadicArg should always have an index of 0

I think this is also a good idea. It help hammer the point home.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212426680

From jvernee at openjdk.org  Thu Jun  1 00:08:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 00:08:06 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <dcy4iyl1NDUbIwBXJOL2p5n0FgiHXPctDjCf64RDmLM=.44f28ab4-d673-4d0f-82a5-4e263ae37a9e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
 <dcy4iyl1NDUbIwBXJOL2p5n0FgiHXPctDjCf64RDmLM=.44f28ab4-d673-4d0f-82a5-4e263ae37a9e@github.com>
Message-ID: <tOB2ITyRdkOeIFo4mBjKQyxw6Jn0l7ZP8AjxapM8Jvw=.3302cb6b-7477-48c1-aab9-2db64872164c@github.com>

On Wed, 31 May 2023 23:41:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 379:
> 
>> 377:  * type {@code float} is converted to {@code double}, and each integral type smaller than {@code int} is converted to
>> 378:  * {@code int}. As such, the native linker will reject attempts to link function descriptors with certain variadic argument
>> 379:  * layouts. Namely, {@linkplain ValueLayout value layouts} that have a carrier type of {@code boolean}, {@code byte},
> 
> Is there any reason as to why you decided to say which layouts are **not** allowed as variadic layouts? I'm wondering whether, if we add more carriers in the future, this list will probably need to be updated? Or do the restriction only involve these "small" types, and stuff like `long double` is always allowed? (in which case the set of unsupported layouts would remain stable over time)

No real reason for the current polarity. The specification explicitly calls out the float -> double conversion, and then for the integral types it refers to ['integer promotions'](https://en.cppreference.com/w/c/language/conversion#Integer_promotions), which is a somewhat complex rule set for assigning ranks to integer types.

So, I think if we add more carriers in the future, we would have to worry about integral types that have a rank less than (unsigned) int when considering this list. This is currently only the types I've listed (though, `char` is a bit of a special case), and this seems relatively stable to me. e.g. `long double` would not need to be added here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212432229

From rriggs at openjdk.org  Thu Jun  1 00:54:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Jun 2023 00:54:05 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
Message-ID: <zHAR5DXhkYn3uQWDxWn_iPcwlRt1WEoYFvwxJR6CeGA=.f9897629-794c-4c95-98f1-fee2fab4790d@github.com>

On Fri, 26 May 2023 19:54:07 GMT, Rudi Horn <duke at openjdk.org> wrote:

>> This change prevents the contents of the internal string array from being copied back when releasing it.
>
> Rudi Horn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Use JNI_ABORT to release string bytes

Looks good for core-libs.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14117#pullrequestreview-1454378418

From dholmes at openjdk.org  Thu Jun  1 02:19:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Jun 2023 02:19:08 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
 <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>
Message-ID: <aKb5HPTm43u3yKnF6OJrji0gpEnZdLs3lbZdFvAmxi4=.0f12cf97-3875-4574-965d-cb55dc76102e@github.com>

On Wed, 31 May 2023 12:07:49 GMT, Severin Gehwolf <sgehwolf 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>>  - Fix whitespace
>>  - 8308090: Add container tests for on-the-fly resource quota updates
>
> Anyone willing to review this?

@jerboaa I can't really review the tests themselves but will run through our CI to see if they cause any problems. If not then they should be okay to add.

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

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1571223360

From dholmes at openjdk.org  Thu Jun  1 03:17:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Jun 2023 03:17:05 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <9UqqGOmXLkrwGFFsrX1IdUCOzdHPOb_bh6rZTi5SgQw=.3b73ac88-8410-409a-b057-cb4837a4a48c@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
 <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
 <ReiS8ogZjIZKxuJNynkiF77HghFDsVTOfbd72sPuXLw=.c5d52edc-01ff-43d0-b199-70a3277b8abe@github.com>
 <LZKxXGJafawMRhT7yMB1T4lRNu06OHsDm-CoscL3m3Y=.4878df0e-2247-4d0e-b650-2f1cce45c69f@github.com>
 <9UqqGOmXLkrwGFFsrX1IdUCOzdHPOb_bh6rZTi5SgQw=.3b73ac88-8410-409a-b057-cb4837a4a48c@github.com>
Message-ID: <1g6MduzNkaQY5jXr2kWzFLhGwbYqFdwQIcIzvGKCVDo=.5e66b381-147a-462c-a028-da5d8df80d76@github.com>

On Wed, 31 May 2023 13:49:46 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

>>> I guess I'll have to wait for OCA verification.
>> 
>> Yes.
>> 
>>> One failure is due to a lack of reviewers, so would you be able to do a review?
>> 
>> Yes, I'll try to do a review later today or tomorrow.
>> 
>> Thanks!
>
>> Yes, I'll try to do a review later today or tomorrow.
> 
> Awesome, thanks!

@pejovica what testing have you done in relation to these changes? We run our container tests in tier5 - have you tested that? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1571265772

From alanb at openjdk.org  Thu Jun  1 06:14:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 06:14:08 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
Message-ID: <rg48fiM9Efq8kBDoNWGcEYOzBN29U5Q6Jvqgkk9td1w=.5b58450b-70ac-41f6-88e4-221b608dd7e6@github.com>

On Fri, 26 May 2023 19:54:07 GMT, Rudi Horn <duke at openjdk.org> wrote:

>> This change prevents the contents of the internal string array from being copied back when releasing it.
>
> Rudi Horn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Use JNI_ABORT to release string bytes

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14117#pullrequestreview-1454646625

From alanb at openjdk.org  Thu Jun  1 06:14:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 06:14:10 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <-XXQZS3DTQRNCh0bgkkX0bCep65VZTxkyho-j_FPCQw=.bfb344b3-26fd-47bc-9903-235fe224346a@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
 <-XXQZS3DTQRNCh0bgkkX0bCep65VZTxkyho-j_FPCQw=.bfb344b3-26fd-47bc-9903-235fe224346a@github.com>
Message-ID: <3OPEPQkI_OgWVT_O460ilZ71m8U08f7nuX-N0IEGAiA=.917940b8-7ee6-4d2b-90f5-752f84c45799@github.com>

On Wed, 31 May 2023 11:49:00 GMT, Rudi Horn <duke at openjdk.org> wrote:

> I have not checked other uses, but they are probably not as critical yet given the special status and frequent use of strings. I can possibly revisit this issue in the future in a further issue / PR if I find time at some stage.

Okay, we should create an issue in JBS to follow-up on that, as there may be other opportunities to avoid the copy back.

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

PR Comment: https://git.openjdk.org/jdk/pull/14117#issuecomment-1571415559

From alanb at openjdk.org  Thu Jun  1 06:19:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 06:19:04 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <hZN6P50ECm2TBpOVhXk0BeznFKlFwrmNkngkF7LPpiE=.ac083c0a-4cac-42d2-91a8-cafd320287df@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

This seems a real backward step. I think some finer grain analysis is needed to work through specific issues, e.g. maybe startup with the regex usage and report back on how much that helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1571420444

From dholmes at openjdk.org  Thu Jun  1 06:23:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Jun 2023 06:23:07 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <iH6ENwf58gay_TnatWAuYvJedw8seybCywur_nbfWDY=.375e51f0-4b85-4dca-9dbb-5f4d4f109fe2@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

These tests didn't fail but I couldn't properly validate the output as we don't seem to save the process stdout file.

But I guess these are okay.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14090#pullrequestreview-1454663420

From duke at openjdk.org  Thu Jun  1 06:58:32 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 1 Jun 2023 06:58:32 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently [v2]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <S0qfvrxlKXqzLuzbqOeqBaqMR0GKEkwXPbpEbk1_sM8=.30ce4d14-d37d-4882-976e-71ba2420ed01@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

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

  8289220: [Shenandoah] TestAllocObjectArrays fails intermittently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/31137f12..51883706

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

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

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

From alanb at openjdk.org  Thu Jun  1 07:12:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 07:12:09 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently [v2]
In-Reply-To: <S0qfvrxlKXqzLuzbqOeqBaqMR0GKEkwXPbpEbk1_sM8=.30ce4d14-d37d-4882-976e-71ba2420ed01@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <S0qfvrxlKXqzLuzbqOeqBaqMR0GKEkwXPbpEbk1_sM8=.30ce4d14-d37d-4882-976e-71ba2420ed01@github.com>
Message-ID: <YCSkW6VOaaFikTA9yi_s_HlFx92HtwSzqujLvEiGM6s=.54d65565-32eb-49c8-83b7-33b498a5127b@github.com>

On Thu, 1 Jun 2023 06:58:32 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: [Shenandoah] TestAllocObjectArrays fails intermittently

I've moved the issue to core-libs/java.util:i18n and change the title of the JBS issue to make it clearer what this is about. Can you adjust the PR description too as this is not ShenandoahGC issue.

@naotoj We might want to think about adding more tests in this area to ensure that the locale cache is stress tested.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1571481539

From jwaters at openjdk.org  Thu Jun  1 07:12:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 07:12:39 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v2]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <KZNH7W5dZuLWeURNi4omOTtCebAICagc05O3rcAf28s=.2d554cd1-914b-4963-aaa6-107614c155db@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

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

  Revert changes to jaccesswalker and add proper cast to offending callsite

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/b925f5ee..628be6b2

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

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

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

From jwaters at openjdk.org  Thu Jun  1 07:14:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 07:14:55 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v3]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <EyfFFtrGk1Z4sJ2tcWSrDTTCiF7GN4s-4pmFnCVEwuc=.2659172b-f087-43a0-9ed3-799a2c5da2e8@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

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

  Nevermind

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/628be6b2..29b93688

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

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

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

From sgehwolf at openjdk.org  Thu Jun  1 08:24:06 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 1 Jun 2023 08:24:06 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <aKb5HPTm43u3yKnF6OJrji0gpEnZdLs3lbZdFvAmxi4=.0f12cf97-3875-4574-965d-cb55dc76102e@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
 <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>
 <aKb5HPTm43u3yKnF6OJrji0gpEnZdLs3lbZdFvAmxi4=.0f12cf97-3875-4574-965d-cb55dc76102e@github.com>
Message-ID: <OgGcVr4ZvTCJer_-l8x-HoSoRCp_Zd_xctAUPpGFWN8=.3c4a216c-b4c4-4753-943e-b14e9c08f686@github.com>

On Thu, 1 Jun 2023 02:16:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anyone willing to review this?
>
> @jerboaa I can't really review the tests themselves but will run through our CI to see if they cause any problems. If not then they should be okay to add.

Thanks @dholmes-ora for running them through your CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1571584032

From shade at openjdk.org  Thu Jun  1 08:58:17 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Jun 2023 08:58:17 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v3]
In-Reply-To: <1uO4gDP7bumdfeOHtKPz_jeu25sS0djvvpAmuI44XjU=.113adccc-9bff-421b-be26-5350e00126d5@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <1uO4gDP7bumdfeOHtKPz_jeu25sS0djvvpAmuI44XjU=.113adccc-9bff-421b-be26-5350e00126d5@github.com>
Message-ID: <S34HlMVyF3cGBD4QDsUB84kW3C39VncNMcwX-BclyKo=.90adc1a6-cb6b-473a-a127-1ba150db15e3@github.com>

On Wed, 31 May 2023 14:53:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
>> 
>> I have some pending work to improve UUID performance, and tests should be improved. 
>> 
>> The improved test still runs in less than 5 seconds on my laptop.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collect collisions and report them once at the end

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14134#issuecomment-1571630408

From duke at openjdk.org  Thu Jun  1 08:58:23 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 1 Jun 2023 08:58:23 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently [v3]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

SUN Guoyun 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:

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/51883706..a09f1b6f

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

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

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

From shade at openjdk.org  Thu Jun  1 08:58:18 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Jun 2023 08:58:18 GMT
Subject: Integrated: 8308803: Improve java/util/UUID/UUIDTest.java
In-Reply-To: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
Message-ID: <C4rbUbqqeG_CTQIdvQq-Yhi9q2B4SR_gaQeOnNh1KJI=.70ed9e2e-9b19-4d20-b0cf-cf812f3b74ab@github.com>

On Wed, 24 May 2023 19:18:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
> 
> I have some pending work to improve UUID performance, and tests should be improved. 
> 
> The improved test still runs in less than 5 seconds on my laptop.

This pull request has now been integrated.

Changeset: 4460429d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4460429d7a50b9a7a99058ef4e5ae36fb30b956f
Stats:     187 lines in 1 file changed: 107 ins; 0 del; 80 mod

8308803: Improve java/util/UUID/UUIDTest.java

Reviewed-by: jpai, rriggs

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

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

From duke at openjdk.org  Thu Jun  1 09:06:09 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Thu, 1 Jun 2023 09:06:09 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <VW0d0G5A5DXLwKTartQijiUdmG2H19-q_PY_iB55DeE=.23d70c40-6a5a-40d2-b060-9dee7fbffe75@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun 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:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

I've done basic testing jtreg tier1-3 and partial shenandoah testing with vmoptions `-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, the results are all OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1571644464

From mdoerr at openjdk.org  Thu Jun  1 09:11:16 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Jun 2023 09:11:16 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v4]
In-Reply-To: <EBUrzkm_HMrEo7qEhu0QHeHB3pKu9QXfMN6hcfFkiTA=.5c8bb4cb-8c68-4591-a988-b167a9eb0e18@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <EBUrzkm_HMrEo7qEhu0QHeHB3pKu9QXfMN6hcfFkiTA=.5c8bb4cb-8c68-4591-a988-b167a9eb0e18@github.com>
Message-ID: <2lQeeCNjItICpnVrL0J04ny7JA-Z7vNXZvitH-oALLc=.93aeb01f-9885-4e26-8c2a-dffb016589c4@github.com>

On Wed, 31 May 2023 18:25:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate import

Thanks for the updates! LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1454964630

From stuefe at openjdk.org  Thu Jun  1 09:13:16 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Jun 2023 09:13:16 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v8]
In-Reply-To: <yVKqFXJf9za_5tyPk84jCYhAKL_BplPd2PRK-USgCrs=.03492282-1aa6-4c87-9a82-b7fa6d43d2fe@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <yVKqFXJf9za_5tyPk84jCYhAKL_BplPd2PRK-USgCrs=.03492282-1aa6-4c87-9a82-b7fa6d43d2fe@github.com>
Message-ID: <hnVoTKS9C48LK2SdKQw8AqL1pkfw-45YfpeXuprXpvM=.0f000464-58c0-49be-bc79-6c7ab15bfe2a@github.com>

On Tue, 30 May 2023 13:19:37 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable JspawnhelperProtocol test on AIX as well because AIX also uses posix_spawn

I gave this a cursory eye, unfortunately i'm too snowed in atm for more. It looks good to me, your reasoning makes sense. Very good job finding and fixing this, and describing the issue. 

About FD_Cloexec , thus can be done in a later change.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13956#pullrequestreview-1454968540

From shade at openjdk.org  Thu Jun  1 09:37:29 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Jun 2023 09:37:29 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v7]
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <tA_3VvHKIjlJ06Q8QWVtlg2Dk77EmjBIllrhRLuFWH4=.c5525e2b-6740-4411-8faa-94b7d118dca9@github.com>

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

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

 - Revert test changes
 - Merge branch 'master' into JDK-8308804-uuid-buffers
 - Simplify clinit
 - Remove the properties
 - Swap lsb/msb
 - Fine-tune exceptions
 - Handle privileged properties
 - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.
 - More touchups
 - Comment updates
 - ... and 3 more: https://git.openjdk.org/jdk/compare/4460429d...fd7eaa1a

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

Changes: https://git.openjdk.org/jdk/pull/14135/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=06
  Stats: 197 lines in 2 files changed: 186 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

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

From sgehwolf at openjdk.org  Thu Jun  1 10:29:12 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 1 Jun 2023 10:29:12 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

I'm concerned about the hard-coding of delimiter values and the added accidential complexity in order to avoid the Regex engine. Note that this test fails due to the delimiter hard-coding:


jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java


This change seems hard to maintain. How would you ensure this won't regress?

src/java.base/linux/classes/jdk/internal/platform/CgroupInfo.java line 110:

> 108:      */
> 109:     static CgroupInfo fromCgroupsLine(String line) {
> 110:         String[] tokens = line.split("\t");

With this change, we now hard-code the expected delimiter and, thus, depend on what the kernel does. Do we have sufficient evidence this hasn't changed/won't change in the future?

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 97:

> 95:         Logger logger = System.getLogger("jdk.internal.platform");
> 96:         logger.log(Level.DEBUG, msg);
> 97:     }

This seems fine and uncontroversial. Suggested name change `log` over `warn`. Perhaps apply this as a separate change?

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 347:

> 345:             int separatorOrdinal = -1;
> 346:             // loop over space-separated tokens
> 347:             for (int tOrdinal = 1, tStart = 0, tEnd = line.indexOf(' '); tEnd != -1; tOrdinal++, tStart = tEnd + 1, tEnd = line.indexOf(' ', tStart)) {

AFAIK, this now also hard-codes the delimiter: A single space. If we really want this custom parser, please add a unit test for it and extract it to a separate class.

A hypothetical line like the following would confuse the parser, setting ordinal to wrong values:

36   35 98:0 /mnt1 /mnt2 rw,noatime master:1 - cgroup /dev/root rw,errors=continue

We'd have: `mountRoot = 98:0`, `mountPath = /mnt1`, `fsType = cgroup` since it expects single space separated values. Seems fragile.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 109:

> 107:     }
> 108: 
> 109:     public static long convertHierachicalLimitLine(String line) {

Pre-existing: typo `convertHierarchicalLimitLine`

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 110:

> 108: 
> 109:     public static long convertHierachicalLimitLine(String line) {
> 110:         String[] tokens = line.split(" ");

Again, assumes single space (` `) delimited entries in `memory.stat`. I'm not sure we should hard-code this.

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 144:

> 142:         }
> 143:         // $MAX $PERIOD
> 144:         String[] tokens = cpuMaxRaw.split(" ");

This seems OK. According to https://docs.kernel.org/admin-guide/cgroup-v2.html#format

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 362:

> 360:             return Long.valueOf(0);
> 361:         }
> 362:         String[] tokens = line.split(" ");

This seems OK. According to https://docs.kernel.org/admin-guide/cgroup-v2.html#format

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

PR Review: https://git.openjdk.org/jdk/pull/14216#pullrequestreview-1454929344
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212816038
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212909205
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212877800
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212882937
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212891278
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212906805
PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1212907029

From jlahoda at openjdk.org  Thu Jun  1 10:40:06 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 1 Jun 2023 10:40:06 GMT
Subject: RFR: 8308856: jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo
 math problem [v2]
In-Reply-To: <z-p190FZCg7etZfM93G6dDG4WFNCDhugc0N0G0czzE0=.ee60798f-2a3a-4f41-8bf4-58c50e9c3ecd@github.com>
References: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
 <z-p190FZCg7etZfM93G6dDG4WFNCDhugc0N0G0czzE0=.ee60798f-2a3a-4f41-8bf4-58c50e9c3ecd@github.com>
Message-ID: <Aozasfx46tH2RLl-3WLQZVjZQLvIFXWATRzQnxiOqgQ=.7ee72b13-3182-41f5-a17b-c2868270047b@github.com>

On Mon, 29 May 2023 08:05:23 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Fix of jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo returning correct zero power of two.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Looks OK to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14148#pullrequestreview-1455145211

From simonis at openjdk.org  Thu Jun  1 11:00:22 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 1 Jun 2023 11:00:22 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
 <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
Message-ID: <7gUtfmZtgqr5ZyxxR24J1CCjWeiFggnWXYpJGcro1Ic=.db7f9ee0-e50f-424a-a7d1-a5ec6853436a@github.com>

On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo 
>>> structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are 
>>> basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
>
>> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
>> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
>> > basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
> 
> Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.

Thanks @RogerRiggs and @tstuefe for your help and patience with this PR. I've now updated the [Release Note](https://bugs.openjdk.org/browse/JDK-8308297) for this change to also include the error scenario described by @mlichtblau .

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

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1571822491

From simonis at openjdk.org  Thu Jun  1 11:00:23 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 1 Jun 2023 11:00:23 GMT
Subject: Integrated: 8307990: jspawnhelper must close its writing side of a
 pipe before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <Xo1VG6qoZNSRJIb8pDufG8D7jmV0uK08QmjTpGM77zc=.b82d0ccb-d37d-4888-b13d-0fb02594fc16@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

This pull request has now been integrated.

Changeset: 39f6d807
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39f6d807dbbe0c9ecd72fe2f76bfbc3091b43c80
Stats:     389 lines in 5 files changed: 351 ins; 11 del; 27 mod

8307990: jspawnhelper must close its writing side of a pipe before reading from it

Reviewed-by: stuefe, rriggs

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

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

From duke at openjdk.org  Thu Jun  1 11:09:26 2023
From: duke at openjdk.org (Marius Lichtblau)
Date: Thu, 1 Jun 2023 11:09:26 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <7gUtfmZtgqr5ZyxxR24J1CCjWeiFggnWXYpJGcro1Ic=.db7f9ee0-e50f-424a-a7d1-a5ec6853436a@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
 <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
 <7gUtfmZtgqr5ZyxxR24J1CCjWeiFggnWXYpJGcro1Ic=.db7f9ee0-e50f-424a-a7d1-a5ec6853436a@github.com>
Message-ID: <gFJpsHnB0iWAgM-q79V0Pltj32mrLBtxzxifHhewj0g=.8cf164f9-8b1e-401e-9573-ef70b6150795@github.com>

On Thu, 1 Jun 2023 10:55:26 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>>> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
>>> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
>>> > basically saying it is better to work on corrupted data rather than reporting an error.
>>> 
>>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
>> 
>> Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.
>
> Thanks @RogerRiggs and @tstuefe for your help and patience with this PR. I've now updated the [Release Note](https://bugs.openjdk.org/browse/JDK-8308297) for this change to also include the error scenario described by @mlichtblau .

Hey @simonis, thank you for taking the time to include our problem in the fix. I appreciate the detailed explanation of your fix!

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

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1571841021

From jwaters at openjdk.org  Thu Jun  1 11:49:24 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 11:49:24 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

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

  Fix the code that is actually warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/29b93688..5fa2d3eb

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

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

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

From asotona at openjdk.org  Thu Jun  1 11:53:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 11:53:13 GMT
Subject: Integrated: 8308856:
 jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo math problem
In-Reply-To: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
References: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
Message-ID: <r3Edbt60h5qfxvY0gtzBvJR8YvpKGq3mb59Fi9Bvc9w=.33bc7b41-b04d-4513-a19a-9c099828593c@github.com>

On Thu, 25 May 2023 12:24:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Fix of jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo returning correct zero power of two.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: a6109bf1
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6109bf1ea2acbebd6a3517813c0b82fdba00c2f
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8308856: jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo math problem

Reviewed-by: jlahoda

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

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

From jwaters at openjdk.org  Thu Jun  1 11:59:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 1 Jun 2023 11:59:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <lmRgb7YaWTkPFfePutzoq4R07kB7DYa7MC--MFfdU5w=.311b471a-bd8f-48c3-8792-beba087c2cc2@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

While looking through the code for this I've come to realize that a staggering amount of code in the accessibility binaries specify longs where unsigned longs would be much more appropriate (see the one example in this PR for instance), wonder if this should also be fixed in the long term too

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1571912910

From sgehwolf at openjdk.org  Thu Jun  1 12:04:08 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 1 Jun 2023 12:04:08 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <G9u89zgphCQ0I7pyWMV3kZACY-JzxBYmMecseqK8hFg=.7c4f8604-005c-43c0-a1fb-3d4888645e1d@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

With my Mandrel hat on I support this change if it helps reducing duplication on the native-image side. It appears, though, we need to find a way that's supportable long-term. It's easy to introduce a new change to this code which accidentally drags in some of those (unwanted) dependencies again.

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

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1571922156

From alanb at openjdk.org  Thu Jun  1 12:14:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:14:06 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <G9u89zgphCQ0I7pyWMV3kZACY-JzxBYmMecseqK8hFg=.7c4f8604-005c-43c0-a1fb-3d4888645e1d@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <G9u89zgphCQ0I7pyWMV3kZACY-JzxBYmMecseqK8hFg=.7c4f8604-005c-43c0-a1fb-3d4888645e1d@github.com>
Message-ID: <Hf_sb5okDsMhTxBWMGG3rCGm6d4IZQI_s7ZhvepeslY=.9b184308-6e86-4cd3-bb38-f22e0f044623@github.com>

On Thu, 1 Jun 2023 12:01:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>  It's easy to introduce a new change to this code which accidentally drags in some of those (unwanted) dependencies again.

I do not like the changes proposed here, they are all crying out for several round cleanups and modernization. One thing that would help is to split this up into a series of changes that could be evaluated, e.g. the use of regex may be a significant part of this so maybe start with that, report back, then work through the iterations to make it clean and maintainable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1571939629

From jlaskey at openjdk.org  Thu Jun  1 12:27:36 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 12:27:36 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v25]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <HRyc0-xwkrLya5U6LFlZ6eHdVGJNxNfTVWWgXv9nMlY=.a8cb4970-59ca-459d-a6cf-0d0b4a6223f9@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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

  Restrict access to unnamed class members when doing separate compilation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/d0189fc2..4bfb8020

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

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

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

From alanb at openjdk.org  Thu Jun  1 12:31:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:31:34 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames
Message-ID: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>

Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.

Code that wants to count stack frames should be directed to use j.l.StackWalker, or if is a a tool, then it can use JVM TI and other tool APIs.

A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

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

Commit messages:
 - Initial commit

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

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

From jlaskey at openjdk.org  Thu Jun  1 12:38:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 12:38:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v26]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <s1U0r4ACsoSsz76y0GYlFEzbhTL21jCpjkhJl0S_qSI=.8e4270e2-40de-47e6-a8de-c8f9f6f1d22f@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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

  Missing Preview feature enum

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/4bfb8020..850a2152

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

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

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

From alanb at openjdk.org  Thu Jun  1 12:45:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:45:10 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
Message-ID: <wxiA1_Wc8s4uudxSLEK26f1KAL4jp4oPf-OkoUOU1f4=.94ddab67-fbf3-4c95-ba70-ecbfa85bd7ce@github.com>

On Wed, 31 May 2023 21:58:44 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust javadoc

I'm very happy where the spec changes have got to in this PR, esp. the module description and allowing a config file be specified with all configuration.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12985#pullrequestreview-1455379216

From alanb at openjdk.org  Thu Jun  1 12:58:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:58:19 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
 <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
 <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>
Message-ID: <SGH897tX6D03BJl_BSq0BWBuwMc9J6tqLPu0PMEIS64=.e442eaba-f702-42bb-8519-27302dd97d3d@github.com>

On Tue, 23 May 2023 18:09:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.

Is this stable now, specifically the "Selecting a main method" section and the behavior change where an instance main takes precedence over an "inherited" static main? Just checking before doing another pass over the method finder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1213112842

From duke at openjdk.org  Thu Jun  1 13:02:11 2023
From: duke at openjdk.org (Brett Okken)
Date: Thu, 1 Jun 2023 13:02:11 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v7]
In-Reply-To: <tA_3VvHKIjlJ06Q8QWVtlg2Dk77EmjBIllrhRLuFWH4=.c5525e2b-6740-4411-8faa-94b7d118dca9@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <tA_3VvHKIjlJ06Q8QWVtlg2Dk77EmjBIllrhRLuFWH4=.c5525e2b-6740-4411-8faa-94b7d118dca9@github.com>
Message-ID: <p_fpNEhLT8JgEpOWu92eG9VJqh5FxYoE1VyS06FOses=.8c48cf8c-0d6c-4a50-a34b-8bb0089a1384@github.com>

On Thu, 1 Jun 2023 09:37:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
>> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Revert test changes
>  - Merge branch 'master' into JDK-8308804-uuid-buffers
>  - Simplify clinit
>  - Remove the properties
>  - Swap lsb/msb
>  - Fine-tune exceptions
>  - Handle privileged properties
>  - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.
>  - More touchups
>  - Comment updates
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/4460429d...fd7eaa1a

src/java.base/share/classes/java/util/UUID.java line 234:

> 232:                     long msb = ByteArray.getLong(buf, 0);
> 233:                     long lsb = ByteArray.getLong(buf, 8);
> 234:                     return fromRandom(msb, lsb);

is there any value in moving this outside of the critical section?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1213117598

From shade at openjdk.org  Thu Jun  1 13:05:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 1 Jun 2023 13:05:12 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v7]
In-Reply-To: <p_fpNEhLT8JgEpOWu92eG9VJqh5FxYoE1VyS06FOses=.8c48cf8c-0d6c-4a50-a34b-8bb0089a1384@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <tA_3VvHKIjlJ06Q8QWVtlg2Dk77EmjBIllrhRLuFWH4=.c5525e2b-6740-4411-8faa-94b7d118dca9@github.com>
 <p_fpNEhLT8JgEpOWu92eG9VJqh5FxYoE1VyS06FOses=.8c48cf8c-0d6c-4a50-a34b-8bb0089a1384@github.com>
Message-ID: <Bbtfy_Jum7_GUliX6tHskkt6XIog2RwiPgpVmOhANLk=.2edb9d8c-77e1-4dc8-a709-48d4c751d8e5@github.com>

On Thu, 1 Jun 2023 12:59:14 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Revert test changes
>>  - Merge branch 'master' into JDK-8308804-uuid-buffers
>>  - Simplify clinit
>>  - Remove the properties
>>  - Swap lsb/msb
>>  - Fine-tune exceptions
>>  - Handle privileged properties
>>  - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.
>>  - More touchups
>>  - Comment updates
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/4460429d...fd7eaa1a
>
> src/java.base/share/classes/java/util/UUID.java line 234:
> 
>> 232:                     long msb = ByteArray.getLong(buf, 0);
>> 233:                     long lsb = ByteArray.getLong(buf, 8);
>> 234:                     return fromRandom(msb, lsb);
> 
> is there any value in moving this outside of the critical section?

I have tried it before, and it gives no benefit, but significantly complicates the code. This is the part under write lock, where we have spent a significant time refilling the buffer. The little improvement we might get here is drowning in those costs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1213121408

From duke at openjdk.org  Thu Jun  1 13:11:26 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 13:11:26 GMT
Subject: Withdrawn: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
Message-ID: <kc61yDMer50HrFEk55-xDCN85ZeKj3D0p4IeXJk89cM=.9d90fcb8-28a8-42b2-8078-f84cfc94d14a@github.com>

On Thu, 25 May 2023 09:14:14 GMT, JoKern65 <duke at openjdk.org> wrote:

> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small adjustments.
> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Thu Jun  1 13:11:24 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 13:11:24 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <tp1fasJhXNuAzfgL4wGOA33z2aejI2mT1hGsOASoDKQ=.37145f46-e3d2-48b7-b6c3-3a673f81c34a@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues  into extra JBS issues. 
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I?ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@mbaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc 
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.  

Thanks for your help so far!

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues into extra JBS issues.
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I?ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@MBaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.

Thanks for your help so far!

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

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1572023812
PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1572024628

From jlaskey at openjdk.org  Thu Jun  1 13:13:20 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 13:13:20 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <SGH897tX6D03BJl_BSq0BWBuwMc9J6tqLPu0PMEIS64=.e442eaba-f702-42bb-8519-27302dd97d3d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
 <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
 <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>
 <SGH897tX6D03BJl_BSq0BWBuwMc9J6tqLPu0PMEIS64=.e442eaba-f702-42bb-8519-27302dd97d3d@github.com>
Message-ID: <QrvF_RpGAqY6aoXDTN4iGaZIYvr7KkvW_eqWEKGY8us=.f987251d-3827-48b9-8ba5-b23c9ea240c6@github.com>

On Thu, 1 Jun 2023 12:55:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.
>
>> Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.
> 
> Is this stable now, specifically the "Selecting a main method" section and the behavior change where an instance main takes precedence over an "inherited" static main? Just checking before doing another pass over the method finder.

I think so - additional changes will be coming from Joe via https://github.com/openjdk/jdk/pull/14165

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1213132645

From alanb at openjdk.org  Thu Jun  1 13:42:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 13:42:18 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
Message-ID: <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>

On Mon, 29 May 2023 10:53:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong link in layout well-formedness doc

src/java.base/share/classes/java/lang/foreign/AddressLayout.java line 116:

> 114:     /**
> 115:      * Returns an address layout with the same carrier, alignment constraint, name and order as this address layout,
> 116:      * but with no target layout

Did you mean to drop the period from the end of the sentence?

src/java.base/share/classes/java/lang/foreign/Arena.java line 269:

> 267:      * @throws IllegalStateException if this arena has already been {@linkplain #close() closed}.
> 268:      * @throws WrongThreadException if this arena is confined, and this method is called from a thread {@code T}
> 269:      * other than the arena's owner thread.

"thread T" hints that "T" will be used later, maybe it's not needed.

src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 38:

> 36: /**
> 37:  * A function descriptor models the signature of a foreign function. A function descriptor is made up of zero or more
> 38:  * argument layouts and zero or one return layout. A function descriptor is used to create

You might want want to put a comma after "layouts" to avoid any ambiguity.

src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 57:

> 55: 
> 56:     /**
> 57:      * {@return the argument layouts of this function descriptor (as an immutable list)}.

I assume this should be "unmodifiable" rather than immutable here.

src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 127:

> 125:     /**
> 126:      * Creates a function descriptor with the given argument layouts and no return layout.  This is useful to model functions
> 127:      * which return no values.

I think I would use "that return" rather than "which return" here.

src/java.base/share/classes/java/lang/foreign/Linker.java line 356:

> 354:  * attach the segment to some existing {@linkplain Arena arena}, so that the lifetime of the region of memory
> 355:  * backing the segment can be managed automatically, as for any other native segment created directly from Java code.
> 356:  * Both these operations are accomplished using the restricted method {@link MemorySegment#reinterpret(long, Arena, Consumer)},

I think this should be "Both of these operations".

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 325:

> 323:      * @return a segment for the newly allocated memory block.
> 324:      * @throws IllegalArgumentException if {@code elementLayout.byteSize() * count} overflows.
> 325:      * @throws IllegalArgumentException if {@code count < 0}.

Another case where the IAE descriptions should probably be combined.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 363:

> 361:      * The returned allocator throws {@link IndexOutOfBoundsException} when a slice of the provided
> 362:      * segment with the requested size and alignment cannot be found.
> 363:      * @implNote A slicing allocator is not <em>thread-safe</em>.

The implNote about thread safety makes me wonder if the SegmentAllocator should say something about thread safety, e.g. should it specify that the allocate methods are thread safe?

src/java.base/share/classes/java/lang/foreign/SequenceLayout.java line 75:

> 73:      * @return a sequence layout with the same characteristics of this layout, but with the given element count.
> 74:      * @throws IllegalArgumentException if {@code elementCount} is negative.
> 75:      * @throws IllegalArgumentException if {@code elementLayout.bitSize() * elementCount} overflows.

Shouldn't the exception descriptions be combined to avoid IAE being listed twice in the generated javadoc?

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 57:

> 55:  *     <li>It can be {@linkplain MemorySegment#set(AddressLayout, long, MemorySegment) stored} inside another memory segment.</li>
> 56:  *     <li>It can be used to access the region of memory backing a global variable (this requires
> 57:  *     {@link MemorySegment#reinterpret(long) resizing} the segment first).</li>

This one probably should be linkplain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213115981
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213119694
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213122457
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213123988
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213126349
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213130078
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213141790
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213171901
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213140568
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213138835

From alanb at openjdk.org  Thu Jun  1 13:43:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 13:43:33 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v4]
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <Z5KdxF-FS6CtSQUg1Jg4iFyxQjLInqQhvXMre-xdbC0=.bd7107e2-c9bf-4660-9009-1dfaa18febbb@github.com>

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

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

 - Sync up from loom repo
 - Merge
 - Sync with loom repo, re-work ScopedValue class description
 - Sync up from loom repo
 - Remove csm.Threads
 - Merge
 - Test should not be in update for main line
 - Sync with loom repo
 - Sync up tests frmo loom repo
 - Sync up with loom repo
 - ... and 5 more: https://git.openjdk.org/jdk/compare/a46b5acc...cc902ce6

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

Changes: https://git.openjdk.org/jdk/pull/13932/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13932&range=03
  Stats: 9267 lines in 40 files changed: 4880 ins; 4325 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/13932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13932/head:pull/13932

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

From asotona at openjdk.org  Thu Jun  1 14:49:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 14:49:25 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s)
Message-ID: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>

Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.

Please review.

Thanks,
Adam

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

Commit messages:
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - added Classfile context parameter to ClasRemapper::remapClass
 - records and methods implementations moved from Classfile to ClassfileImpl
 - added Classfile::buildTo override
 - implementation of Classfile::withOptions(Option... options)
 - added test for StackMapsOption.ALWAYS_GENERATE_STACK_MAPS
 - fixed tests
 - fixed options and jdk/classfile tests
 - fixed jdk/classfile tests
 - ... and 9 more: https://git.openjdk.org/jdk/compare/7d2a7ce2...bcdf0f11

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308899
  Stats: 1579 lines in 106 files changed: 478 ins; 195 del; 906 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From liach at openjdk.org  Thu Jun  1 14:49:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 14:49:29 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s)
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <pJ0ZckI59uozf8hx94Vs0OXZG_A9KedB6_ANNvZKgpM=.63cba4b6-5f3e-4818-b330-942f7cc5f001@github.com>

On Fri, 26 May 2023 14:56:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

A side comment about the API changes:
I think we should recommend users to store Classfile instances in static final variables if sharing is reasonable, like in Module and BindingSpecializer; this way, we can cache class hierarchy resolution information across builds.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 87:

> 85:      * @param r a function mapping attribute names to attribute mappers
> 86:      */
> 87:     record AttributeMapperOption(Function<Utf8Entry, AttributeMapper<?>> attributeMapper) implements Option {

We might want to convert these options into interfaces and move the implementation records into ClassfileImpl, like Brian suggested about ClassHierarchyInfo.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 208:

> 206:      */
> 207:     default ClassModel parse(byte[] bytes) {
> 208:         return new ClassImpl(bytes, (ClassfileImpl)this);

Should we implement this in ClassfileImpl to avoid the redundant cast?

src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 102:

> 100:      * @return re-mapped class file bytes
> 101:      */
> 102:     default byte[] remapClass(ClassModel clm) {

This api should ask for a Classfile object instead. Thankfully, the new Classfile object actually allows us to find potentially bugs in our code (say if the remapped class refer to declared types outside of system class loader)

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

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1452244549
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1211113876
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1211114779
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1211116312

From asotona at openjdk.org  Thu Jun  1 14:49:30 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 14:49:30 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s)
In-Reply-To: <pJ0ZckI59uozf8hx94Vs0OXZG_A9KedB6_ANNvZKgpM=.63cba4b6-5f3e-4818-b330-942f7cc5f001@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <pJ0ZckI59uozf8hx94Vs0OXZG_A9KedB6_ANNvZKgpM=.63cba4b6-5f3e-4818-b330-942f7cc5f001@github.com>
Message-ID: <yPXU2tkzTy7_4HKwsz4-jef3mjwlU2tg6XhosqFeMvU=.45efafb5-cd16-4e11-9626-40f0e0fb8116@github.com>

On Wed, 31 May 2023 05:42:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 87:
> 
>> 85:      * @param r a function mapping attribute names to attribute mappers
>> 86:      */
>> 87:     record AttributeMapperOption(Function<Utf8Entry, AttributeMapper<?>> attributeMapper) implements Option {
> 
> We might want to convert these options into interfaces and move the implementation records into ClassfileImpl, like Brian suggested about ClassHierarchyInfo.

Will fix it, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 208:
> 
>> 206:      */
>> 207:     default ClassModel parse(byte[] bytes) {
>> 208:         return new ClassImpl(bytes, (ClassfileImpl)this);
> 
> Should we implement this in ClassfileImpl to avoid the redundant cast?

yes, several methods should move to ClassfileImpl, thanks.

> src/java.base/share/classes/jdk/internal/classfile/components/ClassRemapper.java line 102:
> 
>> 100:      * @return re-mapped class file bytes
>> 101:      */
>> 102:     default byte[] remapClass(ClassModel clm) {
> 
> This api should ask for a Classfile object instead. Thankfully, the new Classfile object actually allows us to find potentially bugs in our code (say if the remapped class refer to declared types outside of system class loader)

yes, I'll add the parameter, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1212084790
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1212094893
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1212117128

From asemenov at openjdk.org  Thu Jun  1 15:01:37 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 1 Jun 2023 15:01:37 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v4]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

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

  update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/d5b70cb2..b423bd4c

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

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

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

From weijun at openjdk.org  Thu Jun  1 15:07:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Jun 2023 15:07:12 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
Message-ID: <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>

On Thu, 1 Jun 2023 15:02:16 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
>> 
>>> 45: 
>>> 46: // Condition was copied from
>>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 
>> In the current version of the file above, it's written as
>> 
>> #if defined(__APPLE__) && (defined(__ppc__) ||...
>> 
>> Is it better?
>
> done

I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213300305

From asemenov at openjdk.org  Thu Jun  1 15:07:11 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 1 Jun 2023 15:07:11 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
Message-ID: <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>

On Wed, 31 May 2023 13:52:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
> 
>> 45: 
>> 46: // Condition was copied from
>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
> 
> In the current version of the file above, it's written as
> 
> #if defined(__APPLE__) && (defined(__ppc__) ||...
> 
> Is it better?

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213297788

From rriggs at openjdk.org  Thu Jun  1 15:12:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 Jun 2023 15:12:09 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <CQz6LtxBC5kCSbMbevuGFOtizkFImWVKv4leVVoRmFI=.e1d16b2a-4e4b-4e17-9ca3-ac9772552d47@github.com>

On Thu, 1 Jun 2023 06:40:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if is a a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14257#pullrequestreview-1455718528

From jvernee at openjdk.org  Thu Jun  1 15:16:42 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 15:16:42 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v3]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <XWRl54qxs3xz4MckEhWX6rj3EXa1i4UJXaXHuiJKPSs=.e7e053de-5ece-49d1-ba76-ba35e7076658@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
> 
> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
> 
> Testing:
> - local testing on Windows/x64
> - tier1-3 + jdk-tier5 (ongoing)
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

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

  Rework javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/9415e2a1..e806fae5

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

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

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

From jvernee at openjdk.org  Thu Jun  1 15:16:42 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 15:16:42 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <yGDaFJm5t3xIXbjWTkJR-AiQbch8yxZmIyM3B2u_QfU=.4d669191-13a7-41de-bb07-0f670277ba03@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
 <PrwfoKow8uEdN33e5T1d34Ogys6kqezIcSaf9hlanlo=.150e96f0-e463-4f51-addc-e3589c20d175@github.com>
 <mAeCBDbrGb6TzSKT5qUxvbCOIXl3Ws-quY_tT_eh5i0=.375335d1-ec5c-4d00-972a-8dd5cd2f8589@github.com>
 <yGDaFJm5t3xIXbjWTkJR-AiQbch8yxZmIyM3B2u_QfU=.4d669191-13a7-41de-bb07-0f670277ba03@github.com>
Message-ID: <0lphegECNwzPlpGWIkA6SUkOJL2va0alu_w6PQuj7DI=.90f6e24e-f04f-447e-90ca-8609f798205f@github.com>

On Wed, 31 May 2023 23:57:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Also, should we say somewhere that, for prototype-less functions, `firstVariadicArg` should always have an index of 0 (e.g. any other value is illegal, trivially). It's not super important, just one of those little things that can reinforce understanding.
>
>> Perhaps if we used a bullet-list to define the two ways in which variadic function can be declared, the definition could stand out even more?
> 
> Yes, I think this is a good idea. I'll do another pass.
> 
>> Also, should we say somewhere that, for prototype-less functions, firstVariadicArg should always have an index of 0
> 
> I think this is also a good idea. It helps hammer the point home.

Did another pass: https://github.com/openjdk/jdk/pull/14225/commits/e806fae5dc295726846d197dad59e6b0ba715ceb

There are now 3 paragraphs in the javadoc: One that explains what a variadic function is (in C), one  that explains how they are linked using specialized function descriptors, and finally one which explains the limitation on variadic argument layouts.

Additionally I've switched the polarity of the check to be the same as it is in the doc, and aligned the exception message with the terminology in the doc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1213310000

From liach at openjdk.org  Thu Jun  1 15:17:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 15:17:41 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v17]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <tV5dnbqPWgLSOPK2nxGat6OkryLMoNY6Z77iZaCY4z8=.23655767-7f75-414c-9381-e81cdb12edb5@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's faster than old implementation in general.
> 
> 
> Benchmark                                                          Mode  Cnt      Score      Error  Units
> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallLambda           ...

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

 - Some changes per Mandy's review. SecurityManager test fails in this patch
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - stage, needs to fix is mh proxy instance check
 - Merge branch 'master' into explore/mhp-iface
 - Remove assertion, no longer true with teleport definition in MHP
 - Fix tabs, and tests about modules and constructor access
 - stupid faults
 - Revert to shared-class implementation, found a way to deal with security manager
 - ... and 26 more: https://git.openjdk.org/jdk/compare/7fb93a40...56a282e4

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/bd21e68e..56a282e4

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

  Stats: 171579 lines in 3039 files changed: 128195 ins; 20981 del; 22403 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

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

From liach at openjdk.org  Thu Jun  1 15:17:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 15:17:41 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
Message-ID: <GNhAer1mrD46IBan6gx1DiRCatcnesO45kkkYabVd8U=.4059dc05-549e-4e22-98dd-0eb6341e0a23@github.com>

On Sun, 7 May 2023 13:34:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> 
>> Benchmark                                                          Mode  Cnt      Score      Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
>> MethodHandleProxiesAsIFInstanceCreat...
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion, no longer true with teleport definition in MHP

About the security manager: the proposal to change SecurityManager to permit exporting the internal API packages would change the specification of `SecurityManger::checkPackageAccess`. Should I touch that in this patch and potentially require CSR review about SecurityManager changes, or should I go back to the original Proxy-like checks?

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1572243080

From asotona at openjdk.org  Thu Jun  1 15:20:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 15:20:27 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

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

  fixed benchmarks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/bcdf0f11..eae9bed3

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

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

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

From liach at openjdk.org  Thu Jun  1 15:25:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 15:25:12 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
Message-ID: <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>

On Thu, 1 Jun 2023 15:20:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed benchmarks

In fact, I think we can probably mark Classfile as value-based. Then, whether it's created from a factory at every call or if it's cached (my first 2 review comments) no longer matters as much; the caching behavior will be handled by individual option instances (such as class hierarchy caching in the class hierarchy option's resolver)

src/java.base/share/classes/java/lang/Module.java line 1593:

> 1591:     private Class<?> loadModuleInfoClass(InputStream in) throws IOException {
> 1592:         final String MODULE_INFO = "module-info";
> 1593:         var cc = Classfile.of(Classfile.ConstantPoolSharingOption.DO_NOT_SHARE_CONSTANT_POOL);

This `cc` can be stored in a static final field instead.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 55:

> 53: 
> 54:     static Classfile of() {
> 55:         return new ClassfileImpl();

We can create a static final field in `ClassfileImpl` holding a default instance equivalent to that created by `new ClassfileImpl()` and have the `of()` factory return that instance instead.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 840:

> 838:         try {
> 839:             //clone SplitConstantPool with alternate context
> 840:             var cc = Classfile.of(Classfile.StackMapsOption.DO_NOT_GENERATE_STACK_MAPS);

This should set the Class hierarchy resolver, patch dead code, and filter dead labels options from the original context.

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

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1572260124
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213300095
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213302665
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213314212

From jvernee at openjdk.org  Thu Jun  1 15:28:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 15:28:33 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v4]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <f9-JSFMawDZ9cDg7uCtLuqeH6XVYN5Jhhu5RJHlU7O8=.6b877852-c0dc-4a97-8f94-0e09896115c7@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
> 
> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
> 
> Testing:
> - local testing on Windows/x64
> - tier1-3 + jdk-tier5 (ongoing)
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

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

  move prototype-less name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/e806fae5..1f1e22eb

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

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

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

From mcimadamore at openjdk.org  Thu Jun  1 15:28:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 15:28:34 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v3]
In-Reply-To: <XWRl54qxs3xz4MckEhWX6rj3EXa1i4UJXaXHuiJKPSs=.e7e053de-5ece-49d1-ba76-ba35e7076658@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <XWRl54qxs3xz4MckEhWX6rj3EXa1i4UJXaXHuiJKPSs=.e7e053de-5ece-49d1-ba76-ba35e7076658@github.com>
Message-ID: <a8wPc01b-UDwnnDhDYE22UiynGbTvW7PAWauJdf6ht4=.71e9ba1c-986f-4876-8ef6-ae6a52901738@github.com>

On Thu, 1 Jun 2023 15:16:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
>> 
>> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - tier1-3 + jdk-tier5 (ongoing)
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework javadoc

Looks good - I left an optional comment. feel free to ignore (or to deal with that as part of some other PR).

src/java.base/share/classes/java/lang/foreign/Linker.java line 373:

> 371:  * <li>With an empty formal parameter list, such as: {@code void foo();}</li>
> 372:  * </ol>
> 373:  * The latter is often called a <em>prototype-less</em> function as well. The arguments passed in place of the ellipsis,

Would it make sense to move the prototype-less name in the second bullet above?

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

PR Comment: https://git.openjdk.org/jdk/pull/14225#issuecomment-1572258397
PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1213320545

From jvernee at openjdk.org  Thu Jun  1 15:28:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 15:28:34 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v3]
In-Reply-To: <a8wPc01b-UDwnnDhDYE22UiynGbTvW7PAWauJdf6ht4=.71e9ba1c-986f-4876-8ef6-ae6a52901738@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <XWRl54qxs3xz4MckEhWX6rj3EXa1i4UJXaXHuiJKPSs=.e7e053de-5ece-49d1-ba76-ba35e7076658@github.com>
 <a8wPc01b-UDwnnDhDYE22UiynGbTvW7PAWauJdf6ht4=.71e9ba1c-986f-4876-8ef6-ae6a52901738@github.com>
Message-ID: <DMxhvUJPQoM-BRUn2cWvS4LIln8wFB_nXGzWodWMGkQ=.8ddc76c7-86b6-43f9-b567-311e9caa0ae0@github.com>

On Thu, 1 Jun 2023 15:19:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rework javadoc
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 373:
> 
>> 371:  * <li>With an empty formal parameter list, such as: {@code void foo();}</li>
>> 372:  * </ol>
>> 373:  * The latter is often called a <em>prototype-less</em> function as well. The arguments passed in place of the ellipsis,
> 
> Would it make sense to move the prototype-less name in the second bullet above?

Yes, will do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1213324562

From jvernee at openjdk.org  Thu Jun  1 15:32:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 15:32:13 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v4]
In-Reply-To: <f9-JSFMawDZ9cDg7uCtLuqeH6XVYN5Jhhu5RJHlU7O8=.6b877852-c0dc-4a97-8f94-0e09896115c7@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <f9-JSFMawDZ9cDg7uCtLuqeH6XVYN5Jhhu5RJHlU7O8=.6b877852-c0dc-4a97-8f94-0e09896115c7@github.com>
Message-ID: <1g3col7c0paUw_eR0asEOHrdOAR_6QGzsY80myz9RpA=.8dcb2aed-dc29-439e-8d00-18fc83cc907a@github.com>

On Thu, 1 Jun 2023 15:28:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
>> 
>> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - tier1-3 + jdk-tier5 (ongoing)
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move prototype-less name

Thanks for the review! I've updated the CSR with the finalized version of the javadoc. Could you take a look at that as well? https://bugs.openjdk.org/browse/JDK-8309205

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

PR Comment: https://git.openjdk.org/jdk/pull/14225#issuecomment-1572275551

From redestad at openjdk.org  Thu Jun  1 15:35:22 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 1 Jun 2023 15:35:22 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <KnWJ2GDfC3tOc2BdBaC6ZTBunszrwAfwZrFWOIhQZcE=.7d680527-5595-4287-9da9-edd2e7ff2317@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
 <aiC6MkXHICLXZPGIidwhW-iOf2Rrl2vOwuNAzEGmix4=.42794134-5feb-43e8-ad7d-73d4c6e23def@github.com>
 <KnWJ2GDfC3tOc2BdBaC6ZTBunszrwAfwZrFWOIhQZcE=.7d680527-5595-4287-9da9-edd2e7ff2317@github.com>
Message-ID: <3iDPU6qFmt8R5gDA6F9CWnJSgi0iEEo9R89hUWcgcxY=.2e33c1f8-d113-4972-a2d4-ae3fa168f7fe@github.com>

On Mon, 20 Feb 2023 17:03:33 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> We don't fear calling the factory twice for benign races, as the distinct constructor factory instances are behaviorally the same.
>> 
>> The true issue lies in the double getfield operations: Java memory model doesn't require the second read to happen-after a write reflected in the first read, so return this.genericInfo may return null while this.genericInfo == null evaluates to false, in case genericInfo is initialized lazily by another thread. See https://bugs.openjdk.org/browse/JDK-8261404
>
> Hi @liach,
> 
> I think @dholmes-ora is worried about the fields in the object being returned by the getGenericInfo() method and similar. In above case this means fields in class ConstructorRepository.
> I checked it and the entire hierarchy based on sun.reflect.generics.repository.AbstractRepository with subclasses including ConstructorRepository is modeled such that all fields are either:
> - volatile and lazily initialized; or
> - final and initialized in constructor
> 
> Such objects may be published via data race and still be seen consistent on the accepting side.

I don't have any issue with this version. Making the fields volatile is _currently_ unnecessary to ensure correctness -- thanks @plevart for double-checking that all fields in the hierarchy is either `volatile` or `final` -- but adding it is relatively benign (very minor performance cost to a likely-not-very-performance-sensitive code path), reduces fragility and might avoid extraneous allocations of under race conditions.

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

PR Comment: https://git.openjdk.org/jdk/pull/12643#issuecomment-1572275936

From liach at openjdk.org  Thu Jun  1 15:35:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 15:35:23 GMT
Subject: Integrated: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
In-Reply-To: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
Message-ID: <A98NTv7DmmgX-dGDMADScUz5kw-5MN29oqcqgsmdJwk=.7745d08e-23cb-46c1-829b-d8150ecf6ebd@github.com>

On Sun, 19 Feb 2023 18:41:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

This pull request has now been integrated.

Changeset: be36096a
Author:    Chen Liang <liach at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be36096a19bcfc12e789cdeaaa51d746567ac638
Stats:     16 lines in 4 files changed: 8 ins; 0 del; 8 mod

8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

Reviewed-by: stsypanov, redestad

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

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

From mchung at openjdk.org  Thu Jun  1 16:16:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 1 Jun 2023 16:16:08 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <L7yM3yNHocyl9rpn9UoNqsEKGzmT07xsqRTA5ARMUpk=.c344cd89-f1c3-44ab-894c-c51410e62467@github.com>

On Thu, 1 Jun 2023 06:40:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if is a a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14257#pullrequestreview-1455848358

From erikj at openjdk.org  Thu Jun  1 16:21:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 1 Jun 2023 16:21:06 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
Message-ID: <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>

On Fri, 26 May 2023 20:26:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking.
> 
> I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17).
> 
> @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light.
> 

There are no extra options. I suspect it's an issue with the older GCC version. Here is one failing command line:


$ ( cd /home/erik/git/jdk/build/linux-arm32 ; /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -r --sysroot=/var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/arm-linux-gnueabihf/sysroot -o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/GC.o )
/var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libgcc_s.so.1


> The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.

This seems to be Clang specific, so maybe only apply this to Clang and not GCC? Have you measured the difference in link time and concluded that this workaround is needed? If so, how big were the differences? Given that it prints a lot of warnings on mac, I would suggest leaving the partial linking out of this patch to get something in that is actually working. It was included in this patch because of the side effect it had with handling long path names. However, since looking closer at that issue, we were using a different workaround for Clang already and that same workaround should work fine for AR on mac as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1572352386

From naoto at openjdk.org  Thu Jun  1 16:28:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Jun 2023 16:28:06 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <EALFii1S4iLn4SWLDT9AB7R2Ey_w5tMpMEtTi5Jc-wk=.75360c13-4d55-4aa5-a11b-494c1eed7741@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun 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:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

Those SoftReference caches are introduced with this change: https://bugs.openjdk.org/browse/JDK-8196869, and there is a stress test added for it: test/jdk/java/util/Locale/SoftKeys.java
@sunny868 Would you be able to add a JMH test to make sure that your change would not affect the startup time?
@cl4es would you take a look at this change?
Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1572362241

From mchung at openjdk.org  Thu Jun  1 17:17:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 1 Jun 2023 17:17:27 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v17]
In-Reply-To: <tV5dnbqPWgLSOPK2nxGat6OkryLMoNY6Z77iZaCY4z8=.23655767-7f75-414c-9381-e81cdb12edb5@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <tV5dnbqPWgLSOPK2nxGat6OkryLMoNY6Z77iZaCY4z8=.23655767-7f75-414c-9381-e81cdb12edb5@github.com>
Message-ID: <5lE5t4Jkg3tm-bAsVvjQChWCuOJlsZtriy6AvPQuJWM=.e33d2942-1bb1-4e42-aebe-44b4fac5dae7@github.com>

On Thu, 1 Jun 2023 15:17:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> 
>> Benchmark                                                          Mode  Cnt      Score      Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
>> MethodHandleProxiesAsIFInstanceCreat...
>
> 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 36 additional commits since the last revision:
> 
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - stupid faults
>  - Revert to shared-class implementation, found a way to deal with security manager
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/e6f1393e...56a282e4

Thanks for the update.   The security permission check is done regardless of whether it passes the access check.    So the generated code can't access internal API.   For now, I think you can go back to spin bytecode for the check as done in Proxy.  We will consider if it can be replaced by a public API in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1572468328

From jlaskey at openjdk.org  Thu Jun  1 17:18:29 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 17:18:29 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v27]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <2qIU0N6p64RU24IJ3EUaeMFo3GKnYYdd1BdN8cfeI8Y=.4d6b67be-aaf3-44b3-af5e-0d37d28e8414@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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

  Integrate JDK-8308916 and  JDK-8308831 - javax.model

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/850a2152..9d111c26

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

  Stats: 313 lines in 6 files changed: 302 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From apangin at openjdk.org  Thu Jun  1 17:34:11 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Thu, 1 Jun 2023 17:34:11 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v7]
In-Reply-To: <tA_3VvHKIjlJ06Q8QWVtlg2Dk77EmjBIllrhRLuFWH4=.c5525e2b-6740-4411-8faa-94b7d118dca9@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <tA_3VvHKIjlJ06Q8QWVtlg2Dk77EmjBIllrhRLuFWH4=.c5525e2b-6740-4411-8faa-94b7d118dca9@github.com>
Message-ID: <Flga94evDMdNyjgcyJE_PE97ZwQ3Wfj6wOakjKwRfkM=.80c90b3b-583f-471c-af1c-28b9d291a03d@github.com>

On Thu, 1 Jun 2023 09:37:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
>> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Revert test changes
>  - Merge branch 'master' into JDK-8308804-uuid-buffers
>  - Simplify clinit
>  - Remove the properties
>  - Swap lsb/msb
>  - Fine-tune exceptions
>  - Handle privileged properties
>  - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.
>  - More touchups
>  - Comment updates
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/4460429d...fd7eaa1a

src/java.base/share/classes/java/util/UUID.java line 181:

> 179: 
> 180:             private static UUID fromRandom(long msb, long lsb) {
> 181:                 // set version to 3

The comment doesn't match the code. Is it version 4?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1213472422

From prr at openjdk.org  Thu Jun  1 17:46:06 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 1 Jun 2023 17:46:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <HlQFUkd2tqt4ac7yZ5PxNOESR1wumD_kHS55x5FgPp4=.ce755874-c920-4e38-804a-ec344573b1b8@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

I'm not sure I understand the logic here.
I would not want to move to using Java typedefs in places where the windows APIs specify the types they are expecting.
If something comes in from a JNI down-call we should convert it to the type expected by Windows using the name expected by Windows.

Also "compilation" isn't nearly good enough. How is this being tested ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1572518377

From mchung at openjdk.org  Thu Jun  1 18:26:19 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 1 Jun 2023 18:26:19 GMT
Subject: RFR: 8309241: ClassForNameLeak fails intermittently as the class
 loader hasn't been unloaded
Message-ID: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>

Convert `ClassForNameLeak` test to use `jdk.test.lib.util.ForceGC` that would be more reliable in waiting for the class loader to be unloaded.

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

Commit messages:
 - 8309241: ClassForNameLeak fails intermittently as the class loader hasn't been unloaded

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

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

From dnsimon at openjdk.org  Thu Jun  1 19:03:05 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 1 Jun 2023 19:03:05 GMT
Subject: RFR: 8309241: ClassForNameLeak fails intermittently as the class
 loader hasn't been unloaded
In-Reply-To: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
References: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
Message-ID: <9PYd_QedzjigZE0D_I4HcICiEMwMusHUALZd-yeo4LU=.99f749a1-7f17-4f51-ab2e-31447a7eb3eb@github.com>

On Thu, 1 Jun 2023 18:19:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Convert `ClassForNameLeak` test to use `jdk.test.lib.util.ForceGC` that would be more reliable in waiting for the class loader to be unloaded.

Marked as reviewed by dnsimon (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14269#pullrequestreview-1456119608

From mchung at openjdk.org  Thu Jun  1 19:03:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 1 Jun 2023 19:03:05 GMT
Subject: RFR: 8309241: ClassForNameLeak fails intermittently as the class
 loader hasn't been unloaded
In-Reply-To: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
References: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
Message-ID: <HdNilKkj-ZR1Vb2jiCR6ElmFrJl1Y62jYg_grZZOA4U=.7fc1909f-0baf-484b-b274-5f3bf6c143f7@github.com>

On Thu, 1 Jun 2023 18:19:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Convert `ClassForNameLeak` test to use `jdk.test.lib.util.ForceGC` that would be more reliable in waiting for the class loader to be unloaded.

@dougxc has verified that the updated test passes on GraalVM (thanks).

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

PR Comment: https://git.openjdk.org/jdk/pull/14269#issuecomment-1572619219

From jlaskey at openjdk.org  Thu Jun  1 19:09:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 19:09:18 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v28]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <HVtDkCc1zYlCIwt10GViT4WLgAQ1zMK_hz-hIzrdmwU=.c314c9bc-f8e8-4ff5-8ca7-3d2ccfb4eb06@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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

  Integrating JDK-8308913

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/9d111c26..f1acdb04

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

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

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

From asotona at openjdk.org  Thu Jun  1 19:28:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 19:28:11 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
Message-ID: <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>

On Thu, 1 Jun 2023 15:04:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed benchmarks
>
> src/java.base/share/classes/java/lang/Module.java line 1593:
> 
>> 1591:     private Class<?> loadModuleInfoClass(InputStream in) throws IOException {
>> 1592:         final String MODULE_INFO = "module-info";
>> 1593:         var cc = Classfile.of(Classfile.ConstantPoolSharingOption.DO_NOT_SHARE_CONSTANT_POOL);
> 
> This `cc` can be stored in a static final field instead.

Yes, we can avoid repeated construction of default class hierarchy resolver here.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 55:
> 
>> 53: 
>> 54:     static Classfile of() {
>> 55:         return new ClassfileImpl();
> 
> We can create a static final field in `ClassfileImpl` holding a default instance equivalent to that created by `new ClassfileImpl()` and have the `of()` factory return that instance instead.

Global static default context will hold global shared cached class hierarchy resolver and that we want to avoid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213583268
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213585474

From asotona at openjdk.org  Thu Jun  1 19:39:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 1 Jun 2023 19:39:12 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
Message-ID: <hnv6pYscv-C_QReT1OLqmmO1XJZlzb5xnEIbpfWzMQQ=.3783bb21-f1e6-498a-bdca-50a320696844@github.com>

On Thu, 1 Jun 2023 15:14:52 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed benchmarks
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 840:
> 
>> 838:         try {
>> 839:             //clone SplitConstantPool with alternate context
>> 840:             var cc = Classfile.of(Classfile.StackMapsOption.DO_NOT_GENERATE_STACK_MAPS);
> 
> This should set the Class hierarchy resolver, patch dead code, and filter dead labels options from the original context.

Here the other options are irrelevant. The error report wraps already generated incomplete code attribute into a fake class to be able to print details to the error.
I think even the stack map generation suppression is irrelevant here, will double check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1213598996

From mchung at openjdk.org  Thu Jun  1 19:44:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 1 Jun 2023 19:44:11 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v3]
In-Reply-To: <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
Message-ID: <z90XIdgoAAF2G6JTUjy9GFFIFxGSrfvSwB_vUxjyeYo=.f1d87d46-e241-449b-8fe9-3fb715d02e9b@github.com>

On Wed, 17 May 2023 17:20:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op
>
> 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 eight additional commits since the last revision:
> 
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - make static field var handles lazy and fix NPE in isAccessModeSupported

I think the exact argument for `withInvokeExactBehavior` and `withInvokeBehavior` is swapped.

I studied the patch and it seems a clever idea.   I will do another pass to check if `VarHandle::asDirect` is only invoked when the var handle is doing field access.  

As for the implementation of `LazyStaticVarHandle`, I expect that `makeFieldHandle` can always create the direct var handle (i.e. `FieldStaticReadXXX` var handle) and then wrapped by `LazyStaticVarHandle` similar to how `IndirectVarHandle` does; something like this:


    LazyStaticVarHandle(VarHandle target, Class<?> refc, boolean exact) {
        super(target.vform, exact);
        this.target = target;
        this.refc = refc;
    }


Some overridden methods for example `describeConstable` can simply retrun `target.describeConstable()`.   Do I miss some issue that it can't be implemented that way?

src/java.base/share/classes/java/lang/invoke/LazyStaticVarHandle.java line 126:

> 124:         var delegate = this.delegate;
> 125:         return delegate == null ? (hasInvokeExactBehavior() ? this
> 126:                 : new LazyStaticVarHandle(refc, field, writeAllowedOnFinalFields, false))

Suggestion:

                : new LazyStaticVarHandle(refc, field, writeAllowedOnFinalFields, true))

src/java.base/share/classes/java/lang/invoke/LazyStaticVarHandle.java line 134:

> 132:         var delegate = this.delegate;
> 133:         return delegate == null ? (!hasInvokeExactBehavior() ? this
> 134:                 : new LazyStaticVarHandle(refc, field, writeAllowedOnFinalFields, true))

Suggestion:

                : new LazyStaticVarHandle(refc, field, writeAllowedOnFinalFields, false))

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

PR Review: https://git.openjdk.org/jdk/pull/13821#pullrequestreview-1456188245
PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1572667645
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1213602428
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1213602313

From jlaskey at openjdk.org  Thu Jun  1 20:07:40 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 1 Jun 2023 20:07:40 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v29]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <6uEQPQcZ9b-RmEk42cpkRONL_BSNGufigOGBtKqbGFA=.a37c1ed8-e5b0-4720-8a6a-56c32d056256@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into 8306112
 - Integrating JDK-8308913
 - Integrate JDK-8308916 and  JDK-8308831 - javax.model
 - Missing Preview feature enum
 - Restrict access to unnamed class members when doing separate compilation.
 - Merge branch 'master' into 8306112
 - Remove mandated flag
 - Remove trailing whitespace
 - Add main  tests for inferface/enum/record
 - Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
   
   Author: Jan Lahoda <jlahoda at openjdk.org>
 - ... and 35 more: https://git.openjdk.org/jdk/compare/2bb19724...e39e3fe9

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=28
  Stats: 1648 lines in 41 files changed: 1471 ins; 32 del; 145 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jvernee at openjdk.org  Thu Jun  1 20:27:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 20:27:35 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
Message-ID: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>

On Mon, 29 May 2023 10:53:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong link in layout well-formedness doc

Overall a great cleanup, nice work!

src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 91:

> 89:     /**
> 90:      * Returns a function descriptor with no return layout.
> 91:      * @return a new function descriptor, with no return layout.

Maybe this should be collapsed into a single `{@return ...}` block.

src/java.base/share/classes/java/lang/foreign/Linker.java line 201:

> 199:  * <p>
> 200:  * All native linker implementations operate on a subset of memory layouts. More formally, a layout {@code L}
> 201:  * is supported by a native linker {@code NL} iff:

I think using `iff` (if-and-only-if) is incorrect here, since certain linkers might impose additional constraints. For instance, the fallback linker doesn't support union layouts. Also, we want to further restrict variadic argument layouts as well as part of https://github.com/openjdk/jdk/pull/14225

Maybe we could say that all layouts passed to a linker must _at least_ adhere to the following constraints.

src/java.base/share/classes/java/lang/foreign/Linker.java line 203:

> 201:  * is supported by a native linker {@code NL} iff:
> 202:  * <ul>
> 203:  * <li>{@code L} is a value layout {@code V} and {@code V.withoutName()} is equal to one of the following layout constants:

I think the equivalence this is talking about is MemoryLayout::equals? Maybe a plain link should be added to that method as well?
Suggestion:

 * <li>{@code L} is a value layout {@code V} and {@code V.withoutName()} is {@linkplain MemoryLayout#equals(Object) equal} to one of the following layout constants:

src/java.base/share/classes/java/lang/foreign/Linker.java line 444:

> 442:  * <p>
> 443:  * When an upcall stub is passed to a foreign function, a JVM crash might occur, if the foreign code casts the function pointer
> 444:  * associated with the upcall stub to a type that is incompatible with the type of the upcall stub. Moreover, if the method

This kind of makes it sound like a crash can occur at the time of the cast. I think we should mention that the crash can occur when the function is invoked.
Suggestion:

 * When an upcall stub is passed to a foreign function, a JVM crash might occur, if the foreign code casts the function pointer
 * associated with the upcall stub to a type that is incompatible with the type of the upcall stub, and then attempts to invoke the function through the resulting function pointer. Moreover, if the method

src/java.base/share/classes/java/lang/foreign/Linker.java line 473:

> 471: 
> 472:     /**
> 473:      * Creates a method handle which is used to call a foreign function with the given signature and symbol.

I always think of a function "symbol" mostly as the _name_ of the function, so it seems that "address" would be more correct here. Though, I might be wrong on that. It's hard to find a clear definition of "symbol" that applies to this specific use case.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 54:

> 52:  * There are two leaves in the layout hierarchy, {@linkplain ValueLayout value layouts}, which are used to represent values of given size and kind (see
> 53:  * and {@linkplain PaddingLayout padding layouts} which are used, as the name suggests, to represent a portion of a memory
> 54:  * segment whose contents should be ignored, and which are primarily present for alignment reasons (see {@link MemoryLayout#paddingLayout(long)}).

I think this `(see {@link MemoryLayout#paddingLayout(long)})` could be removed as well now, as the link was inlined.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 149:

> 147:  * Some layout path elements, said <em>open path elements</em>, can select multiple layouts at once. For instance,
> 148:  * the open path elements {@link PathElement#sequenceElement()}, {@link PathElement#sequenceElement(long, long)} select
> 149:  * an unspecified element in a sequence layout. A var handles derived from a layout path containing one or more

Suggestion:

 * an unspecified element in a sequence layout. A var handle derived from a layout path containing one or more

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 216:

> 214:  * layout path can be thought of as a function which updates the current layout {@code C_i-1} to some other layout
> 215:  * {@code C_i}. That is, for each path element {@code E1, E2, ... En}, in a layout path {@code P}, we compute
> 216:  * {@code C_i = f_i(C_i-1)}, where {@code f_i} is the selection function expressed the path element under consideration,

Suggestion:

 * {@code C_i = f_i(C_i-1)}, where {@code f_i} is the selection function expressing the path element under consideration,

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 219:

> 217:  * denoted as {@code E_i}. The final layout {@code C_i} is also called the <em>selected layout</em>.
> 218:  * <p>
> 219:  * A layout path P is considered well-formed for an initial layout {@code C_0} if all its path elements

Using `@code`, as above:
Suggestion:

 * A layout path {@code P} is considered well-formed for an initial layout {@code C_0} if all its path elements

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 271:

> 269:      * @apiNote This can be useful to compare two layouts that have different names, but are otherwise equal.
> 270:      *
> 271:      * @return a memory layout with the same characteristics as this layout, but with no name.

Maybe `{@return ...}` should also be used here and for the above `withName` method.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 297:

> 295:      *
> 296:      * @param byteAlignment the layout alignment constraint, expressed in bytes.
> 297:      * @return a memory layout with the same characteristics of this layout, but with the given alignment constraint.

Same here.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 325:

> 323:      *     <li>its return type is {@code long};</li>
> 324:      *     <li>it has a leading parameter of type {@code MemorySegment}, corresponding to the memory segment
> 325:      *     to be accessed;</li>

This is not correct. The returned method handle does not accept a MemorySegment.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 326:

> 324:      *     <li>it has a leading parameter of type {@code MemorySegment}, corresponding to the memory segment
> 325:      *     to be accessed;</li>
> 326:      *     <li>it has as many parameters of type {@code long}, one for each <a href=#open-path-elements>open path elements</a>

Grammatically, I think this should either use the singular form "open path element", or use "each *of the*".
Suggestion:

     *     <li>it has as many parameters of type {@code long}, one for each <a href=#open-path-elements>open path element</a>

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 364:

> 362:      *     selected value layout;</li>
> 363:      *     <li>it has as many access coordinates of type {@code long}, one for each
> 364:      *     <a href=#open-path-elements>open path elements</a> in the provided layout path. The order of these access

Suggestion:

     *     <a href=#open-path-elements>open path element</a> in the provided layout path. The order of these access

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 393:

> 391:      * <p>
> 392:      * Multiple paths can be chained, by using <a href=#deref-path-elements>dereference path elements</a>.
> 393:      * A dereference path element allows to obtain a native memory segment whose base address is the address value

"allows to obtain" doesn't sound right to me. I think it should either be "allows _subject_ to obtain" (where _subject_ is for instance "the user"), or it could also be "allows obtaining" (the the former seems more natural to me).
Suggestion:

     * A dereference path element allows the user to obtain a native memory segment whose base address is the address value

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 418:

> 416:      *
> 417:      * @param elements the layout path elements.
> 418:      * @return a var handle that accesses a memory segment at the offset selected by the given layout path.

This doesn't seem quite right. It is not the memory segment which is found at the offset given by the layout path, it is the base address.

Maybe:
Suggestion:

     * @return a var handle that accesses a memory segment whose base address is found at the offset selected by the given layout path.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 436:

> 434:      *     <li>its return type is {@code MemorySegment};</li>
> 435:      *     <li>it has a leading parameter of type {@code MemorySegment}, corresponding to the memory segment
> 436:      *     to be accessed;</li>

Maybe accessed -> sliced, since no direct memory access occurs here.
Suggestion:

     *     to be sliced;</li>

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 470:

> 468:      * @throws IllegalArgumentException if the layout path contains one or more <a href=#deref-path-elements>dereference path elements</a>.
> 469:      * @throws IllegalArgumentException if the layout path contains one or more path elements that select one or more
> 470:      * sequence element indices, such as {@link PathElement#sequenceElement(long)} and {@link PathElement#sequenceElement(long, long)}).

Looks like the first method link should like to `PathElement#sequenceElement()` instead? (I think using a bound `sequenceElement` is fine right?)

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 499:

> 497:      *     an address layout as its target layout.</li>
> 498:      * </ul>
> 499:      * Sequence path elements selecting more than a sequence element layout are called

Suggestion:

     * Sequence path elements selecting more than one sequence element layout are called

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 645:

> 643:      * is 1. As such, regardless of its size, in the absence of an {@linkplain #withByteAlignment(long) explicit}
> 644:      * alignment constraint, a padding layout does not affect the alignment constraint of the group or sequence layout
> 645:      * it is nested into.

It is possible to override the alignment constraints of group and sequence layouts, so maybe this should say _natural alignment_.
Suggestion:

     * alignment constraint, a padding layout does not affect the natural alignment of the group or sequence layout
     * it is nested into.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 938:

> 936:      * the properties of this segment. For instance, if this segment is a {@linkplain #isReadOnly() read-only segment},
> 937:      * then the resulting buffer is also {@linkplain ByteBuffer#isReadOnly() read-only}. Additionally, if this is a native
> 938:      * segment, the resulting buffer is a {@linkplain ByteBuffer#isDirect() direct buffer}.

(Pre-existing, but seemed useful to mention) Rather than giving a few examples with 'For instance', perhaps this should more explicitly list _all_ the properties that are reflected in the returned buffer (not sure if there are more).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 943:

> 941:      * the returned buffer's {@linkplain ByteBuffer#capacity() capacity} and {@linkplain ByteBuffer#limit() limit}
> 942:      * are both set to this segment' {@linkplain MemorySegment#byteSize() size}. For this reason, a byte buffer cannot be
> 943:      * returned if this segment' size is greater than {@link Integer#MAX_VALUE}.

Suggestion:

     * returned if this segment's size is greater than {@link Integer#MAX_VALUE}.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 951:

> 949:      * <p>
> 950:      * If this segment is {@linkplain #isAccessibleBy(Thread) accessible} from a single thread, calling read/write I/O
> 951:      * operations on the resulting buffer might result in an unspecified exceptions being thrown. Examples of such problematic operations are

Suggestion:

     * operations on the resulting buffer might result in unspecified exceptions being thrown. Examples of such problematic operations are

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 2196:

> 2194:      * with the alignment constraint</a> in the source element layout.
> 2195:      * @throws IllegalArgumentException if {@code srcLayout.byteAlignment() > srcLayout.byteSize()}.
> 2196:      * @throws UnsupportedOperationException if {@code srcSegment} is {@linkplain #isReadOnly() read-only}.

Isn't the source segment being read-only fine? (It seems to work when I test it).

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 388:

> 386:      * knows that they have fully processed the contents of the allocated segment before the subsequent allocation request
> 387:      * takes place.
> 388:      * @implNote While a prefix allocator is <em>thread-safe</em>, concurrent access on the same recycling

Is the term "thread-safe" defined any where? Should it be?

src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 71:

> 69:      *
> 70:      * @param order the desired byte order.
> 71:      * @return a value layout with the same characteristics as this layout, but with the given byte order.

Also seems like a candidate for `{@return ...}`

test/jdk/java/foreign/TestLayoutPaths.java line 125:

> 123:     }
> 124: 
> 125:     public void testByteOffsetHandleRange() {

Missing `@Test`?

test/jdk/java/foreign/TestSegmentCopy.java line 92:

> 90:         if (type.layout.byteSize() > 1) {
> 91:             MemorySegment segment = MemorySegment.ofArray(new byte[100]);
> 92:             // check failure with read-only dest

Comment seems unrelated?
Suggestion:

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

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1572729100
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213428607
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213450622
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213444071
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213513178
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213519613
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213537495
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213543002
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213546737
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213547221
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213549246
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213550462
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213553113
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213554350
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213560057
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213564647
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213567889
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213568928
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213575093
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213577557
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213584838
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213599402
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213600750
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213601348
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213608551
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213613960
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213620105
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213626975
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213628954

From jvernee at openjdk.org  Thu Jun  1 20:27:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 20:27:37 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
Message-ID: <a63nutPD8D-kkuMvya-qzPQoj4gQTPWVsAWwDf5zA9k=.8070351b-6e48-4949-8974-a64cde73bd6c@github.com>

On Thu, 1 Jun 2023 13:06:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 127:
> 
>> 125:     /**
>> 126:      * Creates a function descriptor with the given argument layouts and no return layout.  This is useful to model functions
>> 127:      * which return no values.
> 
> I think I would use "that return" rather than "which return" here.

I [looked this up](https://www.grammarly.com/blog/which-vs-that/), and learned something (thanks!). 

"which" is used for optional clauses. It implies the sentence could be written as "This is useful to model functions (which, by the way, return no values)". i.e. it is optional information about functions. "that" is used to indicate we're talking about a particular kind of function (implying also that there are multiple kinds).

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 325:
> 
>> 323:      * @return a segment for the newly allocated memory block.
>> 324:      * @throws IllegalArgumentException if {@code elementLayout.byteSize() * count} overflows.
>> 325:      * @throws IllegalArgumentException if {@code count < 0}.
> 
> Another case where the IAE descriptions should probably be combined.

I think having the different failure cases split up like this makes the doc easier to read. (IIRC we used to have everything combined in the past, but got the advice at some point to split things up into separate `@throws` clauses).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213439901
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213611242

From jvernee at openjdk.org  Thu Jun  1 20:27:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 20:27:37 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
Message-ID: <Mqjsgs-OrI3yfPXoLLnwoO2Bm-EcEodzFbhuRLbFBbU=.2879a7e0-7973-46ff-8f00-86ef8157d738@github.com>

On Thu, 1 Jun 2023 19:24:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 645:
> 
>> 643:      * is 1. As such, regardless of its size, in the absence of an {@linkplain #withByteAlignment(long) explicit}
>> 644:      * alignment constraint, a padding layout does not affect the alignment constraint of the group or sequence layout
>> 645:      * it is nested into.
> 
> It is possible to override the alignment constraints of group and sequence layouts, so maybe this should say _natural alignment_.
> Suggestion:
> 
>      * alignment constraint, a padding layout does not affect the natural alignment of the group or sequence layout
>      * it is nested into.

On a related note: should we even allow sequences of padding layouts?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213585708

From smarks at openjdk.org  Thu Jun  1 20:36:31 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 1 Jun 2023 20:36:31 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
Message-ID: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>

Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.

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

Commit messages:
 - Minor wording adjustment.
 - 8307840: SequencedMap view method specification and implementation adjustments

Changes: https://git.openjdk.org/jdk/pull/14267/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14267&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307840
  Stats: 113 lines in 3 files changed: 64 ins; 3 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/14267.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14267/head:pull/14267

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

From mcimadamore at openjdk.org  Thu Jun  1 20:46:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 20:46:10 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
Message-ID: <8Ib6l3Ykq0UOD-xVaKUyemJeQDbu5X5cW1mK4u3cnKM=.d6ab1330-7bc6-4c3c-914a-6c3e8b82605c@github.com>

On Thu, 1 Jun 2023 13:16:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/SequenceLayout.java line 75:
> 
>> 73:      * @return a sequence layout with the same characteristics of this layout, but with the given element count.
>> 74:      * @throws IllegalArgumentException if {@code elementCount} is negative.
>> 75:      * @throws IllegalArgumentException if {@code elementLayout.bitSize() * elementCount} overflows.
> 
> Shouldn't the exception descriptions be combined to avoid IAE being listed twice in the generated javadoc?

I think @PaulSandoz  suggested this idiom in other places where the `@throws` clause was very hard to break up, so I thought that would have been preferrable than having a single para. But if there are strong opinions, I could tweak in different ways, perhaps with bullet lists (but that will require a lot of work).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213660125

From mcimadamore at openjdk.org  Thu Jun  1 21:00:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 21:00:16 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Mqjsgs-OrI3yfPXoLLnwoO2Bm-EcEodzFbhuRLbFBbU=.2879a7e0-7973-46ff-8f00-86ef8157d738@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <Mqjsgs-OrI3yfPXoLLnwoO2Bm-EcEodzFbhuRLbFBbU=.2879a7e0-7973-46ff-8f00-86ef8157d738@github.com>
Message-ID: <n238JjkfdXnI0lIh3qsjtRZ9r4TRaJQKn2Qqj--0EhQ=.d07d5288-7b85-4b6e-9340-b7e5adb218a8@github.com>

On Thu, 1 Jun 2023 19:25:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 645:
>> 
>>> 643:      * is 1. As such, regardless of its size, in the absence of an {@linkplain #withByteAlignment(long) explicit}
>>> 644:      * alignment constraint, a padding layout does not affect the alignment constraint of the group or sequence layout
>>> 645:      * it is nested into.
>> 
>> It is possible to override the alignment constraints of group and sequence layouts, so maybe this should say _natural alignment_.
>> Suggestion:
>> 
>>      * alignment constraint, a padding layout does not affect the natural alignment of the group or sequence layout
>>      * it is nested into.
>
> On a related note: should we even allow sequences of padding layouts?

I let sequence of padding slide on the basis that groups of padding are allowed. But it's a somewhat arbitrary line. That said, we do use stuff like that in jextract, where we model types we don't support (or bitfields) as padding. I think starting to ban padding in certain places would result in a less compositional API - and perhaps tools would have to workaround some of these limitations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213672976

From mcimadamore at openjdk.org  Thu Jun  1 21:00:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 21:00:21 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
Message-ID: <4C4EUdcFz_tApI7-Nrv6zi_lbgOiDZPTHmwcmrezC5E=.ace6d428-7b07-40df-af44-42ae9222d29f@github.com>

On Thu, 1 Jun 2023 19:36:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 938:
> 
>> 936:      * the properties of this segment. For instance, if this segment is a {@linkplain #isReadOnly() read-only segment},
>> 937:      * then the resulting buffer is also {@linkplain ByteBuffer#isReadOnly() read-only}. Additionally, if this is a native
>> 938:      * segment, the resulting buffer is a {@linkplain ByteBuffer#isDirect() direct buffer}.
> 
> (Pre-existing, but seemed useful to mention) Rather than giving a few examples with 'For instance', perhaps this should more explicitly list _all_ the properties that are reflected in the returned buffer (not sure if there are more).

Good idea - it is not trivial to capture all the properties in a single para.

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 388:
> 
>> 386:      * knows that they have fully processed the contents of the allocated segment before the subsequent allocation request
>> 387:      * takes place.
>> 388:      * @implNote While a prefix allocator is <em>thread-safe</em>, concurrent access on the same recycling
> 
> Is the term "thread-safe" defined any where? Should it be?

I think the term is used pretty much all over the javadoc (not just FFM's) - e.g. look for this preamble:

 * <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>,
 * immutable and thread-safe
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213670809
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213669418

From darcy at openjdk.org  Thu Jun  1 21:04:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 1 Jun 2023 21:04:30 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v5]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <HTAFR7FhcvE_E-uaYsDZmSwQwx254-o0D9fYMLFH7GE=.f20d3c43-9db9-4ed5-812f-99e35c87bebf@github.com>

> Time to get JDK 22 underway...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Update symbol files for JDK 21 build 25.
 - Merge branch 'master' into JDK-8306584
 - Refactor a few more enums.
 - Respond to review comments.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - ... and 19 more: https://git.openjdk.org/jdk/compare/0ab09630...075a2ab6

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=04
  Stats: 5956 lines in 69 files changed: 5902 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From mcimadamore at openjdk.org  Thu Jun  1 21:09:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 21:09:14 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
Message-ID: <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>

On Thu, 1 Jun 2023 18:12:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 444:
> 
>> 442:  * <p>
>> 443:  * When an upcall stub is passed to a foreign function, a JVM crash might occur, if the foreign code casts the function pointer
>> 444:  * associated with the upcall stub to a type that is incompatible with the type of the upcall stub. Moreover, if the method
> 
> This kind of makes it sound like a crash can occur at the time of the cast. I think we should mention that the crash can occur when the function is invoked.
> Suggestion:
> 
>  * When an upcall stub is passed to a foreign function, a JVM crash might occur, if the foreign code casts the function pointer
>  * associated with the upcall stub to a type that is incompatible with the type of the upcall stub, and then attempts to invoke the function through the resulting function pointer. Moreover, if the method

I agree that's better - I was also puzzled by the text (I think it's there from before, just shuffled?)

> src/java.base/share/classes/java/lang/foreign/Linker.java line 473:
> 
>> 471: 
>> 472:     /**
>> 473:      * Creates a method handle which is used to call a foreign function with the given signature and symbol.
> 
> I always think of a function "symbol" mostly as the _name_ of the function, so it seems that "address" would be more correct here. Though, I might be wrong on that. It's hard to find a clear definition of "symbol" that applies to this specific use case.

the idea behind this is to connect with the javadoc of `SymbolLookup` which defines and then uses symbol all over the place.

> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 393:
> 
>> 391:      * <p>
>> 392:      * Multiple paths can be chained, by using <a href=#deref-path-elements>dereference path elements</a>.
>> 393:      * A dereference path element allows to obtain a native memory segment whose base address is the address value
> 
> "allows to obtain" doesn't sound right to me. I think it should either be "allows _subject_ to obtain" (where _subject_ is for instance "the user"), or it could also be "allows obtaining" (the the former seems more natural to me).
> Suggestion:
> 
>      * A dereference path element allows the user to obtain a native memory segment whose base address is the address value

I will also look for some other way to say this - typically when I end up with such convoluted sentences there's a better way to write it :-)

> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 418:
> 
>> 416:      *
>> 417:      * @param elements the layout path elements.
>> 418:      * @return a var handle that accesses a memory segment at the offset selected by the given layout path.
> 
> This doesn't seem quite right. It is not the memory segment which is found at the offset given by the layout path, it is the base address.
> 
> Maybe:
> Suggestion:
> 
>      * @return a var handle that accesses a memory segment whose base address is found at the offset selected by the given layout path.

Yeah - I meant what you said - but now that you said it, I also saw how what I've written can be prone to an alternate (and wrong) interpretation. I'll clarify.

> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 470:
> 
>> 468:      * @throws IllegalArgumentException if the layout path contains one or more <a href=#deref-path-elements>dereference path elements</a>.
>> 469:      * @throws IllegalArgumentException if the layout path contains one or more path elements that select one or more
>> 470:      * sequence element indices, such as {@link PathElement#sequenceElement(long)} and {@link PathElement#sequenceElement(long, long)}).
> 
> Looks like the first method link should like to `PathElement#sequenceElement()` instead? (I think using a bound `sequenceElement` is fine right?)

This is deliberate (but subtle). Basically, for `select` we just want to select a target layout (we don't care which). So the method has a preference for open sequence layout paths: there's no access or offset to model here, the method just needs to end up into some layout at the end of the path. One might argue that these restrictions are unnecessary - but I didn't feel strongly enough to drop them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213681006
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213679251
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213677679
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213676964
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213675483

From mcimadamore at openjdk.org  Thu Jun  1 21:09:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 21:09:16 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
Message-ID: <02fGvGO-WlGfJeSweM2kgOdXpW2m6Sr4z4gUyIdWFj0=.b484c663-ddbd-4e26-b7b6-04cb9e01b7f4@github.com>

On Thu, 1 Jun 2023 21:04:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 473:
>> 
>>> 471: 
>>> 472:     /**
>>> 473:      * Creates a method handle which is used to call a foreign function with the given signature and symbol.
>> 
>> I always think of a function "symbol" mostly as the _name_ of the function, so it seems that "address" would be more correct here. Though, I might be wrong on that. It's hard to find a clear definition of "symbol" that applies to this specific use case.
>
> the idea behind this is to connect with the javadoc of `SymbolLookup` which defines and then uses symbol all over the place.

Maybe a linkplan could help?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213679476

From mcimadamore at openjdk.org  Thu Jun  1 21:12:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 21:12:09 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
Message-ID: <x0VjOYnyIFKlW2MGq4VnkeazIQa8YnavwnNmNk8fE3o=.6fd5eb0d-b963-4575-a2e1-bcb960c63fc9@github.com>

On Thu, 1 Jun 2023 17:10:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 201:
> 
>> 199:  * <p>
>> 200:  * All native linker implementations operate on a subset of memory layouts. More formally, a layout {@code L}
>> 201:  * is supported by a native linker {@code NL} iff:
> 
> I think using `iff` (if-and-only-if) is incorrect here, since certain linkers might impose additional constraints. For instance, the fallback linker doesn't support union layouts. Also, we want to further restrict variadic argument layouts as well as part of https://github.com/openjdk/jdk/pull/14225
> 
> Maybe we could say that all layouts passed to a linker must _at least_ adhere to the following constraints.

I'll think about it - it's a bit problematic to specify in terms of "at least" because we need to be able to refer to "supported by NL" recursively in the text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213683303

From mcimadamore at openjdk.org  Thu Jun  1 21:16:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 1 Jun 2023 21:16:10 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
Message-ID: <QmcL2lMeMi5zVkAfxJtmjhBD8pcw6KmNClEgYoY8QJw=.37c2e5d7-a10a-4e2d-9fc4-dad0b77d0bc7@github.com>

On Thu, 1 Jun 2023 13:00:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/Arena.java line 269:
> 
>> 267:      * @throws IllegalStateException if this arena has already been {@linkplain #close() closed}.
>> 268:      * @throws WrongThreadException if this arena is confined, and this method is called from a thread {@code T}
>> 269:      * other than the arena's owner thread.
> 
> "thread T" hints that "T" will be used later, maybe it's not needed.

Correct - this is mostly a copy/paste issue for similar throws clauses in methods outside arena.

> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 363:
> 
>> 361:      * The returned allocator throws {@link IndexOutOfBoundsException} when a slice of the provided
>> 362:      * segment with the requested size and alignment cannot be found.
>> 363:      * @implNote A slicing allocator is not <em>thread-safe</em>.
> 
> The implNote about thread safety makes me wonder if the SegmentAllocator should say something about thread safety, e.g. should it specify that the allocate methods are thread safe?

I think SegmentAllocator should be agnostic re. thread safety. Allocation is a world of compromises, where if you give up (thread) safety you can gain more performance (and viceversa). So I think having a "one size fits all" thread-safety blanket might not work very well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213686844
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213685702

From jvernee at openjdk.org  Thu Jun  1 21:23:08 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 21:23:08 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <02fGvGO-WlGfJeSweM2kgOdXpW2m6Sr4z4gUyIdWFj0=.b484c663-ddbd-4e26-b7b6-04cb9e01b7f4@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
 <02fGvGO-WlGfJeSweM2kgOdXpW2m6Sr4z4gUyIdWFj0=.b484c663-ddbd-4e26-b7b6-04cb9e01b7f4@github.com>
Message-ID: <ZmRKnqQ1Ju5li9f9cAJQq1uaDR0XIEL4Zb9_tM5IHiM=.1456995d-401b-4ccc-b0c3-977751a07373@github.com>

On Thu, 1 Jun 2023 21:04:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> the idea behind this is to connect with the javadoc of `SymbolLookup` which defines and then uses symbol all over the place.
>
> Maybe a linkplan could help?

Okay, but `SymbolLookup` also says this: "A <em>symbol lookup</em> retrieves the address of a symbol in one or more libraries." and "This symbol lookup, which is known as a <em>default lookup</em>, helps clients to quickly find addresses of well-known symbols."

This seems to imply that "symbol" and "address" are two different things. I get the connection between the address and the SymbolLookup, but I'll note that it's also not necessary for a function address to come from a SymbolLookup (e.g. the address could be returned from native code, or be the address of an upcall stub).

So, I feel like sticking with "address" is better. Maybe a paragraph (or just a `@see` tag) could be added to refer to SymbolLookup instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213693435

From liach at openjdk.org  Thu Jun  1 21:26:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 21:26:25 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v4]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <oG-PsLKkiN7TTe739zNHKs2mLNyLAuhI53WEu6Fynxw=.4b90cda7-3b44-42eb-9cc5-70b0c5b1881a@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op

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

  Fix exact swap
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/6ed6b805..d347ee7e

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

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

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

From liach at openjdk.org  Thu Jun  1 21:26:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 Jun 2023 21:26:27 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v3]
In-Reply-To: <z90XIdgoAAF2G6JTUjy9GFFIFxGSrfvSwB_vUxjyeYo=.f1d87d46-e241-449b-8fe9-3fb715d02e9b@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
 <z90XIdgoAAF2G6JTUjy9GFFIFxGSrfvSwB_vUxjyeYo=.f1d87d46-e241-449b-8fe9-3fb715d02e9b@github.com>
Message-ID: <lnzXdI0-7OakGneU0TVm5gBr5KOm2nbJ8RIoDOBjPJw=.25a9423b-9c7b-4b9f-98e1-07874ebeb0ae@github.com>

On Thu, 1 Jun 2023 19:39:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> As for the implementation of `LazyStaticVarHandle`, I expect that `makeFieldHandle` can always create the direct var handle (i.e. `FieldStaticReadXXX` var handle) and then wrapped by `LazyStaticVarHandle` similar to how `IndirectVarHandle` does; 

Since I am not familiar with hotspot internals, I assumed that staticFieldBase and staticFieldOffset shouldn't be used until the class is initialized (rather than linked). This for certain can be done if they are ready once a class is linked, and we should probably update unsafe's comment as well. Can you confirm that they staticFieldBase/Offset are safe to be called before initialization?

If this change is safe, we can significantly reduce the initial-call overhead of the lazy VH significantly as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1572801392

From naoto at openjdk.org  Thu Jun  1 21:46:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 Jun 2023 21:46:13 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <eIjbrsmBz485KHAyRmOWdM_LUC33JSNTnR8uHFrA17o=.8431098a-739e-4530-97da-a4133c622d3a@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun 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:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

As to the patch, would you please elaborate on your changes more? To me, it is simply inlining `Key.normalize(key)` content into `Cache.createObject()`, and not sure how it prevents the issue in which the referent got GC'ed during the reference creation and use.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1572826469

From jvernee at openjdk.org  Thu Jun  1 21:51:12 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 21:51:12 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <n238JjkfdXnI0lIh3qsjtRZ9r4TRaJQKn2Qqj--0EhQ=.d07d5288-7b85-4b6e-9340-b7e5adb218a8@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <Mqjsgs-OrI3yfPXoLLnwoO2Bm-EcEodzFbhuRLbFBbU=.2879a7e0-7973-46ff-8f00-86ef8157d738@github.com>
 <n238JjkfdXnI0lIh3qsjtRZ9r4TRaJQKn2Qqj--0EhQ=.d07d5288-7b85-4b6e-9340-b7e5adb218a8@github.com>
Message-ID: <5emZKvH2QID-_4OoGMZBeRhvu4QgIE4kyerwbEjcHIs=.03dabc86-edd0-40c1-a73f-e6dca3991bf7@github.com>

On Thu, 1 Jun 2023 20:57:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> On a related note: should we even allow sequences of padding layouts?
>
> I let sequence of padding slide on the basis that groups of padding are allowed. But it's a somewhat arbitrary line. That said, we do use stuff like that in jextract, where we model types we don't support (or bitfields) as padding. I think starting to ban padding in certain places would result in a less compositional API - and perhaps tools would have to workaround some of these limitations.

Thanks, I agree with that analogy

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213714285

From jvernee at openjdk.org  Thu Jun  1 21:51:10 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 1 Jun 2023 21:51:10 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
Message-ID: <E9FZJq_CCwbjL6IzHwif35lVUpRi5LV84uGIxmFXBog=.984ca052-1e0a-4ea5-b841-acb9c8f0a303@github.com>

On Thu, 1 Jun 2023 21:00:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 470:
>> 
>>> 468:      * @throws IllegalArgumentException if the layout path contains one or more <a href=#deref-path-elements>dereference path elements</a>.
>>> 469:      * @throws IllegalArgumentException if the layout path contains one or more path elements that select one or more
>>> 470:      * sequence element indices, such as {@link PathElement#sequenceElement(long)} and {@link PathElement#sequenceElement(long, long)}).
>> 
>> Looks like the first method link should like to `PathElement#sequenceElement()` instead? (I think using a bound `sequenceElement` is fine right?)
>
> This is deliberate (but subtle). Basically, for `select` we just want to select a target layout (we don't care which). So the method has a preference for open sequence layout paths: there's no access or offset to model here, the method just needs to end up into some layout at the end of the path. One might argue that these restrictions are unnecessary - but I didn't feel strongly enough to drop them.

Ok, thanks for explaining.

>> src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 388:
>> 
>>> 386:      * knows that they have fully processed the contents of the allocated segment before the subsequent allocation request
>>> 387:      * takes place.
>>> 388:      * @implNote While a prefix allocator is <em>thread-safe</em>, concurrent access on the same recycling
>> 
>> Is the term "thread-safe" defined any where? Should it be?
>
> I think the term is used pretty much all over the javadoc (not just FFM's) - e.g. look for this preamble:
> 
>  * <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>,
>  * immutable and thread-safe
>  ```

Right, I guess I'm asking: can/should we do better? ;) It might be nice to define the term once and for all for the entire JDK, similar to how 'reachability' also has a central definition. (and then add a link from here).

But, arguably, that seems like too much scope creep for this PR, so let's save it for a potential followup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213714496
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1213716230

From mseledtsov at openjdk.org  Thu Jun  1 22:01:08 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 1 Jun 2023 22:01:08 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <vSn81I9V8XI0k8n5SaD95JelG0xFF-kOzSz4N05jH1w=.7bbf1edc-ffcf-4ca5-a810-6b83b93ec69d@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

Changes look good to me. Thank you for adding these tests.

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

Marked as reviewed by mseledtsov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14090#pullrequestreview-1456374316

From mchung at openjdk.org  Thu Jun  1 23:25:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 1 Jun 2023 23:25:09 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v4]
In-Reply-To: <oG-PsLKkiN7TTe739zNHKs2mLNyLAuhI53WEu6Fynxw=.4b90cda7-3b44-42eb-9cc5-70b0c5b1881a@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <oG-PsLKkiN7TTe739zNHKs2mLNyLAuhI53WEu6Fynxw=.4b90cda7-3b44-42eb-9cc5-70b0c5b1881a@github.com>
Message-ID: <sSmId3Mc91vuIutsPLgMolhujCXexwTP6xla6h3vgvk=.9ac2630b-f1c2-4a71-9819-7cbbd5e82450@github.com>

On Thu, 1 Jun 2023 21:26:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix exact swap
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

`staticFieldBase` and `staticFieldOffset` can be called before initialization once a class has been linked.   They are unsafe operations and so the code has to ensure class initialization before it accesses a static field.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1572912754

From jiangli at openjdk.org  Thu Jun  1 23:41:08 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 1 Jun 2023 23:41:08 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
 <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
Message-ID: <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>

On Thu, 1 Jun 2023 16:18:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > > Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking.
> > 
> > 
> > I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17).
> > @erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light.
> 
> There are no extra options. I suspect it's an issue with the older GCC version. Here is one failing command line:
> 
> ```
> $ ( cd /home/erik/git/jdk/build/linux-arm32 ; /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -r --sysroot=/var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/arm-linux-gnueabihf/sysroot -o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/librmi_relocatable.o /home/erik/git/jdk/build/linux-arm32/support/native/java.rmi/librmi/static/GC.o )
> /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /var/tmp/jib-erik/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libgcc_s.so.1
> ```
> 

Thanks a lot for looking into the issue.

> > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.
> 
> This seems to be Clang specific, so maybe only apply this to Clang and not GCC? Have you measured the difference in link time and concluded that this workaround is needed? If so, how big were the differences? 

It was noticeably slower (which prompted me looked into it at that time) when linking the executable using the static libraries created without partial linking workaround. In my experiments, it took >2m when linking final executable. With the mitigation the final linking took a few seconds.

> Given that it prints a lot of warnings on mac, I would suggest leaving the partial linking out of this patch to get something in that is actually working. It was included in this patch because of the side effect it had with handling long path names. However, since looking closer at that issue, we were using a different workaround for Clang already and that same workaround should work fine for AR on mac as well.

Sounds good for solving the macosx `ar` limitation differently. I'll change that. We can also exclude the partial linking part for gcc (due the older tool issue that you've found). Any concerns with including partial linking step for clang on Linux?

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1572922666

From bpb at openjdk.org  Fri Jun  2 00:07:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 00:07:12 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test java/io/GetXSpace.java
Message-ID: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>

For Unix, copy the `jchar`s into an allocated `char` array.

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

Commit messages:
 - 8309216: Cast from jchar* to char* in test java/io/GetXSpace.java

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

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

From bpb at openjdk.org  Fri Jun  2 00:07:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 00:07:13 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java
In-Reply-To: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
Message-ID: <cKmXcFErgRIFDSW0RfGMX0BW8MSxi0Y1iqdNcfVBlfc=.fbfce508-8f53-43c9-9094-be4f1805d2a2@github.com>

On Fri, 2 Jun 2023 00:00:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For Unix, copy the `jchar`s into an allocated `char` array.

Preliminary test run passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14276#issuecomment-1572936688

From dholmes at openjdk.org  Fri Jun  2 01:08:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 2 Jun 2023 01:08:08 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <ddLUlGiSYp3PgkioeA-d3NMxjel2k9M01g_oW_VwFGI=.24c708fa-c43e-462c-aab6-21f1d6baabe0@github.com>

On Thu, 1 Jun 2023 06:40:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if is a a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Yes :)

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14257#pullrequestreview-1456506531

From duke at openjdk.org  Fri Jun  2 01:10:11 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 2 Jun 2023 01:10:11 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun 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:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 369:

> 367:             BaseLocale l = key.holder;
> 368:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
> 369:             return (new Key(locale)).getBaseLocale();

Perhaps a more rigorous approach would look like this?
<pre><code class="java">
BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
BaseLocal value = (new Key(locale)).getBaseLocale();
Reference.reachabilityFence(locale);
return value;
</code></pre>
But the current patch has passed the tests with `-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, so I think the current patch is OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1213813143

From liach at openjdk.org  Fri Jun  2 01:13:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 01:13:12 GMT
Subject: RFR: 8307149: MethodHandles.arrayConstructor can be cached
In-Reply-To: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>
References: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>
Message-ID: <Dg3b-sKVD1bafmI2DmhKdqlQ_g2iScm-razGXFs88gY=.d1616488-8dcb-45d9-877a-5e160e1c0245@github.com>

On Thu, 4 May 2023 23:29:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch migrates `MethodHandles::arrayConstructor`, added in Java 9 as a hotfix to the incorrect constructor found on arrays via Lookup, to share the array access caching features. The result is that calling `MethodHandles.arrayConstructor` to create method handles is much faster.
> 
> Oracle JDK 20:
> 
> Benchmark                                             Mode  Cnt   Score   Error  Units
> MethodHandlesArrayConstructor.createWithAnewarray     avgt   15   2.739 ? 0.058  ns/op
> MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15   3.313 ? 0.041  ns/op
> MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  61.874 ? 0.397  ns/op
> 
> 
> This patch:
> 
> Benchmark                                             Mode  Cnt  Score   Error  Units
> MethodHandlesArrayConstructor.createWithAnewarray     avgt   15  3.067 ? 0.026  ns/op
> MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15  3.699 ? 0.042  ns/op
> MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  1.447 ? 0.004  ns/op

keep-alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/13819#issuecomment-1572983914

From liach at openjdk.org  Fri Jun  2 01:22:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 01:22:07 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v4]
In-Reply-To: <oG-PsLKkiN7TTe739zNHKs2mLNyLAuhI53WEu6Fynxw=.4b90cda7-3b44-42eb-9cc5-70b0c5b1881a@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <oG-PsLKkiN7TTe739zNHKs2mLNyLAuhI53WEu6Fynxw=.4b90cda7-3b44-42eb-9cc5-70b0c5b1881a@github.com>
Message-ID: <c4uk05oNR96DyNsfEywNrShjXxY_IMkd7dKKnGs0FHU=.c8221777-0688-4920-81dc-02dc4cd2913c@github.com>

On Thu, 1 Jun 2023 21:26:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix exact swap
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

In addition, should we initialize the ref class or the declaring class only? I don't think we need to initialize the ref class when declaring class initialization should be sufficient, but that is a change in behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1572991154

From duke at openjdk.org  Fri Jun  2 01:30:06 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 2 Jun 2023 01:30:06 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <VW0d0G5A5DXLwKTartQijiUdmG2H19-q_PY_iB55DeE=.23d70c40-6a5a-40d2-b060-9dee7fbffe75@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VW0d0G5A5DXLwKTartQijiUdmG2H19-q_PY_iB55DeE=.23d70c40-6a5a-40d2-b060-9dee7fbffe75@github.com>
Message-ID: <Q2qtCrM5PZ2kCxTzIKA69ApFFqheiY4lZbGvgfCTX9M=.0973512a-bc8f-4959-b307-362843c60252@github.com>

On Thu, 1 Jun 2023 09:03:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> SUN Guoyun 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:
>> 
>>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared
>
> I've done basic testing jtreg tier1-3 and partial shenandoah testing with vmoptions `-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, the results are all OK.

>  @sunny868 Would you be able to add a JMH test to make sure that your change would not affect the startup time? 

All JMH tests or some of them? I had trigger JMH test, waiting for run results.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1572999255

From duke at openjdk.org  Fri Jun  2 02:10:09 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Fri, 2 Jun 2023 02:10:09 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <kFeOAbID5CsptDtVeKZ-O2RhUD50AUEB10vP0p8i4UM=.0e3ef102-e406-44a7-9698-0eaf5bd38a15@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun 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:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

`make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot" TEST=java/util/Locale/SoftKeys.java` can trigger  same error:
<pre><code class="shell">
Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
	at java.base/java.util.Locale.forLanguageTag(Locale.java:1876)
	at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:45)
	... 19 more
</code></pre>
this patch can fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1573032287

From liach at openjdk.org  Fri Jun  2 02:12:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 02:12:30 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op

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

 - Compute base and offset right after linking, simplify code
 - Merge branch 'master' into lazy-static-varhandle
 - Fix exact swap
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Remove export for removed package
 - Merge branch 'master' into lazy-static-varhandle
 - Test the creation performance of handles, lazy one indeed better
 - Merge branch 'master' into lazy-static-varhandle
 - copyright year
 - Benchmarks. lazy initialize is SLOW
 - nuke meaningless overrides
 - ... and 1 more: https://git.openjdk.org/jdk/compare/a32cfd30...27e18b7c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/d347ee7e..27e18b7c

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

  Stats: 66891 lines in 1457 files changed: 47041 ins; 10823 del; 9027 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

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

From mchung at openjdk.org  Fri Jun  2 02:12:30 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 02:12:30 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v4]
In-Reply-To: <c4uk05oNR96DyNsfEywNrShjXxY_IMkd7dKKnGs0FHU=.c8221777-0688-4920-81dc-02dc4cd2913c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <oG-PsLKkiN7TTe739zNHKs2mLNyLAuhI53WEu6Fynxw=.4b90cda7-3b44-42eb-9cc5-70b0c5b1881a@github.com>
 <c4uk05oNR96DyNsfEywNrShjXxY_IMkd7dKKnGs0FHU=.c8221777-0688-4920-81dc-02dc4cd2913c@github.com>
Message-ID: <_-V-Ciz-CZV5h_1BMNM9-wfjf13Cb8EOrATGp5TKPl4=.0234d077-f447-4e78-9650-08210c88ffc0@github.com>

On Fri, 2 Jun 2023 01:19:26 GMT, Chen Liang <liach at openjdk.org> wrote:

> In addition, should we initialize the ref class or the declaring class only? I don't think we need to initialize the ref class when declaring class initialization should be sufficient, but that is a change in behavior.

Declaring class will be initialized [1].

refc should be equals to the declaring class because the static field to be looked up can only be found in the declaring class.  There should be no behavioral change.

[1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStaticVarHandle(java.lang.Class,java.lang.String,java.lang.Class)

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1573031355

From liach at openjdk.org  Fri Jun  2 02:42:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 02:42:11 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
Message-ID: <XysH8cpSh7AcI_1M3C4TXGQ3sEGX7R4IZU-z58bf0RU=.47171f29-0768-417b-ba74-053a52938e57@github.com>

On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> 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 11 additional commits since the last revision:
> 
>  - Compute base and offset right after linking, simplify code
>  - Merge branch 'master' into lazy-static-varhandle
>  - Fix exact swap
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/b9ba7a85...27e18b7c

Not quite. I mean scenarios like this:

import java.lang.invoke.*;

class Parent {
	public static final int[] value = {34};
}

class Child extends Parent {}

public class Test {
	public static void main(String... args) throws Throwable {
		System.out.println(Child.value[0]);
		var lookup = MethodHandles.lookup();
		var getter = lookup.findStaticVarHandle(Child.class, "value", int[].class);
		System.out.println(((int[]) getter.getAcquire())[0]);
	}
}


Here, the `value` field is in parent, but it's accessed via a subclass and is resolved successfully. Are the refc and declaring class still equal here? I think we only need to initialize Parent without initializing Child in this case.

I've also updated the benchmark for the latest patch. Unfortunately the regular invocations and lazy var handle initial call performance saw a decrease.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1573054150

From darcy at openjdk.org  Fri Jun  2 02:46:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Jun 2023 02:46:26 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v3]
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <XZ-tC_VceAdzzTI7OKVPPz4a8uhTTgytsoE54r791Jk=.6323ee23-b049-47d5-8a4a-da4f70ea3b24@github.com>

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

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

 - Merge branch 'master' into JDK-8308913
 - Merge branch 'master' into JDK-8308913
 - Implement review feedback.
 - Merge branch 'master' into JDK-8308913
 - Cleanup and edit text.
 - Respond to review comments.
 - Appease jcheck.
 - JDK-8308913: Update core reflection for JEP 445 (preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14165/files
  - new: https://git.openjdk.org/jdk/pull/14165/files/ffdbbecd..05244653

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

  Stats: 9712 lines in 220 files changed: 7677 ins; 1116 del; 919 mod
  Patch: https://git.openjdk.org/jdk/pull/14165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14165/head:pull/14165

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

From liach at openjdk.org  Fri Jun  2 03:36:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 03:36:35 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v8]
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - 1. Moved the default resolver to a static method, in anticipation of future changes
   2. Removed SecurityManager related content
   3. Changed ClassHierarchyInfo into an interface
   4. Moved caching method from static to instance method
 - Merge branch 'master' into hierarchy-resolve
 - rename to ofClassLoading/ofResourceParsing
   convert the default class provider to bypass security manager restrictions
 - Merge branch 'master' into hierarchy-resolve
 - Merge branch 'master' into hierarchy-resolve
 - Test both cached and uncached resolvers
 - Update the class hierarchy resolver api as per mailing list last week
 - Merge branch 'master' into hierarchy-resolve
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Make lookup based resolver throw on illegal access eagerly
 - ... and 2 more: https://git.openjdk.org/jdk/compare/101bf229...9e9079fb

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

Changes: https://git.openjdk.org/jdk/pull/13082/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=07
  Stats: 388 lines in 8 files changed: 294 ins; 29 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/13082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082

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

From liach at openjdk.org  Fri Jun  2 03:41:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 03:41:08 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v8]
In-Reply-To: <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>
Message-ID: <zqHizzRKoF1A2SkrpSmzoG17BH-u9k0kqiXXJT43yV4=.9265fc40-ab99-44dd-a469-a9a01459da5c@github.com>

On Fri, 2 Jun 2023 03:36:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Make lookup based resolver throw on illegal access eagerly
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/101bf229...9e9079fb

A brief summary of the latest update:
1. I've moved to implement all 3 API changes to ClassHierarchyResolver discussed on classfile-api-dev
2. I've dropped SecurityManager content; if they are needed by another patch, those patches can add on their own.

This will be in conflict with the Classfile object update; I can update accordingly if that one is integrated first.

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

PR Comment: https://git.openjdk.org/jdk/pull/13082#issuecomment-1573096991

From darcy at openjdk.org  Fri Jun  2 04:48:35 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Jun 2023 04:48:35 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

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

  Update reflective support.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14165/files
  - new: https://git.openjdk.org/jdk/pull/14165/files/05244653..eead727d

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

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

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

From darcy at openjdk.org  Fri Jun  2 04:51:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Jun 2023 04:51:06 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <8Yl9LB0CtuI0st9nNAd6BiKgnP0Ef77mWU2smcLRmRA=.b030f3d2-f511-41b0-be47-2abd5e3fd369@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <8Yl9LB0CtuI0st9nNAd6BiKgnP0Ef77mWU2smcLRmRA=.b030f3d2-f511-41b0-be47-2abd5e3fd369@github.com>
Message-ID: <wTE9Ml8yco6Qhv3yMl3-K74wXXL59-M1k7orYhjRWvc=.08d15075-c068-4a42-9043-719bc6945234@github.com>

On Fri, 26 May 2023 20:37:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > Looks fine. This version matches the current implementation where `getCanonicalName` returns non-null. When the implementation of `getCanonicalName` is updated to return null, the spec should be updated.
> > > Nit: `<p>` is needed assuming the section of "Unnamed Classes" has 3 paragraphs.
> > 
> > 
> > Thanks @mlchung.
> > Yes, the current spec matches what the implementation in @JimLaskey 's PR #13689 does at the time of writing.
> > Discussions are on-going with the JEP 445 team regarding whether and how to implement a "isUnnamedClass" predicate for core reflection which would allow the `getCanonicalName` method to screen for unnamed classes and return null, as would reasonably be implied by a reading of the most current draft JLS updates.
> 
> PS Depending on the result of those discussion, the specification for `getCanonicalName` may be changed to return `null`.

PPS PR updated along those line; the changes will likely end up being integrated through Jim's existing JEP 445 PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14165#issuecomment-1573138645

From jpai at openjdk.org  Fri Jun  2 05:04:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 2 Jun 2023 05:04:05 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <XXth74jSqJtK0k8r91SE1KoIFFYZ1cncvmKsmluj0Qo=.4ae6ed06-4b20-4c98-a6ce-828fc81e5185@github.com>

On Thu, 1 Jun 2023 06:40:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if is a a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14257#pullrequestreview-1456650687

From iris at openjdk.org  Fri Jun  2 05:59:03 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 2 Jun 2023 05:59:03 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <iICyQl63NpWinrFTPrMsnEJGzPUCUBlKPk0WUFuaqVU=.6ba2e82b-ad5a-4a10-b300-e8fbc2e40c78@github.com>

On Thu, 1 Jun 2023 06:40:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if is a a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Happy to see this being removed early in JDK 22!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14257#pullrequestreview-1456700929

From smarks at openjdk.org  Fri Jun  2 06:41:36 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 Jun 2023 06:41:36 GMT
Subject: RFR: 8308167: SequencedMap::firstEntry throws NPE when first entry has
 null key or value
Message-ID: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>

Create and use new NullableKeyValueHolder class to accommodate map entries whose key or value might be null.

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

Commit messages:
 - 8308167: SequencedMap::firstEntry throws NPE when first entry has null key or value

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

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

From pminborg at openjdk.org  Fri Jun  2 08:11:12 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 Jun 2023 08:11:12 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <E9FZJq_CCwbjL6IzHwif35lVUpRi5LV84uGIxmFXBog=.984ca052-1e0a-4ea5-b841-acb9c8f0a303@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
 <E9FZJq_CCwbjL6IzHwif35lVUpRi5LV84uGIxmFXBog=.984ca052-1e0a-4ea5-b841-acb9c8f0a303@github.com>
Message-ID: <-YkZMoSJbS9OS1h2cwsimnNYxZU7OhPENB4_ysuElmw=.ea0486c2-000c-4662-846f-d0143d0ae7f9@github.com>

On Thu, 1 Jun 2023 21:47:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I think the term is used pretty much all over the javadoc (not just FFM's) - e.g. look for this preamble:
>> 
>>  * <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>,
>>  * immutable and thread-safe
>>  ```
>
> Right, I guess I'm asking: can/should we do better? ;) It might be nice to define the term once and for all for the entire JDK, similar to how 'reachability' also has a central definition. (and then add a link from here).
> 
> But, arguably, that seems like too much scope creep for this PR, so let's save it for a potential followup.

I think there is something we could start off from: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/annotations/ThreadSafe.html

This could be made under a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214060977

From pminborg at openjdk.org  Fri Jun  2 08:25:11 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 2 Jun 2023 08:25:11 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <-YkZMoSJbS9OS1h2cwsimnNYxZU7OhPENB4_ysuElmw=.ea0486c2-000c-4662-846f-d0143d0ae7f9@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
 <E9FZJq_CCwbjL6IzHwif35lVUpRi5LV84uGIxmFXBog=.984ca052-1e0a-4ea5-b841-acb9c8f0a303@github.com>
 <-YkZMoSJbS9OS1h2cwsimnNYxZU7OhPENB4_ysuElmw=.ea0486c2-000c-4662-846f-d0143d0ae7f9@github.com>
Message-ID: <vbAg82_6yaASM5-N_3IeCd8sTEGioVZQHEV4MjkkBkM=.f9f6ed0e-e170-4411-b9ec-8ee577505396@github.com>

On Fri, 2 Jun 2023 08:08:17 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Right, I guess I'm asking: can/should we do better? ;) It might be nice to define the term once and for all for the entire JDK, similar to how 'reachability' also has a central definition. (and then add a link from here).
>> 
>> But, arguably, that seems like too much scope creep for this PR, so let's save it for a potential followup.
>
> I think there is something we could start off from: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/annotations/ThreadSafe.html
> 
> This could be made under a separate issue.

https://bugs.openjdk.org/browse/JDK-8309342

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214075735

From alanb at openjdk.org  Fri Jun  2 08:41:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Jun 2023 08:41:11 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <QmcL2lMeMi5zVkAfxJtmjhBD8pcw6KmNClEgYoY8QJw=.37c2e5d7-a10a-4e2d-9fc4-dad0b77d0bc7@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
 <QmcL2lMeMi5zVkAfxJtmjhBD8pcw6KmNClEgYoY8QJw=.37c2e5d7-a10a-4e2d-9fc4-dad0b77d0bc7@github.com>
Message-ID: <sZPemWRLSj2KrBHoONR5uRdHIsbBVDJ1H7ov81TSBfk=.931a8ea3-c402-4395-997a-cc8a94652407@github.com>

On Thu, 1 Jun 2023 21:12:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I think SegmentAllocator should be agnostic re. thread safety. Allocation is a world of compromises, where if you give up (thread) safety you can gain more performance (and viceversa). So I think having a "one size fits all" thread-safety blanket might not work very well.

I'm just trying to think about the practical implications of this.  Arena is specified to be thread-safe so I can allocate from a non-confined Arena, and from concurrent threads, without needing to coordinate.  However, if you hand me a SegmentAllocator that is not an Arena then I don't know if I need to coordinate allocation with other parties. I'm not too concerned about the slicingAllocator and prefixAllocator factory methods as the result SegmentAllocators will likely be wrapped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214092803

From sgehwolf at openjdk.org  Fri Jun  2 09:01:16 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 2 Jun 2023 09:01:16 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <xuXwvEdG6cYFWIhacGp5DOKRaVaza9rqJq8ClRl6-HM=.da8a437f-e72d-4fd8-ac2f-e0f072addd39@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1573393329

From sgehwolf at openjdk.org  Fri Jun  2 09:01:19 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 2 Jun 2023 09:01:19 GMT
Subject: Integrated: 8308090: Add container tests for on-the-fly resource quota
 updates
In-Reply-To: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
Message-ID: <WHycS5_36FTOCyG0h2TsTTzLTnLW7Z0ifjh-6W4LOik=.200393bf-b500-45b1-bd4e-2c0302640491@github.com>

On Mon, 22 May 2023 16:40:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
> 
> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
> 
> Testing:
>  - [x] GHA
>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)

This pull request has now been integrated.

Changeset: dc8bc6c9
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc8bc6c98ca1f9b441cf71c641675fe29dda9162
Stats:     434 lines in 5 files changed: 431 ins; 2 del; 1 mod

8308090: Add container tests for on-the-fly resource quota updates

Reviewed-by: dholmes, mseledtsov

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

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

From mcimadamore at openjdk.org  Fri Jun  2 10:02:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 10:02:11 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <sZPemWRLSj2KrBHoONR5uRdHIsbBVDJ1H7ov81TSBfk=.931a8ea3-c402-4395-997a-cc8a94652407@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
 <QmcL2lMeMi5zVkAfxJtmjhBD8pcw6KmNClEgYoY8QJw=.37c2e5d7-a10a-4e2d-9fc4-dad0b77d0bc7@github.com>
 <sZPemWRLSj2KrBHoONR5uRdHIsbBVDJ1H7ov81TSBfk=.931a8ea3-c402-4395-997a-cc8a94652407@github.com>
Message-ID: <JUuaW4pu8DhSvS_THkeEaLXZH29B-mePRZxu5WPxS6Y=.1b40150f-825f-4818-8da8-18b1feca50ab@github.com>

On Fri, 2 Jun 2023 08:38:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think SegmentAllocator should be agnostic re. thread safety. Allocation is a world of compromises, where if you give up (thread) safety you can gain more performance (and viceversa). So I think having a "one size fits all" thread-safety blanket might not work very well.
>
>> I think SegmentAllocator should be agnostic re. thread safety. Allocation is a world of compromises, where if you give up (thread) safety you can gain more performance (and viceversa). So I think having a "one size fits all" thread-safety blanket might not work very well.
> 
> I'm just trying to think about the practical implications of this.  Arena is specified to be thread-safe so I can allocate from a non-confined Arena, and from concurrent threads, without needing to coordinate.  However, if you hand me a SegmentAllocator that is not an Arena then I don't know if I need to coordinate allocation with other parties. I'm not too concerned about the slicingAllocator and prefixAllocator factory methods as the result SegmentAllocators will likely be wrapped.

In practice, SegmentAllocator will be used in two cases:
* as a parameter to a downcall method handle which returns a by-value struct
* as a building block to construct a custom arena

In both cases, I think it's up to the client to decide how thread-safe allocation should be. For instance, if you use a SegmentAllocator in a custom arena, and the allocator is not thread-safe, well, you can always attach it to a custom _confined_ arena (so that thread-unsafety is not a problem). I think using a SegmentAllocator in isolation will be quite rare.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214174042

From mcimadamore at openjdk.org  Fri Jun  2 10:12:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 10:12:10 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <JUuaW4pu8DhSvS_THkeEaLXZH29B-mePRZxu5WPxS6Y=.1b40150f-825f-4818-8da8-18b1feca50ab@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
 <QmcL2lMeMi5zVkAfxJtmjhBD8pcw6KmNClEgYoY8QJw=.37c2e5d7-a10a-4e2d-9fc4-dad0b77d0bc7@github.com>
 <sZPemWRLSj2KrBHoONR5uRdHIsbBVDJ1H7ov81TSBfk=.931a8ea3-c402-4395-997a-cc8a94652407@github.com>
 <JUuaW4pu8DhSvS_THkeEaLXZH29B-mePRZxu5WPxS6Y=.1b40150f-825f-4818-8da8-18b1feca50ab@github.com>
Message-ID: <SHJVWoE-s0lJD1onYgMGl6TTuhO8z1ZurFW2JVWUDww=.750f77af-89b5-4bb5-a121-f88508b53526@github.com>

On Fri, 2 Jun 2023 09:58:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> I think SegmentAllocator should be agnostic re. thread safety. Allocation is a world of compromises, where if you give up (thread) safety you can gain more performance (and viceversa). So I think having a "one size fits all" thread-safety blanket might not work very well.
>> 
>> I'm just trying to think about the practical implications of this.  Arena is specified to be thread-safe so I can allocate from a non-confined Arena, and from concurrent threads, without needing to coordinate.  However, if you hand me a SegmentAllocator that is not an Arena then I don't know if I need to coordinate allocation with other parties. I'm not too concerned about the slicingAllocator and prefixAllocator factory methods as the result SegmentAllocators will likely be wrapped.
>
> In practice, SegmentAllocator will be used in two cases:
> * as a parameter to a downcall method handle which returns a by-value struct
> * as a building block to construct a custom arena
> 
> In both cases, I think it's up to the client to decide how thread-safe allocation should be. For instance, if you use a SegmentAllocator in a custom arena, and the allocator is not thread-safe, well, you can always attach it to a custom _confined_ arena (so that thread-unsafety is not a problem). I think using a SegmentAllocator in isolation will be quite rare.

Note that, beside thread-safety, there are other things that are inconvenient about a segment allocator:
* an allocator is not constrained to return segments with the same lifetime;
* an allocator does not provide any guarantee re. aliasing memory. Same memory region could be written over and over (this is what prefixAllocator does);

These facts make it hard for clients SegmentAllocator to interact with a SegmentAllocator they don't own (unless they have to allocate precisely _one_ segment, on behalf of the client, and return it to them - which, not surprisingly is also what the Linker does). So, with SegmentAllocators there's always an element of trust: a client gave me an allocator to obtain a slab of memory, I trust the client to have done what it needed to do so that my operation can be safe. If I happen to allocate garbage (as a result of a race) it's on them.

If you need to allocate multiple segments in a single "session", and have some lifetime guarantees of the segments that have been allocated and/or you want to make sure that what you get is not garbage (e.g. thread-safety, aliasing, etc.), then you need Arena.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214183868

From duke at openjdk.org  Fri Jun  2 10:14:00 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 2 Jun 2023 10:14:00 GMT
Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base
Message-ID: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>

Compiling on AIX with xlc17 which contains the new clang 15 frontend
shows the following warnings.

built by make/modules/java.base/Lib.gmk

src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
^

src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
end = (void *)nddp + size;
~~~~~~~~~~~~ ^

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
#elif _ALLBSD_SOURCE


built by make/modules/java.base/lib/CoreLibraries.gmk

src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
if (ret < sizeof(psinfo_t)) {
^

src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
addr < p->ldinfo_textorg + p->ldinfo_textsize) {
~~~~~~~~~~~~~~~~~ ^

src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
void ZLIB_INTERNAL inflate_fast(strm, start)
^
src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
vfprintf(stderr, fmt, vl);
^~~

The test library libGetXSpace.c also shows a warning.
In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.

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

Commit messages:
 - JDK-8309219

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

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

From mcimadamore at openjdk.org  Fri Jun  2 10:19:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 10:19:09 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <3cPudNa3sSX5YbcoXvPy82F8-djLnh4b56Mdb0huj4k=.ce7e334a-d121-49bd-b478-f9fad49f50af@github.com>
Message-ID: <jqbiZV-IrqOMvvveqElbTCfj8JQ83o3Y6nVk77E14BA=.186166bc-c814-4948-b96b-96501f48093c@github.com>

On Thu, 1 Jun 2023 13:04:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 57:
> 
>> 55: 
>> 56:     /**
>> 57:      * {@return the argument layouts of this function descriptor (as an immutable list)}.
> 
> I assume this should be "unmodifiable" rather than immutable here.

This was derived from MethodType::parameterList, which also mentions immutable. I'm fine changing to "unmodifiable".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214190239

From asotona at openjdk.org  Fri Jun  2 10:47:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Jun 2023 10:47:06 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v2]
In-Reply-To: <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
 <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
Message-ID: <KT4S1E_g7e5V_K70VjcMCr7AhA3rh6O-LX9pjzxbPCs=.cd34c67e-f5c5-4d09-8dc6-b0239fa8031d@github.com>

On Thu, 1 Jun 2023 19:23:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Module.java line 1593:
>> 
>>> 1591:     private Class<?> loadModuleInfoClass(InputStream in) throws IOException {
>>> 1592:         final String MODULE_INFO = "module-info";
>>> 1593:         var cc = Classfile.of(Classfile.ConstantPoolSharingOption.DO_NOT_SHARE_CONSTANT_POOL);
>> 
>> This `cc` can be stored in a static final field instead.
>
> Yes, we can avoid repeated construction of default class hierarchy resolver here.

In this situation the ClassHierarchyResolver is never used and have no caching function.
Adding static field with initializer does not make much sense here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1214214987

From mcimadamore at openjdk.org  Fri Jun  2 10:48:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 10:48:14 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <x0VjOYnyIFKlW2MGq4VnkeazIQa8YnavwnNmNk8fE3o=.6fd5eb0d-b963-4575-a2e1-bcb960c63fc9@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <x0VjOYnyIFKlW2MGq4VnkeazIQa8YnavwnNmNk8fE3o=.6fd5eb0d-b963-4575-a2e1-bcb960c63fc9@github.com>
Message-ID: <IPjxOQVzSJWIScDkDNAZH5mTO-cQn6DoEX_lSu8HlPc=.9bfad9f8-dd89-49c3-b69f-14dceabedc22@github.com>

On Thu, 1 Jun 2023 21:09:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 201:
>> 
>>> 199:  * <p>
>>> 200:  * All native linker implementations operate on a subset of memory layouts. More formally, a layout {@code L}
>>> 201:  * is supported by a native linker {@code NL} iff:
>> 
>> I think using `iff` (if-and-only-if) is incorrect here, since certain linkers might impose additional constraints. For instance, the fallback linker doesn't support union layouts. Also, we want to further restrict variadic argument layouts as well as part of https://github.com/openjdk/jdk/pull/14225
>> 
>> Maybe we could say that all layouts passed to a linker must _at least_ adhere to the following constraints.
>
> I'll think about it - it's a bit problematic to specify in terms of "at least" because we need to be able to refer to "supported by NL" recursively in the text.

I'll replace "if" with "iff". I think to address your comment on linker options affecting what's supported, we can add a paragraph in that sense (but I think I'd like to do that after we fix https://git.openjdk.org/jdk/pull/14225, so that I can add a link to somewhere concrete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214215055

From mcimadamore at openjdk.org  Fri Jun  2 10:51:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 10:51:10 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
Message-ID: <yzVwQZ3PQ6rlXi8WKn7J3eajxYieJt-fqBNjTQDjUJU=.d188fb80-2d51-4f8c-9949-609a291a54b3@github.com>

On Thu, 1 Jun 2023 19:58:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 71:
> 
>> 69:      *
>> 70:      * @param order the desired byte order.
>> 71:      * @return a value layout with the same characteristics as this layout, but with the given byte order.
> 
> Also seems like a candidate for `{@return ...}`

Possibly. The text is consistent in using different wording between the header and return (as I did a pass in that sense), but perhaps that's a bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214217959

From mcimadamore at openjdk.org  Fri Jun  2 11:10:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 11:10:09 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
Message-ID: <GGkfsA0-A_EfacwRaR9kDUGuTR9oIQgmjIH68rn5TL0=.60419f7e-9d66-414e-aae6-b644bdb59f70@github.com>

On Thu, 1 Jun 2023 21:02:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 418:
>> 
>>> 416:      *
>>> 417:      * @param elements the layout path elements.
>>> 418:      * @return a var handle that accesses a memory segment at the offset selected by the given layout path.
>> 
>> This doesn't seem quite right. It is not the memory segment which is found at the offset given by the layout path, it is the base address.
>> 
>> Maybe:
>> Suggestion:
>> 
>>      * @return a var handle that accesses a memory segment whose base address is found at the offset selected by the given layout path.
>
> Yeah - I meant what you said - but now that you said it, I also saw how what I've written can be prone to an alternate (and wrong) interpretation. I'll clarify.

Actually, looking back at this I'm not sure it's correct? We have an input memory segment MS. And a layout path. A layout path identifies an offset O at which MS has to be accessed in order to read a value (of some type). I'm not sure any of this depends on "base address" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214235804

From asotona at openjdk.org  Fri Jun  2 11:24:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 2 Jun 2023 11:24:20 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v3]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <MAyCvxZOkEK7oPuPM7JmMZItULNwGpbo0oV6vVoOHM8=.c96f9021-9c7f-417a-81b2-a44c863ea6c3@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> 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 22 additional commits since the last revision:

 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - added Classfile context parameter to ClasRemapper::remapClass
 - records and methods implementations moved from Classfile to ClassfileImpl
 - added Classfile::buildTo override
 - implementation of Classfile::withOptions(Option... options)
   ClassfileImpl made immutable
   "options" use across implementation renamed to "context"
 - added test for StackMapsOption.ALWAYS_GENERATE_STACK_MAPS
   fixed DirectCodeBuilder and added fast bypass when stack map is not needed
 - ... and 12 more: https://git.openjdk.org/jdk/compare/0945a741...f8915f91

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/eae9bed3..f8915f91

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

  Stats: 20638 lines in 447 files changed: 15729 ins; 1904 del; 3005 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From mcimadamore at openjdk.org  Fri Jun  2 11:41:38 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 11:41:38 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v5]
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <V-Z6J9dH6z_ERZDa0tGIqS0V1v8WTeUdChUXmpMQ7uc=.d81a4920-37f5-4f54-941f-4e107ea31636@github.com>

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an ...

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

 - Missed a review comment
 - Use more `{@return}` tags
 - Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14098/files
  - new: https://git.openjdk.org/jdk/pull/14098/files/265e0d5b..44b382dd

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

  Stats: 79 lines in 12 files changed: 12 ins; 15 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

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

From mcimadamore at openjdk.org  Fri Jun  2 11:44:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 11:44:23 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
Message-ID: <1OUz3rHrOqiGV5EsjJxqWUJa6xjhPsJZxdri320sPoY=.5e92ec5b-3638-42a4-b32f-d5e73714c16b@github.com>

On Mon, 29 May 2023 10:53:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong link in layout well-formedness doc

Thanks for the comments so far, I've updated the javadoc in place:
https://cr.openjdk.org/~mcimadamore/jdk/8308645/javadoc/java.base/java/lang/foreign/package-summary.html

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

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1573599201

From jvernee at openjdk.org  Fri Jun  2 11:49:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 11:49:11 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <GGkfsA0-A_EfacwRaR9kDUGuTR9oIQgmjIH68rn5TL0=.60419f7e-9d66-414e-aae6-b644bdb59f70@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <62taiqcs7jZRPCvDZ5Ltd4Fb0QOByg3zvaG7OMEKPoU=.50734a98-539a-4fb4-a2b8-2bb0cfa07d17@github.com>
 <GGkfsA0-A_EfacwRaR9kDUGuTR9oIQgmjIH68rn5TL0=.60419f7e-9d66-414e-aae6-b644bdb59f70@github.com>
Message-ID: <YVtKVrrIPHcuLJWkSYBOVGCyrVYiivgHtzyCM-6bLPk=.a09a150a-1a9f-4678-ac46-e0960baf8ba2@github.com>

On Fri, 2 Jun 2023 11:07:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Yeah - I meant what you said - but now that you said it, I also saw how what I've written can be prone to an alternate (and wrong) interpretation. I'll clarify.
>
> Actually, looking back at this I'm not sure it's correct? We have an input memory segment MS. And a layout path. A layout path identifies an offset O at which MS has to be accessed in order to read a value (of some type). I'm not sure any of this depends on "base address" ?

Hmm, that's true. The base address that we read and turn into a memory segment isn't necessarily accessed, but the MS we read the base address from is. So, on second thought, I think the current text is good as it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214272188

From jlaskey at openjdk.org  Fri Jun  2 11:51:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 11:51:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v30]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <NWJ1FTjFDNJvCy3OixcD-CZYrSQtRs8ql6RlFD_tcl0=.890c5a56-545f-44e4-94e1-d2f52101ea78@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into 8306112
 - Update reflection to follow spec
 - Merge branch 'master' into 8306112
 - Integrating JDK-8308913
 - Integrate JDK-8308916 and  JDK-8308831 - javax.model
 - Missing Preview feature enum
 - Restrict access to unnamed class members when doing separate compilation.
 - Merge branch 'master' into 8306112
 - Remove mandated flag
 - Remove trailing whitespace
 - ... and 37 more: https://git.openjdk.org/jdk/compare/dc8bc6c9...0edcd9ae

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=29
  Stats: 1678 lines in 41 files changed: 1500 ins; 32 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jwaters at openjdk.org  Fri Jun  2 11:55:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 2 Jun 2023 11:55:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <HlQFUkd2tqt4ac7yZ5PxNOESR1wumD_kHS55x5FgPp4=.ce755874-c920-4e38-804a-ec344573b1b8@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <HlQFUkd2tqt4ac7yZ5PxNOESR1wumD_kHS55x5FgPp4=.ce755874-c920-4e38-804a-ec344573b1b8@github.com>
Message-ID: <BsmdPW642IrO-SFPRr1_O9B2UJmgXhQg-7tl90IwXK0=.5384f33d-ae2d-4bb3-b684-df10b219e937@github.com>

On Thu, 1 Jun 2023 17:43:02 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm not sure I understand the logic here. I would not want to move to using Java typedefs in places where the windows APIs specify the types they are expecting. If something comes in from a JNI down-call we should convert it to the type expected by Windows using the name expected by Windows.

I can change the jints in this PR to regular ints if required. As listed above, the native Windows API routines that the java.desktop code calls are actually expecting ints, so our existing declarations of passing longs to them are also wrong regardless, even without the Java typedefs

Actually, now that I revisit this issue (shown in the list above), the only actual calls in this change that _don't_ take Java typedefs are the calls to ::Arc and ::Pie, so this is less of a problem than initially expected

> Also "compilation" isn't nearly good enough. How is this being tested?

`-permissive-`

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1573611091

From erikj at openjdk.org  Fri Jun  2 14:07:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 Jun 2023 14:07:09 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
 <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
 <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>
Message-ID: <SD7hzglOVjoSLADlSgMYRPL07fq8z9fDHXausUDgI1k=.61e33381-4b31-4e34-ab26-cfb587499a48@github.com>

On Thu, 1 Jun 2023 23:38:03 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Sounds good for solving the macosx `ar` limitation differently. I'll change that. We can also exclude the partial linking part for gcc (due the older tool issue that you've found). Any concerns with including partial linking step for clang on Linux?

I have no concerns regarding clang on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1573796012

From jvernee at openjdk.org  Fri Jun  2 15:11:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 15:11:34 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v5]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <0U6OHpqxSagnCFgRmh9lsYVn8cFfoImNp1SYL8To3Yc=.8e312520-78c6-4f0c-ab91-e8accddcbeb0@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
> 
> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
> 
> Testing:
> - local testing on Windows/x64
> - tier1-3 + jdk-tier5 (ongoing)
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

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

  automatically apply variadic promotions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/1f1e22eb..38d759d6

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

  Stats: 177 lines in 8 files changed: 110 ins; 51 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14225/head:pull/14225

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

From rriggs at openjdk.org  Fri Jun  2 15:14:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Jun 2023 15:14:23 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <FdD9VBeUxlRvfjK4py0ToEZWyFOYLBJ0j3k8jTLR9hs=.93308710-6823-4d9c-9510-4a1b78f60231@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

PR#[14063](https://github.com/openjdk/jdk/pull/14063) to add byte order and address size to Architecture has been updated but not integrated.
It has no immediate use except perhaps this PR.
So I think it can/should wait for integration until after the fork @ RPD1.

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

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1573892813

From jvernee at openjdk.org  Fri Jun  2 15:16:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 15:16:28 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v6]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <yiEfKt8v8lD7tkqBIh5bM3VRnwiDmbw-vBGq0ksseGY=.ecc9d006-54d5-4ecc-aa18-81e9c9a90089@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
> 
> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
> 
> Testing:
> - local testing on Windows/x64
> - tier1-3 + jdk-tier5 (ongoing)
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

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

 - Merge branch 'master' into VAFixes
 - undo spurious whitespace changes
 - automatically apply variadic promotions
 - move prototype-less name
 - Rework javadoc
 - review comments
 - fix word order
 - adjust whitespace
 - simplify test changes
 - reject invalid variadic layouts
 - ... and 1 more: https://git.openjdk.org/jdk/compare/ad4d487a...9daadbfc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/38d759d6..9daadbfc

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

  Stats: 16078 lines in 335 files changed: 13372 ins; 1441 del; 1265 mod
  Patch: https://git.openjdk.org/jdk/pull/14225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14225/head:pull/14225

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

From jvernee at openjdk.org  Fri Jun  2 15:16:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 15:16:30 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v4]
In-Reply-To: <f9-JSFMawDZ9cDg7uCtLuqeH6XVYN5Jhhu5RJHlU7O8=.6b877852-c0dc-4a97-8f94-0e09896115c7@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <f9-JSFMawDZ9cDg7uCtLuqeH6XVYN5Jhhu5RJHlU7O8=.6b877852-c0dc-4a97-8f94-0e09896115c7@github.com>
Message-ID: <VN7TfV6QIgzpeXkkXolAq8eBHu5PntiiboHZEFUJTQM=.7e7bb47a-3d64-47e3-8509-1100ef15021f@github.com>

On Thu, 1 Jun 2023 15:28:33 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
>> 
>> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - tier1-3 + jdk-tier5 (ongoing)
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move prototype-less name

After some offline discussion with Maurizio, we concluded that the linker should automatically apply the needed argument promotions, rather than reject the 'incorrect' layouts. This is more convenient to the user because they don't have to figure out how to do the promotions, but also because they don't have to figure out the platform dependent promotion process.

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

PR Comment: https://git.openjdk.org/jdk/pull/14225#issuecomment-1573892839

From mcimadamore at openjdk.org  Fri Jun  2 15:55:13 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 15:55:13 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v6]
In-Reply-To: <yiEfKt8v8lD7tkqBIh5bM3VRnwiDmbw-vBGq0ksseGY=.ecc9d006-54d5-4ecc-aa18-81e9c9a90089@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <yiEfKt8v8lD7tkqBIh5bM3VRnwiDmbw-vBGq0ksseGY=.ecc9d006-54d5-4ecc-aa18-81e9c9a90089@github.com>
Message-ID: <qc_mFkmMo_PfSco8CaDfHzLIhvlHc4HbaE4GNGDUtZY=.03a92e35-7ddf-47ea-aca3-a8155c7993a5@github.com>

On Fri, 2 Jun 2023 15:16:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains this.
>> 
>> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - local testing on Linux/x64 using the fallback linker
>> - tier1-3 + jdk-tier5
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into VAFixes
>  - undo spurious whitespace changes
>  - automatically apply variadic promotions
>  - move prototype-less name
>  - Rework javadoc
>  - review comments
>  - fix word order
>  - adjust whitespace
>  - simplify test changes
>  - reject invalid variadic layouts
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/5aae3daf...9daadbfc

Looks good. I left minor stylistic comments.

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 261:

> 259:     // and float is promoted to double
> 260:     // See: https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions
> 261:     private static FunctionDescriptor promoteVariadicArgs(FunctionDescriptor function, int firstVariadicArgIndex) {

Maybe it's unneeded optimization, but we're scanning the list of layouts once, and then once again to determine the resulting method type. Should we try to do both in one pass?

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 327:

> 325:     }
> 326: 
> 327:     private static boolean requiresVariadicFloatPromotion(ValueLayout vl) {

Should this be called `requiresVariadicDoublePromotion` ? (In the other method we say `int`, which is the target of the conversion).

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14225#pullrequestreview-1457862860
PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1214549997
PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1214545214

From bpb at openjdk.org  Fri Jun  2 15:57:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 15:57:31 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
Message-ID: <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>

> For Unix, copy the `jchar`s into an allocated `char` array.

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

  8309216: Reformat malloc size calculation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14276/files
  - new: https://git.openjdk.org/jdk/pull/14276/files/fb730a18..18506101

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

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

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

From jvernee at openjdk.org  Fri Jun  2 15:59:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 15:59:09 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v6]
In-Reply-To: <qc_mFkmMo_PfSco8CaDfHzLIhvlHc4HbaE4GNGDUtZY=.03a92e35-7ddf-47ea-aca3-a8155c7993a5@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <yiEfKt8v8lD7tkqBIh5bM3VRnwiDmbw-vBGq0ksseGY=.ecc9d006-54d5-4ecc-aa18-81e9c9a90089@github.com>
 <qc_mFkmMo_PfSco8CaDfHzLIhvlHc4HbaE4GNGDUtZY=.03a92e35-7ddf-47ea-aca3-a8155c7993a5@github.com>
Message-ID: <oTUTZ064ZiCjpuUYEKvMjpeJ8YTxatDtTOinUX9ZhE4=.027dd1a9-6ce0-41e5-890f-a21c391fca50@github.com>

On Fri, 2 Jun 2023 15:47:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into VAFixes
>>  - undo spurious whitespace changes
>>  - automatically apply variadic promotions
>>  - move prototype-less name
>>  - Rework javadoc
>>  - review comments
>>  - fix word order
>>  - adjust whitespace
>>  - simplify test changes
>>  - reject invalid variadic layouts
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/973fe55b...9daadbfc
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 327:
> 
>> 325:     }
>> 326: 
>> 327:     private static boolean requiresVariadicFloatPromotion(ValueLayout vl) {
> 
> Should this be called `requiresVariadicDoublePromotion` ? (In the other method we say `int`, which is the target of the conversion).

Yes, I can do that. I was going for 'int' meaning 'integral' and 'float' meaning floating point. But I think your suggestion is clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1214553721

From jvernee at openjdk.org  Fri Jun  2 16:22:43 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 16:22:43 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v7]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <TDPUixLUZqjYbpMf9ypKU0IR4HSogqnlsnPKiXhcIwg=.a594c924-9c07-41dd-bf44-baf944a75d60@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains this.
> 
> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
> 
> Testing:
> - local testing on Windows/x64
> - local testing on Linux/x64 using the fallback linker
> - tier1-3 + jdk-tier5
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

Jorn Vernee 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/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/9daadbfc..3ec04fa6

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

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

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

From jvernee at openjdk.org  Fri Jun  2 16:22:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 16:22:45 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v6]
In-Reply-To: <qc_mFkmMo_PfSco8CaDfHzLIhvlHc4HbaE4GNGDUtZY=.03a92e35-7ddf-47ea-aca3-a8155c7993a5@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <yiEfKt8v8lD7tkqBIh5bM3VRnwiDmbw-vBGq0ksseGY=.ecc9d006-54d5-4ecc-aa18-81e9c9a90089@github.com>
 <qc_mFkmMo_PfSco8CaDfHzLIhvlHc4HbaE4GNGDUtZY=.03a92e35-7ddf-47ea-aca3-a8155c7993a5@github.com>
Message-ID: <cQOirZJlcV1mpEIdv1MzZ1nXu2q8wqemtrlV2g5iz0U=.2d12d408-f4cb-407c-97f9-4a8c20622b2b@github.com>

On Fri, 2 Jun 2023 15:52:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into VAFixes
>>  - undo spurious whitespace changes
>>  - automatically apply variadic promotions
>>  - move prototype-less name
>>  - Rework javadoc
>>  - review comments
>>  - fix word order
>>  - adjust whitespace
>>  - simplify test changes
>>  - reject invalid variadic layouts
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/16267ba7...9daadbfc
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 261:
> 
>> 259:     // and float is promoted to double
>> 260:     // See: https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions
>> 261:     private static FunctionDescriptor promoteVariadicArgs(FunctionDescriptor function, int firstVariadicArgIndex) {
> 
> Maybe it's unneeded optimization, but we're scanning the list of layouts once, and then once again to determine the resulting method type. Should we try to do both in one pass?

I considered keeping track of the promoted args in a boolean[], but I figured it was simpler to just scan the layouts again. And this is not really performance critical code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1214570923

From psandoz at openjdk.org  Fri Jun  2 16:32:10 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 2 Jun 2023 16:32:10 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
Message-ID: <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>

On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> 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 11 additional commits since the last revision:
> 
>  - Compute base and offset right after linking, simplify code
>  - Merge branch 'master' into lazy-static-varhandle
>  - Fix exact swap
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/cf71f03a...27e18b7c

The latest revision looks a much better arrangement.

I wonder if it is possible to transition from an lazy (indirect) VH to a direct VH once initialized i.e., `checkAccessModeThenIsDirect` returns the value of `initialized`. Thereby we reduce the potential footprint cost of inflating further MHs and take the more efficient route through the guard method on subsequent invocations.

Not thought through all the implications of this, but since this will all occur in the interpreter it may well work out. We then get closer, conceptually at least, to the behavior of static field access using direct MHs.

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

PR Review: https://git.openjdk.org/jdk/pull/13821#pullrequestreview-1457968612

From jvernee at openjdk.org  Fri Jun  2 16:36:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 2 Jun 2023 16:36:14 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v5]
In-Reply-To: <V-Z6J9dH6z_ERZDa0tGIqS0V1v8WTeUdChUXmpMQ7uc=.d81a4920-37f5-4f54-941f-4e107ea31636@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <V-Z6J9dH6z_ERZDa0tGIqS0V1v8WTeUdChUXmpMQ7uc=.d81a4920-37f5-4f54-941f-4e107ea31636@github.com>
Message-ID: <v1GgTvJiDcEQpmb3uqBuItHgueiwLUCmfCd_JGE2OME=.13cae8cb-be4e-449a-8dc0-d97a2192ed7c@github.com>

On Fri, 2 Jun 2023 11:41:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Missed a review comment
>  - Use more `{@return}` tags
>  - Address review comments

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 945:

> 943:      * cannot be returned if this segment's size is greater than {@link Integer#MAX_VALUE};</li>
> 944:      * <li>It is a {@linkplain ByteBuffer#isDirect() direct buffer}, if this is a native segment.</li>
> 945:      * </ul>

Nice!

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

PR Review: https://git.openjdk.org/jdk/pull/14098#pullrequestreview-1457977686
PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214587551

From mchung at openjdk.org  Fri Jun  2 16:47:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 16:47:09 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
Message-ID: <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>

On Fri, 2 Jun 2023 04:48:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explain in java.lang.Class how unnamed classes are modeled in core reflection.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update reflective support.

src/java.base/share/classes/java/lang/Class.java line 1884:

> 1882:                     reflective=true)
> 1883:     public boolean isUnnamedClass() {
> 1884:         return isSynthetic() && PreviewFeatures.isEnabled() && isTopLevelClass();

Should this include more tests such as not abstract, final, package access, in an unnamed package, etc to accurately determine it's an unnamed class?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1214597498

From mchung at openjdk.org  Fri Jun  2 17:19:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 17:19:07 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <XysH8cpSh7AcI_1M3C4TXGQ3sEGX7R4IZU-z58bf0RU=.47171f29-0768-417b-ba74-053a52938e57@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <XysH8cpSh7AcI_1M3C4TXGQ3sEGX7R4IZU-z58bf0RU=.47171f29-0768-417b-ba74-053a52938e57@github.com>
Message-ID: <TivwkU3LLeLZPo2z3EyP5BcA1cXiUdGM8e8hOl9FisI=.3aca153f-5aa7-4161-ade7-6988639fef89@github.com>

On Fri, 2 Jun 2023 02:37:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think we only need to initialize Parent without initializing Child in this case.
 
The bytecode behavior to access the field via `lookup.findStaticVarHandle(Child.class, "value", int[].class)` is `Child.value;`.  The class or interface that declared the resolved field is initialized per JVMS `getStatic` and `putStatic`.   So I think `Parent` is initialized but not `Child`.    @PaulSandoz can confirm.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574063904

From darcy at openjdk.org  Fri Jun  2 17:28:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 2 Jun 2023 17:28:08 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>
Message-ID: <jcjVgz58Koqd3e1TkzaQwsLZXSqBjyC-zYBw_MDwyJY=.982ddf89-5a08-4415-9bf4-97005716ff08@github.com>

On Fri, 2 Jun 2023 16:44:35 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update reflective support.
>
> src/java.base/share/classes/java/lang/Class.java line 1884:
> 
>> 1882:                     reflective=true)
>> 1883:     public boolean isUnnamedClass() {
>> 1884:         return isSynthetic() && PreviewFeatures.isEnabled() && isTopLevelClass();
> 
> Should this include more tests such as not abstract, final, package access, in an unnamed package, etc to accurately determine it's an unnamed class?

Hmm. I think adding at least a check for ACC_FINAL should be fine as it should have near-zero cost on top of the existing predicate once the method get compiled. (In future iterations of the JEP, the idiom to identify isUnnamed will likely change.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1214633943

From naoto at openjdk.org  Fri Jun  2 17:32:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Jun 2023 17:32:11 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
Message-ID: <XljfwkOCw965HSNVEPIjZ4aPdtfviNDpArfMpr8zvyw=.6b8af48e-9113-43d5-8409-4fd6fd676798@github.com>

On Wed, 31 May 2023 21:58:44 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust javadoc

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12985#pullrequestreview-1458112588

From bchristi at openjdk.org  Fri Jun  2 18:01:06 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 2 Jun 2023 18:01:06 GMT
Subject: RFR: 8309241: ClassForNameLeak fails intermittently as the class
 loader hasn't been unloaded
In-Reply-To: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
References: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
Message-ID: <_cpHHwjwKmLlXTKbg6OMb7Oa9eCZLMjy0MvOiLBFewk=.ccd50eda-dd38-4df8-99fa-a4b2482e71a3@github.com>

On Thu, 1 Jun 2023 18:19:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Convert `ClassForNameLeak` test to use `jdk.test.lib.util.ForceGC` that would be more reliable in waiting for the class loader to be unloaded.

Good changes.

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

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14269#pullrequestreview-1458179600

From jlaskey at openjdk.org  Fri Jun  2 18:12:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 18:12:07 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <jcjVgz58Koqd3e1TkzaQwsLZXSqBjyC-zYBw_MDwyJY=.982ddf89-5a08-4415-9bf4-97005716ff08@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>
 <jcjVgz58Koqd3e1TkzaQwsLZXSqBjyC-zYBw_MDwyJY=.982ddf89-5a08-4415-9bf4-97005716ff08@github.com>
Message-ID: <UgVstUU2bWyzfPS5dc-4FWZohu_UF0jEhF2-E28QDKc=.86f7d7f3-44da-47be-96f3-f755912f47ff@github.com>

On Fri, 2 Jun 2023 17:25:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 1884:
>> 
>>> 1882:                     reflective=true)
>>> 1883:     public boolean isUnnamedClass() {
>>> 1884:         return isSynthetic() && PreviewFeatures.isEnabled() && isTopLevelClass();
>> 
>> Should this include more tests such as not abstract, final, package access, in an unnamed package, etc to accurately determine it's an unnamed class?
>
> Hmm. I think adding at least a check for ACC_FINAL should be fine as it should have near-zero cost on top of the existing predicate once the method get compiled. (In future iterations of the JEP, the idiom to identify isUnnamed will likely change.)

As mentioned in https://bugs.openjdk.org/browse/JDK-8308916 the expression should be `PreviewFeatures.isEnabled() && isSynthetic() &&  isTopLevelClass()` as `PreviewFeatures.isEnabled()` is a private static final test that will effectively make the full expression constant `false` when not in preview mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1214670484

From mchung at openjdk.org  Fri Jun  2 18:15:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 18:15:12 GMT
Subject: Integrated: 8309241: ClassForNameLeak fails intermittently as the
 class loader hasn't been unloaded
In-Reply-To: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
References: <DcwLIUb9WN8QnguumIEC4gFiGygpClabfiYWK-Etrek=.85e7f60d-7dc0-4293-adf2-113f1a0c604e@github.com>
Message-ID: <TjTfrrsbc8WO2HwAgLJO0w-KHMjl6-YRwQhjam5JpLM=.aeff0509-5feb-4145-9244-a5e2cf71d5c9@github.com>

On Thu, 1 Jun 2023 18:19:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Convert `ClassForNameLeak` test to use `jdk.test.lib.util.ForceGC` that would be more reliable in waiting for the class loader to be unloaded.

This pull request has now been integrated.

Changeset: a23bbea9
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a23bbea9593a85a9d60431e68805efa6f960a4d4
Stats:     58 lines in 1 file changed: 15 ins; 29 del; 14 mod

8309241: ClassForNameLeak fails intermittently as the class loader hasn't been unloaded

Reviewed-by: dnsimon, bchristi

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

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

From smarks at openjdk.org  Fri Jun  2 18:19:12 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 Jun 2023 18:19:12 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
Message-ID: <FdhoAPQmaqhtUbIs-ZnQYaGm2ia4sxM_lktrw33z-Zg=.7e473cd3-42fe-42ac-9441-8886d886aeea@github.com>

On Wed, 31 May 2023 21:58:44 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust javadoc

src/java.xml/share/classes/jdk/xml/internal/JdkConstants.java line 291:

> 289:      */
> 290:     public static final String CONFIG_FILE = "java.xml.config.file";
> 291: 

This isn't the name of the config file but instead is the name of the _property_ that points to the config file. At some point maybe this could be renamed, maybe to CONFIG_FILE_PROPNAME or something.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1214676010

From bpb at openjdk.org  Fri Jun  2 18:40:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 18:40:08 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
 <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
Message-ID: <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>

On Fri, 2 Jun 2023 18:26:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8309216: Reformat malloc size calculation
>
> test/jdk/java/io/File/libGetXSpace.c line 85:
> 
>> 83:         // use GetDiskSpaceInformationW
>> 84:         DISK_SPACE_INFORMATION diskSpaceInfo;
>> 85:         BOOL hres = pfnGetDiskSpaceInformation(path, &diskSpaceInfo);
> 
> The strchars/path could be released before checking the return; keeping the cleanup in the common flow.
> Here and below after calling GetDiskFreeSpaceExW.
> Your call.

Good idea; will update.

> test/jdk/java/io/File/libGetXSpace.c line 142:
> 
>> 140:     for (int i = 0; i < len; i++) {
>> 141:         chars[i] = (char)strchars[i];
>> 142:     }
> 
> Is this `memcpy(chars, strchars, len);`

I don't think so if `chars` is `char *` and `strchars` is `jchar*` as I think `char` is 8 bits and `jchar` is 16 bits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214692423
PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214692051

From rriggs at openjdk.org  Fri Jun  2 18:40:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Jun 2023 18:40:07 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
Message-ID: <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>

On Fri, 2 Jun 2023 15:57:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For Unix, copy the `jchar`s into an allocated `char` array.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309216: Reformat malloc size calculation

test/jdk/java/io/File/libGetXSpace.c line 85:

> 83:         // use GetDiskSpaceInformationW
> 84:         DISK_SPACE_INFORMATION diskSpaceInfo;
> 85:         BOOL hres = pfnGetDiskSpaceInformation(path, &diskSpaceInfo);

The strchars/path could be released before checking the return; keeping the cleanup in the common flow.
Here and below after calling GetDiskFreeSpaceExW.
Your call.

test/jdk/java/io/File/libGetXSpace.c line 142:

> 140:     for (int i = 0; i < len; i++) {
> 141:         chars[i] = (char)strchars[i];
> 142:     }

Is this `memcpy(chars, strchars, len);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214684070
PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214683954

From mchung at openjdk.org  Fri Jun  2 18:45:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 18:45:08 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <UgVstUU2bWyzfPS5dc-4FWZohu_UF0jEhF2-E28QDKc=.86f7d7f3-44da-47be-96f3-f755912f47ff@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>
 <jcjVgz58Koqd3e1TkzaQwsLZXSqBjyC-zYBw_MDwyJY=.982ddf89-5a08-4415-9bf4-97005716ff08@github.com>
 <UgVstUU2bWyzfPS5dc-4FWZohu_UF0jEhF2-E28QDKc=.86f7d7f3-44da-47be-96f3-f755912f47ff@github.com>
Message-ID: <L1pOpoNLF2SYdJ_4Peeb3S7-PTM87KEvvqqK6glMxm8=.6520a1ad-de3a-41a8-a8a3-61ccd0e785cc@github.com>

On Fri, 2 Jun 2023 18:09:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Hmm. I think adding at least a check for ACC_FINAL should be fine as it should have near-zero cost on top of the existing predicate once the method get compiled. (In future iterations of the JEP, the idiom to identify isUnnamed will likely change.)
>
> As mentioned in https://bugs.openjdk.org/browse/JDK-8308916 the expression should be `PreviewFeatures.isEnabled() && isSynthetic() &&  isTopLevelClass()` as `PreviewFeatures.isEnabled()` is a private static final test that will effectively make the full expression constant `false` when not in preview mode.

Checking package access should also have near-zero cost.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1214695722

From psandoz at openjdk.org  Fri Jun  2 18:46:10 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 2 Jun 2023 18:46:10 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <TivwkU3LLeLZPo2z3EyP5BcA1cXiUdGM8e8hOl9FisI=.3aca153f-5aa7-4161-ade7-6988639fef89@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <XysH8cpSh7AcI_1M3C4TXGQ3sEGX7R4IZU-z58bf0RU=.47171f29-0768-417b-ba74-053a52938e57@github.com>
 <TivwkU3LLeLZPo2z3EyP5BcA1cXiUdGM8e8hOl9FisI=.3aca153f-5aa7-4161-ade7-6988639fef89@github.com>
Message-ID: <yNLS4Az_KRgZER8HTmo7S7Tc92yGk78XSU10q_fqfyU=.271671f0-1dd2-4157-b2b5-01c513569cfe@github.com>

On Fri, 2 Jun 2023 17:16:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > I think we only need to initialize Parent without initializing Child in this case.
> 
> The bytecode behavior to access the field via `lookup.findStaticVarHandle(Child.class, "value", int[].class)` is `Child.value;`. The class or interface that declared the resolved field is initialized per JVMS `getStatic` and `putStatic`. So I think `Parent` is initialized but not `Child`. @PaulSandoz can confirm.

Yes, confirmed (verified both with explicit field access, `Child.value`,  and access using a direct method handle).

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574162809

From smarks at openjdk.org  Fri Jun  2 19:12:10 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 Jun 2023 19:12:10 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
Message-ID: <KcFjiAcFIk0ny1BivPSTX4ygaesPe1pWmysWLvVQ7c4=.c77a317b-daca-43ea-8186-24f95f572e94@github.com>

On Wed, 31 May 2023 21:58:44 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust javadoc

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java line 562:

> 560:             //invalid setting
> 561:             throw new NumberFormatException("Invalid setting for system property: " + limit.systemProperty());
> 562:         }

Kind of a questionable idiom here to catch NFE and then throw a new NFE, discarding the previous one. Maybe wrap instead? But the larger question is, I think, what should happen in this case. If the user sets a malformed property, will this cause exceptions to be thrown at arbitrary points in the program? Both items are things to consider for later.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java line 581:

> 579:                 }
> 580:             }
> 581:         }

It's a little hard to see what's going on here but this essentially boils down to a Map<String,String> mapping new names to old names. This or further refactoring should be considered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1214725620
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1214726907

From mchung at openjdk.org  Fri Jun  2 19:14:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 19:14:04 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
Message-ID: <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>

On Fri, 2 Jun 2023 16:29:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I wonder if it is possible to transition from an lazy (indirect) VH to a direct VH once initialized i.e., `checkAccessModeThenIsDirect` returns the value of `initialized`. 

Sounds a good idea.  Once the class is initialized, the lazy VH becomes a direct VH that may help the performance.  In that case, the VarHandleGuards would need to ensure it links with the direct VH not the lazy VH.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574191781

From mchung at openjdk.org  Fri Jun  2 19:14:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 19:14:11 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
Message-ID: <RxXqaQqlicf4f4USLKpP-oyQmUaYkSY026EZlWJ7XWg=.beab5c68-d6fd-4e4f-9c56-3adfcbb040a7@github.com>

On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> 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 11 additional commits since the last revision:
> 
>  - Compute base and offset right after linking, simplify code
>  - Merge branch 'master' into lazy-static-varhandle
>  - Fix exact swap
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d89020de...27e18b7c

src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 75:

> 73:     public VarHandle withInvokeExactBehavior() {
> 74:         var updatedDelegate = target.withInvokeExactBehavior();
> 75:         return initialized ? new LazyInitializingVarHandle(updatedDelegate, refc) : updatedDelegate;

Suggestion:

        return initialized ? updatedDelegate: new LazyInitializingVarHandle(updatedDelegate, refc);


If initialized, should return `updatedDelegate` instead.   Same for `withInvokeBehavior`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1214729466

From bpb at openjdk.org  Fri Jun  2 19:23:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 19:23:10 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v3]
In-Reply-To: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
Message-ID: <s2-i5fjiHjQuq_DjW0yAcsc8VbASOsga_nzilxRzn34=.9ac9dec1-a251-4a29-a448-42d0b8a901e4@github.com>

> For Unix, copy the `jchar`s into an allocated `char` array.

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

  8309216: Move string release into common flow (win)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14276/files
  - new: https://git.openjdk.org/jdk/pull/14276/files/18506101..0ecf89b1

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

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

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

From bpb at openjdk.org  Fri Jun  2 19:23:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 19:23:12 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
 <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
 <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
Message-ID: <ocp8xKcHAzoXsIk6qN5jfswCXFd5DiD6kMuBKv134Lo=.dfcbf486-6fd7-4ad5-831f-54e5461e1152@github.com>

On Fri, 2 Jun 2023 18:37:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/File/libGetXSpace.c line 85:
>> 
>>> 83:         // use GetDiskSpaceInformationW
>>> 84:         DISK_SPACE_INFORMATION diskSpaceInfo;
>>> 85:         BOOL hres = pfnGetDiskSpaceInformation(path, &diskSpaceInfo);
>> 
>> The strchars/path could be released before checking the return; keeping the cleanup in the common flow.
>> Here and below after calling GetDiskFreeSpaceExW.
>> Your call.
>
> Good idea; will update.

So changed in 0ecf89b1d060bb8c1a35402ec108cbe9f3f35bb9.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214735984

From smarks at openjdk.org  Fri Jun  2 19:27:12 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 2 Jun 2023 19:27:12 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
Message-ID: <mTHwk5WPcDrK4zqP9J9cJkfbEwiKxK7BC7X6rbVZl8U=.64ed997b-cddf-4146-8310-141d7e153f88@github.com>

On Wed, 31 May 2023 21:58:44 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust javadoc

Marked as reviewed by smarks (Reviewer).

Overall I think this is OK to go in as it stands. The specs have been thoroughly reviewed and the loading of the new config file needs to match the specs and it's been well tested. I especially like how the duplicated logic in the factory finders has been converted to centralized infrastructure.

Now that things are centralized, it's easier to find and highlight additional items for cleanup. This probably can be considered as technical debt that can be worked on over time. I've mentioned a few things near individual places in the code; I'll repeat them here for completeness. In addition there are a few other things I noticed that we should also probably look at at some point in the future.

JdkConstants.CONFIG_FILE could probably be renamed.

NameMap is mapping from new to old property names. This could probably be changed to a Map<String,String> instead of a search through the enum's values. There are only three enums (I think) so this isn't terrible, but it does add some extra code that could be simplified if it were changed to an actual Map. Another alternative is to merge the old name into the Limits enum itself, as another field; that would save a lookup and avoid having to keep a separate data structure in sync.

There are a few places where NumberFormatException is caught and then a new NFE is thrown, discarding the old one. The new one provides more information but it's a bit odd not to chain the exceptions. Unfortunately NFE doesn't have a chaining constructor; maybe one should be added? Alternatively, initCause() could be called.

A larger question is whether we want exceptions to be thrown from initialization code. This will have the effect of causing an exception to be thrown to arbitrary user code. (Or will it?) For property-reading code I think a better alternative is to ignore errant values, possibly issuing a warning message. However this will require further discussion.

There are two XMLSecurityManager files:
* com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java
* jdk/xml/internal/XMLSecurityManager.java

It seems like there's a lot of duplication between them. This should be revisited.

Meanwhile, in both XMLSecurityManagers the state loaded from config files, properties, etc. is stored in parallel arrays indexed by the enum's ordinals. This suggests an alternative which is to use an EnumMap. The value of the EnumMap could be a record consisting of the property value and its state (origin) and possibly whether it was set explicitly.

At some point we also might want to take another look at the tests. Testing configuration files indeed requires multiple invocations of the JVM. There are ways a single jtreg test can invoke multiple JVMs using multiple `@run` lines. Each can pass different arguments in order to run different test cases, even different test classes if necessary. But this will require additional thinking and discussion.

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

PR Review: https://git.openjdk.org/jdk/pull/12985#pullrequestreview-1458364801
PR Comment: https://git.openjdk.org/jdk/pull/12985#issuecomment-1574210212

From mchung at openjdk.org  Fri Jun  2 19:38:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 19:38:11 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
Message-ID: <PhVRofgRjottdNeAvYyyRbhFfbS4t28YUwBxuZPID34=.9699d6c6-ad77-4158-a51e-26feb4159c09@github.com>

On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> 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 11 additional commits since the last revision:
> 
>  - Compute base and offset right after linking, simplify code
>  - Merge branch 'master' into lazy-static-varhandle
>  - Fix exact swap
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4978eac7...27e18b7c

test/jdk/java/lang/invoke/VarHandles/LazyStaticTest.java line 42:

> 40:         assert initialized.isEmpty() : "Incorrect initial state";
> 41: 
> 42:         class Sample1 {

Nit: suggest to move this inner class outside of the method body.  I think it helps readability.   maybe name it as `Sample` or `Test` or sth.   I expect `Sample2` when I read `Sample1`.

test/jdk/java/lang/invoke/VarHandles/LazyStaticTest.java line 59:

> 57: 
> 58:         assert initialized.contains(Sample1.class) : "Sample1 class initialized after VarHandle use";
> 59:         assert Sample1.apple == 42 : "The value is not set correctly to Sample1.apple";

It may be good to extend the test case to invoke the lazy VH multiple times that will exercise in the case if lazy VH transitions to direct VH.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1214748270
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1214752797

From joehw at openjdk.org  Fri Jun  2 19:44:15 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 2 Jun 2023 19:44:15 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>
Message-ID: <Lz1jstCiEqKcZn4KTD3_ahfuvxuIvDWsckAWqHamlrw=.b5c30324-33a9-41e7-a5d4-370db5462168@github.com>

On Wed, 31 May 2023 21:58:44 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust javadoc

Thanks! Will discuss these issues in separate threads for each of them. The question on the duplication of XMLSecurityManager has an easier answer: the later was added to replace the former that was specific to Xerces. Note that the one for Xalan was already deleted. There were too many references. Since this changeset is already pretty large, I decided to leave it to a simpler changeset (e.g. DTD) to do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/12985#issuecomment-1574226021

From joehw at openjdk.org  Fri Jun  2 20:13:30 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 2 Jun 2023 20:13:30 GMT
Subject: Integrated: 8303530: Redefine JAXP Configuration File
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <Y_a5CjBTXUc20j7Emam3RAvIZf4328LSUAcUXsBh92I=.45e0f6b7-eebe-402f-9433-40b4aa5c680f@github.com>

On Sat, 11 Mar 2023 04:28:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

This pull request has now been integrated.

Changeset: aff9cea0
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff9cea05468daf60fa80c7d9993b3aa8497b0c5
Stats:     3948 lines in 56 files changed: 3177 ins; 581 del; 190 mod

8303530: Redefine JAXP Configuration File

Reviewed-by: naoto, lancea, alanb, smarks

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

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

From jlaskey at openjdk.org  Fri Jun  2 20:18:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 20:18:07 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v31]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <HK1h-vFWbotQHsYTAQyQFHjH6WsclwZ_cm0cBuq1XhU=.16f2e30b-393c-434f-9c97-ddc3aae86c7c@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Use getQualifiedName() to indicate unnamed class
 - ClassSymbol#getSimpleName() returning empty name breaks some tools

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/0edcd9ae..97a522f7

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

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

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

From rriggs at openjdk.org  Fri Jun  2 21:08:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Jun 2023 21:08:05 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v3]
In-Reply-To: <s2-i5fjiHjQuq_DjW0yAcsc8VbASOsga_nzilxRzn34=.9ac9dec1-a251-4a29-a448-42d0b8a901e4@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <s2-i5fjiHjQuq_DjW0yAcsc8VbASOsga_nzilxRzn34=.9ac9dec1-a251-4a29-a448-42d0b8a901e4@github.com>
Message-ID: <wD6M5PDi6CPlMaH29Cq7j__fk85J7LasgZxCkDSmESk=.87bdb696-ad53-459f-882c-53e3b743630e@github.com>

On Fri, 2 Jun 2023 19:23:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For Unix, copy the `jchar`s into an allocated `char` array.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309216: Move string release into common flow (win)

looks good; give someone else a chance to review also.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14276#pullrequestreview-1458477087

From cjplummer at openjdk.org  Fri Jun  2 21:38:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 21:38:08 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread names
 when using the virtual thread wrapper
Message-ID: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>

Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:

com/sun/jdi/JdbMethodExitTest.java
com/sun/jdi/JdbStepTest.java
com/sun/jdi/JdbStopThreadTest.java
com/sun/jdi/JdbStopThreadidTest.java

These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.

Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.

Testing was done by running all of tier1 and tier5.

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

Commit messages:
 - when using virtual threads, properly name the main threads

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

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

From naoto at openjdk.org  Fri Jun  2 22:04:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Jun 2023 22:04:05 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
 <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
 <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
Message-ID: <MNkpy8RP7-DrxfuJie7nMPf0TqPswSP6ESJIPgNiSto=.35d8d0f4-4f30-4685-b0be-befa4519f1a0@github.com>

On Fri, 2 Jun 2023 18:36:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/io/File/libGetXSpace.c line 142:
>> 
>>> 140:     for (int i = 0; i < len; i++) {
>>> 141:         chars[i] = (char)strchars[i];
>>> 142:     }
>> 
>> Is this `memcpy(chars, strchars, len);`
>
> I don't think so if `chars` is `char *` and `strchars` is `jchar*` as I think `char` is 8 bits and `jchar` is 16 bits.

I just wonder if jchar is UTF-16 and char is platform encoding, would it work by simply casting the low 8bit to char?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214882192

From jlaskey at openjdk.org  Fri Jun  2 22:10:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 2 Jun 2023 22:10:44 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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

  Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/97a522f7..55b6be5b

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

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

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

From bpb at openjdk.org  Fri Jun  2 22:21:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 22:21:04 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <MNkpy8RP7-DrxfuJie7nMPf0TqPswSP6ESJIPgNiSto=.35d8d0f4-4f30-4685-b0be-befa4519f1a0@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
 <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
 <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
 <MNkpy8RP7-DrxfuJie7nMPf0TqPswSP6ESJIPgNiSto=.35d8d0f4-4f30-4685-b0be-befa4519f1a0@github.com>
Message-ID: <O0lDfWUx8rONkIjVmiwuQ9cwIhUIGrfaeqGvMjoAE28=.a82b4c15-1164-49ea-8407-aa05ce8f947c@github.com>

On Fri, 2 Jun 2023 22:00:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I don't think so if `chars` is `char *` and `strchars` is `jchar*` as I think `char` is 8 bits and `jchar` is 16 bits.
>
> I just wonder if jchar is UTF-16 and char is platform encoding, would it work by simply casting the low 8bit to char?

Probably not. This is only intended to cover the constrained case of this test. Something like the macro `WITH_PLATFORM_STRING` in `libjava/io_util.h` would be needed for the general case, but I thought that that might be overdoing it for here. I could of course be mistaken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214895770

From naoto at openjdk.org  Fri Jun  2 22:26:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Jun 2023 22:26:06 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v3]
In-Reply-To: <s2-i5fjiHjQuq_DjW0yAcsc8VbASOsga_nzilxRzn34=.9ac9dec1-a251-4a29-a448-42d0b8a901e4@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <s2-i5fjiHjQuq_DjW0yAcsc8VbASOsga_nzilxRzn34=.9ac9dec1-a251-4a29-a448-42d0b8a901e4@github.com>
Message-ID: <_UUiLEq9i8_8bytdefQowLqhjm2A5rN8rHN0JoIvgQk=.87a5c2ed-5b9b-4242-b42a-9fba14863338@github.com>

On Fri, 2 Jun 2023 19:23:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For Unix, copy the `jchar`s into an allocated `char` array.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8309216: Move string release into common flow (win)

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14276#pullrequestreview-1458536200

From mcimadamore at openjdk.org  Fri Jun  2 22:26:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 2 Jun 2023 22:26:09 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v7]
In-Reply-To: <TDPUixLUZqjYbpMf9ypKU0IR4HSogqnlsnPKiXhcIwg=.a594c924-9c07-41dd-bf44-baf944a75d60@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <TDPUixLUZqjYbpMf9ypKU0IR4HSogqnlsnPKiXhcIwg=.a594c924-9c07-41dd-bf44-baf944a75d60@github.com>
Message-ID: <SHukDeIIz3b0ClcwKYkVd3mlRrlZlgb56UdpUvto_Xc=.160b63b7-fb7c-4e8b-8091-27cf3f065739@github.com>

On Fri, 2 Jun 2023 16:22:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains this.
>> 
>> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - local testing on Linux/x64 using the fallback linker
>> - tier1-3 + jdk-tier5
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comment

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14225#pullrequestreview-1458536809

From naoto at openjdk.org  Fri Jun  2 22:26:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 Jun 2023 22:26:08 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <O0lDfWUx8rONkIjVmiwuQ9cwIhUIGrfaeqGvMjoAE28=.a82b4c15-1164-49ea-8407-aa05ce8f947c@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
 <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
 <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
 <MNkpy8RP7-DrxfuJie7nMPf0TqPswSP6ESJIPgNiSto=.35d8d0f4-4f30-4685-b0be-befa4519f1a0@github.com>
 <O0lDfWUx8rONkIjVmiwuQ9cwIhUIGrfaeqGvMjoAE28=.a82b4c15-1164-49ea-8407-aa05ce8f947c@github.com>
Message-ID: <dHjqEDrda2FmSwEm57CAEk3jOkkBlLK2bO8G_Gw1AXk=.30e38d67-19aa-4b37-bc88-634987c1a158@github.com>

On Fri, 2 Jun 2023 22:18:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I just wonder if jchar is UTF-16 and char is platform encoding, would it work by simply casting the low 8bit to char?
>
> Probably not. This is only intended to cover the constrained case of this test. Something like the macro `WITH_PLATFORM_STRING` in `libjava/io_util.h` would be needed for the general case, but I thought that that might be overdoing it for here. I could of course be mistaken.

OK, if the usage is limited and covers the required test cases, that sounds reasonable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214899665

From bpb at openjdk.org  Fri Jun  2 22:31:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Jun 2023 22:31:05 GMT
Subject: RFR: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java [v2]
In-Reply-To: <dHjqEDrda2FmSwEm57CAEk3jOkkBlLK2bO8G_Gw1AXk=.30e38d67-19aa-4b37-bc88-634987c1a158@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
 <nuqHH1b5NQm-qTQbhNApUVm_46iowdhkT-W8A0eHnpE=.67900ece-1cd8-4baf-b8a9-100459ef0090@github.com>
 <rPd_r2y6rMICy8zOmO4v19u6sjJGtG-chPos61hQuzI=.1c5bbe58-a570-4c19-8739-a27ba5719529@github.com>
 <nUJLk5LVpyPK_8oncBQMRU741k6FABV_tF0am8S9UAE=.b563bc67-56d4-46bf-93d0-7a7a57dc2dc2@github.com>
 <MNkpy8RP7-DrxfuJie7nMPf0TqPswSP6ESJIPgNiSto=.35d8d0f4-4f30-4685-b0be-befa4519f1a0@github.com>
 <O0lDfWUx8rONkIjVmiwuQ9cwIhUIGrfaeqGvMjoAE28=.a82b4c15-1164-49ea-8407-aa05ce8f947c@github.com>
 <dHjqEDrda2FmSwEm57CAEk3jOkkBlLK2bO8G_Gw1AXk=.30e38d67-19aa-4b37-bc88-634987c1a158@github.com>
Message-ID: <bR4ZRsFMwvRFdgU191kqazN99CX85B2eo18UNnFBwkM=.b9fec102-83da-49bb-8f60-877393c805a0@github.com>

On Fri, 2 Jun 2023 22:23:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Probably not. This is only intended to cover the constrained case of this test. Something like the macro `WITH_PLATFORM_STRING` in `libjava/io_util.h` would be needed for the general case, but I thought that that might be overdoing it for here. I could of course be mistaken.
>
> OK, if the usage is limited and covers the required test cases, that sounds reasonable.

Only file system roots are passed as the paths handed to the `getSpace0()` method so hopefully it should be all right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14276#discussion_r1214903127

From liach at openjdk.org  Fri Jun  2 22:39:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 22:39:05 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
Message-ID: <qwHdF_UNcq9FreWLNtQfzZPan-VhpkKp_bb7dtDWBLo=.31d6f294-9b67-4a72-83fb-d2d52624f4c1@github.com>

On Fri, 2 Jun 2023 16:29:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I wonder if it is possible to transition from an lazy (indirect) VH to a direct VH once initialized i.e., `checkAccessModeThenIsDirect` returns the value of `initialized`. Thereby we reduce the potential footprint cost of inflating further MHs and take the more efficient route through the guard method on subsequent invocations.

Currently, the VH passed to linkToStatic-linked implementation methods must be of the correct implementation type. As a result, we have to at least add an `asDirect` call when we pass the VH instance, like the invocation for indirect VH's MHs. Would that be an acceptable refactor, or is that too costly as after constant folding, the two VHs already have similar performance?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574393507

From mchung at openjdk.org  Fri Jun  2 22:53:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 2 Jun 2023 22:53:22 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
Message-ID: <JYue3cbBHByxmsTOdSDuw_87CwC8EqknAuCy02p5ryM=.6e8db45c-9d4d-4f1b-9a09-7655eaee3306@github.com>

On Fri, 2 Jun 2023 02:12:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> 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 11 additional commits since the last revision:
> 
>  - Compute base and offset right after linking, simplify code
>  - Merge branch 'master' into lazy-static-varhandle
>  - Fix exact swap
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/01dce019...27e18b7c

what performance results do you see with this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574406514

From amenkov at openjdk.org  Fri Jun  2 23:00:08 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 23:00:08 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <zPkh-6t3tcheVcJkrDjmV6NQOZsBe7YFV-7DNr46oxg=.be056d77-c2bd-4679-a604-fc6ad33a40b7@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1458569741

From liach at openjdk.org  Fri Jun  2 23:10:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 23:10:06 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <JYue3cbBHByxmsTOdSDuw_87CwC8EqknAuCy02p5ryM=.6e8db45c-9d4d-4f1b-9a09-7655eaee3306@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <JYue3cbBHByxmsTOdSDuw_87CwC8EqknAuCy02p5ryM=.6e8db45c-9d4d-4f1b-9a09-7655eaee3306@github.com>
Message-ID: <Uqx9NWNzcABU16S74GZp0hK8P_6kE-6yPordrFX_mSo=.ca19a093-3981-4f27-8710-fc5331dd94bd@github.com>

On Fri, 2 Jun 2023 22:50:21 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> what performance results do you see with this change?

The indirect VH invocation already has a performance similar to the direct invocation in JMH. Do you mean that I should add `asDirect` to the direct paths in VH and check the benchmark results?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574420828

From liach at openjdk.org  Fri Jun  2 23:50:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 2 Jun 2023 23:50:09 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <L1pOpoNLF2SYdJ_4Peeb3S7-PTM87KEvvqqK6glMxm8=.6520a1ad-de3a-41a8-a8a3-61ccd0e785cc@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>
 <jcjVgz58Koqd3e1TkzaQwsLZXSqBjyC-zYBw_MDwyJY=.982ddf89-5a08-4415-9bf4-97005716ff08@github.com>
 <UgVstUU2bWyzfPS5dc-4FWZohu_UF0jEhF2-E28QDKc=.86f7d7f3-44da-47be-96f3-f755912f47ff@github.com>
 <L1pOpoNLF2SYdJ_4Peeb3S7-PTM87KEvvqqK6glMxm8=.6520a1ad-de3a-41a8-a8a3-61ccd0e785cc@github.com>
Message-ID: <ldTCKTmicoFOrFpTbvUxlXi_cA_GOTSjpJu8sUk4v84=.1361b9fb-ffb9-49a8-8776-475784e44dd2@github.com>

On Fri, 2 Jun 2023 18:41:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> As mentioned in https://bugs.openjdk.org/browse/JDK-8308916 the expression should be `PreviewFeatures.isEnabled() && isSynthetic() &&  isTopLevelClass()` as `PreviewFeatures.isEnabled()` is a private static final test that will effectively make the full expression constant `false` when not in preview mode.
>
> Checking package access should also have near-zero cost.

Will this accidentally return `true` for classes from other JVM programming languages?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1214969195

From liach at openjdk.org  Sat Jun  3 00:02:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 Jun 2023 00:02:25 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v6]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <id7yJae8NNylcY1kIYbzmJG3Mm2kA4yPLH_BULvh_3Y=.47a922a0-58c0-48ef-baf2-752e3164db1f@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op

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

 - Fix withBehavior and test
 - Merge branch 'master' into lazy-static-varhandle
 - Compute base and offset right after linking, simplify code
 - Merge branch 'master' into lazy-static-varhandle
 - Fix exact swap
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Remove export for removed package
 - Merge branch 'master' into lazy-static-varhandle
 - Test the creation performance of handles, lazy one indeed better
 - Merge branch 'master' into lazy-static-varhandle
 - copyright year
 - ... and 3 more: https://git.openjdk.org/jdk/compare/dd539201...e21733c1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/27e18b7c..e21733c1

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

  Stats: 7044 lines in 133 files changed: 5823 ins; 774 del; 447 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

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

From mchung at openjdk.org  Sat Jun  3 00:05:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 3 Jun 2023 00:05:06 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <XysH8cpSh7AcI_1M3C4TXGQ3sEGX7R4IZU-z58bf0RU=.47171f29-0768-417b-ba74-053a52938e57@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <XysH8cpSh7AcI_1M3C4TXGQ3sEGX7R4IZU-z58bf0RU=.47171f29-0768-417b-ba74-053a52938e57@github.com>
Message-ID: <W6Sw28GBloJHh9-I01cg1mw9YX_x9EvUVHrd4-D6WLE=.44c3048c-833c-4b82-873c-6c95cb4bcaf4@github.com>

On Fri, 2 Jun 2023 02:37:13 GMT, Chen Liang <liach at openjdk.org> wrote:

> I've also updated the benchmark for the latest patch. Unfortunately the regular invocations and lazy var handle initial call performance saw a decrease.

Maybe I misunderstood what you meant about "a decrease in performance".

> The indirect VH invocation already has a performance similar to the direct invocation in JMH. Do you mean that I should add asDirect to the direct paths in VH and check the benchmark results?

I guess there would be no difference then.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574454947

From liach at openjdk.org  Sat Jun  3 00:16:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 Jun 2023 00:16:23 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v7]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op

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

  Remove lazy init of MH, for all invocation of the Lazy VH needs this MH

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/e21733c1..0d44a0d3

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

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

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

From darcy at openjdk.org  Sat Jun  3 00:25:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 00:25:30 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <ldTCKTmicoFOrFpTbvUxlXi_cA_GOTSjpJu8sUk4v84=.1361b9fb-ffb9-49a8-8776-475784e44dd2@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <cYL_LI9sz-PDfFlLbPk2NvfDHaRF8a0ABCaKtg4lE0w=.a2e622ad-3b9f-429e-ae53-3fb48cb0f225@github.com>
 <jcjVgz58Koqd3e1TkzaQwsLZXSqBjyC-zYBw_MDwyJY=.982ddf89-5a08-4415-9bf4-97005716ff08@github.com>
 <UgVstUU2bWyzfPS5dc-4FWZohu_UF0jEhF2-E28QDKc=.86f7d7f3-44da-47be-96f3-f755912f47ff@github.com>
 <L1pOpoNLF2SYdJ_4Peeb3S7-PTM87KEvvqqK6glMxm8=.6520a1ad-de3a-41a8-a8a3-61ccd0e785cc@github.com>
 <ldTCKTmicoFOrFpTbvUxlXi_cA_GOTSjpJu8sUk4v84=.1361b9fb-ffb9-49a8-8776-475784e44dd2@github.com>
Message-ID: <YltpyKtjLTDmzqzWCIbfDBwJZM_Q8_Fnu44js6mJbfI=.057c6ac5-a0c8-4ca0-aa5e-2214ec20cf64@github.com>

On Fri, 2 Jun 2023 23:46:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Will this accidentally return `true` for classes from other JVM programming languages?

That is a potential concern. Future iteration of this work will likely use a different idiom to determine is-unnamed that would be more robust against false positives from class files generated for non-Java languages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1215028194

From liach at openjdk.org  Sat Jun  3 01:02:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 Jun 2023 01:02:08 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v7]
In-Reply-To: <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>
Message-ID: <clbDuNjVEYEZ80b9Q2MLKR5tBEqtm68JexBtvp0uzCE=.b4aa8a49-61c1-45ad-bdc4-d0b98cdadc1e@github.com>

On Sat, 3 Jun 2023 00:16:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove lazy init of MH, for all invocation of the Lazy VH needs this MH

Yeah, I was referring the performance drop from 0.5ns/op to 12ns/op for botg direct and indirect; don't know what caused the problems of general slowdown on my end.

Also, is there anything I can do to fix the windows build failures?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1574509072

From lmesnik at openjdk.org  Sat Jun  3 01:11:03 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 3 Jun 2023 01:11:03 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <qWVQNo9OnOEfp2Ugqsp8RKYaIuZXBo6yfeUhHqNcqa8=.1c081866-795e-4ed1-b449-5972e7f365c7@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1458712928

From darcy at openjdk.org  Sat Jun  3 01:56:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 01:56:18 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <EL34kCYqNb-9aFTsl57w1WI5GyCSIRjzk3Wu6dkZ0D8=.bbd33dfe-a52f-4a5a-b73e-555371dbc94d@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

src/java.base/share/classes/java/lang/Class.java line 1884:

> 1882:                     reflective=true)
> 1883:     public boolean isUnnamedClass() {
> 1884:         return PreviewFeatures.isEnabled() && isSynthetic() && isTopLevelClass();

Please add a check for final-ness as @mlchung suggested in the other PR of the reflection changes stand-alone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1215095660

From duke at openjdk.org  Sat Jun  3 02:32:12 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 3 Jun 2023 02:32:12 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v7]
In-Reply-To: <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>
Message-ID: <AT3zpBZCybgUc7JzaL4IOHJnVDYMdwTY5qAqO30sBW8=.309bbb2e-8159-4d01-99ad-84bb8cd77b5f@github.com>

On Sat, 3 Jun 2023 00:16:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  12.668 ? 0.069  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  12.683 ? 0.069  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove lazy init of MH, for all invocation of the Lazy VH needs this MH

src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 106:

> 104:         UNSAFE.ensureClassInitialized(refc);
> 105:         this.initialized = true;
> 106:     }

This?should probably?have a?fast?path when?`this.initialized` is?`true`, so?that it?can be?better constant?folded by?the?**JIT**:
Suggestion:

    private void ensureInitialized() {
        if (this.initialized) {
            return;
        }
        UNSAFE.ensureClassInitialized(refc);
        this.initialized = true;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1215132431

From liach at openjdk.org  Sat Jun  3 03:50:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 Jun 2023 03:50:13 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v7]
In-Reply-To: <AT3zpBZCybgUc7JzaL4IOHJnVDYMdwTY5qAqO30sBW8=.309bbb2e-8159-4d01-99ad-84bb8cd77b5f@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>
 <AT3zpBZCybgUc7JzaL4IOHJnVDYMdwTY5qAqO30sBW8=.309bbb2e-8159-4d01-99ad-84bb8cd77b5f@github.com>
Message-ID: <WPpuNDZmH1It_dQf8O_FRd3J9ivBODA_C4jjIiz97rc=.43e64371-9db6-4635-9e19-5895b1ac288a@github.com>

On Sat, 3 Jun 2023 02:25:59 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove lazy init of MH, for all invocation of the Lazy VH needs this MH
>
> src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 106:
> 
>> 104:         UNSAFE.ensureClassInitialized(refc);
>> 105:         this.initialized = true;
>> 106:     }
> 
> This?should probably?have a?fast?path when?`this.initialized` is?`true`, so?that it?can be?better constant?folded by?the?**JIT**:
> Suggestion:
> 
>     private void ensureInitialized() {
>         if (this.initialized) {
>             return;
>         }
>         UNSAFE.ensureClassInitialized(refc);
>         this.initialized = true;
>     }

I think I should probably update the MH lambda form as well, to skip the ensure call entirely if JVM has not constant-fold the inefficient form yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1215184529

From dfuchs at openjdk.org  Sat Jun  3 10:21:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Sat, 3 Jun 2023 10:21:08 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v4]
In-Reply-To: <Z5KdxF-FS6CtSQUg1Jg4iFyxQjLInqQhvXMre-xdbC0=.bd7107e2-c9bf-4660-9009-1dfaa18febbb@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <Z5KdxF-FS6CtSQUg1Jg4iFyxQjLInqQhvXMre-xdbC0=.bd7107e2-c9bf-4660-9009-1dfaa18febbb@github.com>
Message-ID: <FrBc-A3WfR9XeiJwNaZVbFmdeBEvi_UcDe9pC3vZm3M=.f57f6b38-bd66-4947-91b1-d2ead363fedb@github.com>

On Thu, 1 Jun 2023 13:43:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Sync up from loom repo
>  - Merge
>  - Sync with loom repo, re-work ScopedValue class description
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a46b5acc...cc902ce6

I reviewed the API documentation of `ScopedValue` (mostly the class level API documentation, but I had a look at the methods API too) and it looks good. It reads well, and when I had question they were usually answered in the next paragraph that followed what I was reading.

I didn't look at Structured Concurrency.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13932#pullrequestreview-1459172232

From dnsimon at openjdk.org  Sat Jun  3 11:40:32 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 3 Jun 2023 11:40:32 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into libgraal
Message-ID: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>

This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.

## Times

The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.


public class Nop {
    public static void main(String[] args) {}
}


(1) Baseline (no options):

> for i in (seq 10); java Nop; end
        0.05 real         0.04 user         0.01 sys
        0.04 real         0.03 user         0.01 sys
        0.04 real         0.03 user         0.01 sys
        0.04 real         0.03 user         0.01 sys
        0.03 real         0.03 user         0.00 sys
        0.04 real         0.03 user         0.01 sys
        0.04 real         0.03 user         0.00 sys
        0.03 real         0.03 user         0.00 sys
        0.04 real         0.03 user         0.01 sys
        0.03 real         0.03 user         0.00 sys


(2) Eagerly initialize libgraal (with PR):

> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
        0.06 real         0.04 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys
        0.05 real         0.03 user         0.01 sys


(3) Eagerly initialize libgraal (without PR):

> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
        0.11 real         0.08 user         0.02 sys
        0.08 real         0.06 user         0.01 sys
        0.08 real         0.07 user         0.01 sys
        0.10 real         0.07 user         0.01 sys
        0.08 real         0.06 user         0.01 sys
        0.10 real         0.07 user         0.01 sys
        0.08 real         0.07 user         0.01 sys
        0.08 real         0.07 user         0.01 sys
        0.08 real         0.06 user         0.01 sys
        0.08 real         0.06 user         0.01 sys

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

Commit messages:
 - more efficient copying of system properties into libjvmci

Changes: https://git.openjdk.org/jdk/pull/14291/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309390
  Stats: 242 lines in 8 files changed: 172 ins; 30 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/14291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14291/head:pull/14291

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

From dnsimon at openjdk.org  Sat Jun  3 11:40:32 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 3 Jun 2023 11:40:32 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <izHmY2GJAbYKMlMCqx_oXl2VB9BZ2rdsB5NWB0PjSJU=.1ad07c44-6e77-4234-8a47-d7b63088a01b@github.com>

On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real  ...

src/java.base/share/classes/jdk/internal/util/SystemProps.java line 62:

> 60:      * are initialized by VersionProps.java-template.
> 61:      *
> 62:      * @return a Properties instance initialized with all of the properties

I took the liberty of correcting this javadoc to reflect the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14291#discussion_r1215453699

From alanb at openjdk.org  Sat Jun  3 14:11:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Jun 2023 14:11:05 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <zpcRx0syiflc3q7qlJ8TOXzJN8zbHmMZMNx858Y2IjE=.d0c5c84c-b497-460d-aca3-e1c7ce98162e@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

test/lib/jdk/test/lib/process/ProcessTools.java line 899:

> 897:             // when main is executed in virtual thread
> 898:             MainThreadGroup tg = new MainThreadGroup();
> 899:             Thread vthread = createVirtualThread(() -> {

You can replace this with `Thread.ofVirtual().unstarted(() -> {` and remove the helper method. I think that helper method dates from the jtreg wrapper solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14292#discussion_r1215549528

From cjplummer at openjdk.org  Sat Jun  3 18:24:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 18:24:04 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <zpcRx0syiflc3q7qlJ8TOXzJN8zbHmMZMNx858Y2IjE=.d0c5c84c-b497-460d-aca3-e1c7ce98162e@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <zpcRx0syiflc3q7qlJ8TOXzJN8zbHmMZMNx858Y2IjE=.d0c5c84c-b497-460d-aca3-e1c7ce98162e@github.com>
Message-ID: <1BSXXnlH2oe9TenR2t-oiwJAqWlrEjyhSZk_fht2SDE=.d27a4cd5-1b74-4974-8f51-4f73816fcb98@github.com>

On Sat, 3 Jun 2023 14:07:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 899:
> 
>> 897:             // when main is executed in virtual thread
>> 898:             MainThreadGroup tg = new MainThreadGroup();
>> 899:             Thread vthread = createVirtualThread(() -> {
> 
> You can replace this with `Thread.ofVirtual().unstarted(() -> {` and remove the helper method. I think that helper method dates from the jtreg wrapper solution. Better still, maybe you could use `Thread.ofVirtual().name("main").start(() -> {`.

Yes, I already brought this up with Leonid. I was going to file a separate bug for it, but I can fix it with this CR if you'd like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14292#discussion_r1215705793

From cjplummer at openjdk.org  Sat Jun  3 21:18:23 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 21:18:23 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v2]
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <Ew_43CoITkOIENp21RASOJ1eglugBKIc6oCc8c_Bvkw=.3396be5c-7fe5-4a61-bcb5-b56508139602@github.com>

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

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

 - Merge branch 'master' into 8309334_processtools
   merge
 - when using virtual threads, properly name the main threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14292/files
  - new: https://git.openjdk.org/jdk/pull/14292/files/e53abaf4..de5ca147

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

  Stats: 4052 lines in 65 files changed: 3213 ins; 625 del; 214 mod
  Patch: https://git.openjdk.org/jdk/pull/14292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14292/head:pull/14292

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

From cjplummer at openjdk.org  Sat Jun  3 21:34:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 21:34:16 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - No longer need reflection to call Thread.ofVirtual().unstarted()
 - Remove from problem list tests that are fixed by this PR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14292/files
  - new: https://git.openjdk.org/jdk/pull/14292/files/de5ca147..9bcc200b

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

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

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

From sspitsyn at openjdk.org  Sat Jun  3 23:11:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 3 Jun 2023 23:11:07 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
Message-ID: <B4EO1Mrr9FLP-3JsAdR3QsGd_WkaE0s0YWo8EGEtXMk=.ec2ea60f-6acd-425d-8cb0-886c451946ba@github.com>

On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No longer need reflection to call Thread.ofVirtual().unstarted()
>  - Remove from problem list tests that are fixed by this PR.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1460389726

From darcy at openjdk.org  Sat Jun  3 23:18:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 23:18:17 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <xU8SseGoaVwCC4YQqfbcwwnP6oNS9Q5QKd8xjggg0fU=.a056412f-7100-4167-bcbf-5be09337d030@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1379:

> 1377:          @Override @DefinedBy(Api.LANGUAGE_MODEL)
> 1378:          public Name getSimpleName() {
> 1379:              // return isUnnamed() ? name.subName(0, 0) /* empty name */ : name;

This line could be deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1215925243

From darcy at openjdk.org  Sat Jun  3 23:24:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 23:24:19 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <cDe8Kz-rNxvDiulsEk0HkuXfGFkb6ZnIUflU059nRes=.e8784f29-9eb2-48cd-ba8c-b541a53b42bf@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 140:

> 138:         }
> 139: 
> 140:         if (unnamedClass.getSimpleName().isEmpty()) {

Presumably the sense of the predicates testing names needs to now be reserved due to subsequent updates to the javax.lang.model support.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1215928629

From darcy at openjdk.org  Sat Jun  3 23:33:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 3 Jun 2023 23:33:19 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
Message-ID: <lkZ4DQ50wb5ccDRl2SSpRPPdAAg8VK5UdVHywUXS4WA=.7a890a19-d87d-42cf-aaff-337c1727371b@github.com>

On Fri, 2 Jun 2023 22:10:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName

Core reflection and javax.lang.model APIs look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1460430032

From alanb at openjdk.org  Sun Jun  4 07:18:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Jun 2023 07:18:08 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
Message-ID: <5DZfskNZrZY5sENy22fgCrs6CAsoNo9GgnsM3gYVBdU=.dbbf65ec-dd7e-4afe-b80d-49151b23511e@github.com>

On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No longer need reflection to call Thread.ofVirtual().unstarted()
>  - Remove from problem list tests that are fixed by this PR.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1460999128

From liach at openjdk.org  Sun Jun  4 13:23:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 Jun 2023 13:23:46 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v8]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <jQcnbhcSZbuXy12y0JNaCembJ-G4qGXa3ZhhhI_41IM=.aefaaa31-b3a4-4653-9a48-e245cf2b86df@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op

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

  Improve subsequent VH call performance, thanks exeboss

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/0d44a0d3..dc3e73e9

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

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

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

From liach at openjdk.org  Sun Jun  4 13:23:46 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 Jun 2023 13:23:46 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v7]
In-Reply-To: <WPpuNDZmH1It_dQf8O_FRd3J9ivBODA_C4jjIiz97rc=.43e64371-9db6-4635-9e19-5895b1ac288a@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jeawxd4xGuC4n1iZkDHF1bRYFV8bhDawgc-VNm39Do8=.f9424576-dcb8-42e9-870c-c079ad915b26@github.com>
 <AT3zpBZCybgUc7JzaL4IOHJnVDYMdwTY5qAqO30sBW8=.309bbb2e-8159-4d01-99ad-84bb8cd77b5f@github.com>
 <WPpuNDZmH1It_dQf8O_FRd3J9ivBODA_C4jjIiz97rc=.43e64371-9db6-4635-9e19-5895b1ac288a@github.com>
Message-ID: <FXkNTkv40jQXfOA4HDMB2l9QptSXgKp_z-2_vZEu_mQ=.3c60609d-4d4a-4942-8122-c20c2c4ffa30@github.com>

On Sat, 3 Jun 2023 03:47:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 106:
>> 
>>> 104:         UNSAFE.ensureClassInitialized(refc);
>>> 105:         this.initialized = true;
>>> 106:     }
>> 
>> This?should probably?have a?fast?path when?`this.initialized` is?`true`, so?that it?can be?better constant?folded by?the?**JIT**:
>> Suggestion:
>> 
>>     private void ensureInitialized() {
>>         if (this.initialized) {
>>             return;
>>         }
>>         UNSAFE.ensureClassInitialized(refc);
>>         this.initialized = true;
>>     }
>
> I think I should probably update the MH lambda form as well, to skip the ensure call entirely if JVM has not constant-fold the inefficient form yet.

Indeed, updating lambda form and cached mh works: the average invocation performance becomes ~0.8ns/op, equal to the direct version, compared to the original ~1ms/op. See the updated benchmark results in the main PR body.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1216694641

From duke at openjdk.org  Sun Jun  4 16:16:10 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 4 Jun 2023 16:16:10 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v8]
In-Reply-To: <jQcnbhcSZbuXy12y0JNaCembJ-G4qGXa3ZhhhI_41IM=.aefaaa31-b3a4-4653-9a48-e245cf2b86df@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jQcnbhcSZbuXy12y0JNaCembJ-G4qGXa3ZhhhI_41IM=.aefaaa31-b3a4-4653-9a48-e245cf2b86df@github.com>
Message-ID: <y3fqUGz0R8468GVNRm0rUAwXjnk1RhCx21y5ugZRhoo=.64ecf040-92ba-4496-be37-5d618536cc39@github.com>

On Sun, 4 Jun 2023 13:23:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt  Score   Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10    50.980 ?   9.454  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10    24.350 ?   6.701  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10    65.140 ?   7.552  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   118.360 ?  20.320  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10    49.500 ?   4.277  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10    26.690 ?   5.157  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10    87.930 ?  12.643  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  1057.120 ? 189.810  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve subsequent VH call performance, thanks exeboss

src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 125:

> 123:                 cache[i] = callTarget;
> 124:             }
> 125:         }

Unlike?calling `Unsafe::ensureClassInitialized(?)` (which?performs its?own?synchronisation) or?writing?`true` to?`this.initialized` (which?is a?benign?race), updating?the?lambda?forms this?way is?probably not?quite?correct to?do?under?a?race and?probably?needs some?synchronisation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1216862767

From cjplummer at openjdk.org  Sun Jun  4 18:21:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 4 Jun 2023 18:21:12 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
Message-ID: <eXfAbu8dKd2qW9i1T_z9ycm1K6Os6f_LECbBON_kOx0=.be5c426c-6753-4501-8de0-da271cfcb39a@github.com>

On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No longer need reflection to call Thread.ofVirtual().unstarted()
>  - Remove from problem list tests that are fixed by this PR.

Thanks for the reviews Leonid, Alan, Serguei and Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/14292#issuecomment-1575663199

From cjplummer at openjdk.org  Sun Jun  4 18:21:14 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 4 Jun 2023 18:21:14 GMT
Subject: Integrated: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <L0cpvE8qdv9994S5EQYqJwtxaAqSbMuM0j6lc-RNpKA=.f64235d7-d4fd-4533-96d7-4cf0a12aae39@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

This pull request has now been integrated.

Changeset: ecb17532
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecb17532dc8f3e271ad2d6550127a2253569cf9b
Stats:     24 lines in 3 files changed: 5 ins; 16 del; 3 mod

8309334: ProcessTools.main() does not properly set thread names when using the virtual thread wrapper

Reviewed-by: amenkov, lmesnik, sspitsyn, alanb

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

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

From liach at openjdk.org  Sun Jun  4 21:19:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 Jun 2023 21:19:06 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v8]
In-Reply-To: <y3fqUGz0R8468GVNRm0rUAwXjnk1RhCx21y5ugZRhoo=.64ecf040-92ba-4496-be37-5d618536cc39@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <jQcnbhcSZbuXy12y0JNaCembJ-G4qGXa3ZhhhI_41IM=.aefaaa31-b3a4-4653-9a48-e245cf2b86df@github.com>
 <y3fqUGz0R8468GVNRm0rUAwXjnk1RhCx21y5ugZRhoo=.64ecf040-92ba-4496-be37-5d618536cc39@github.com>
Message-ID: <3qfyy7p3A-q8vug3coD6uM7q3bzYzznOWW6lgiPRTlk=.084ed5ee-5407-435a-82fb-6b81fde72f29@github.com>

On Sun, 4 Jun 2023 16:12:46 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve subsequent VH call performance, thanks exeboss
>
> src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 125:
> 
>> 123:                 cache[i] = callTarget;
>> 124:             }
>> 125:         }
> 
> Unlike?calling `Unsafe::ensureClassInitialized(?)` (which?performs its?own?synchronisation) or?writing?`true` to?`this.initialized` (which?is a?benign?race), updating?the?lambda?forms this?way is?probably not?quite?correct to?do?under?a?race and?probably?needs some?synchronisation.

The form update is a benign race. The array update might need some fences, but I'm not sure, as the read MH should be complete when the updated value is already observed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1217150854

From liach at openjdk.org  Sun Jun  4 23:52:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 Jun 2023 23:52:37 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v5]
In-Reply-To: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
Message-ID: <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>

> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
> 
> 
> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op

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:

 - Forgot to upload latest micro
 - general optimizations to MTD, no longer change backing storage

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

Changes: https://git.openjdk.org/jdk/pull/13186/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=04
  Stats: 305 lines in 7 files changed: 201 ins; 42 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/13186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13186/head:pull/13186

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

From liach at openjdk.org  Sun Jun  4 23:52:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 Jun 2023 23:52:37 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v4]
In-Reply-To: <AdHwQZAeklxWofiQtkzO43Vd4KxlrdWqZ2N-ZuqR79g=.b11da573-ba20-4fc4-9b41-1c0b7b6a4214@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
 <AdHwQZAeklxWofiQtkzO43Vd4KxlrdWqZ2N-ZuqR79g=.b11da573-ba20-4fc4-9b41-1c0b7b6a4214@github.com>
Message-ID: <AqCEai8V_j2UKhTcD_kkCFa-m_I6ugrlvf6vMwr1qXI=.96706f33-c145-4e99-8b8b-e08c42af0744@github.com>

On Fri, 26 May 2023 20:41:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> The microbenchmark shows the performance of using the `MethodTypeDesc` factory methods.  With [#13671](https://github.com/openjdk/jdk/pull/13671), `MethodTypeDesc` is cached and I wonder if this is no longer the bottleneck of ClassFile API performance.   
> 
> [JDK-8304932](https://bugs.openjdk.org/browse/JDK-8304932) is a bug that can simply be fixed by 
> 
> diff --git a/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java b/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
> index 738c4d68a43..ed23887c9ef 100644
> --- a/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
> +++ b/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
> @@ -95,7 +95,7 @@ public sealed interface MethodTypeDesc
>       * {@link ClassDesc} for {@code void}
>       */
>      static MethodTypeDesc of(ClassDesc returnDesc, ClassDesc... paramDescs) {
> -        return new MethodTypeDescImpl(returnDesc, paramDescs);
> +        return new MethodTypeDescImpl(returnDesc, paramDescs.clone());
>      }
>  
>      /**
> diff --git a/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java b/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
> index 4341c3fb56f..8586bfb5926 100644
> --- a/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
> +++ b/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
> @@ -41,7 +41,7 @@ import static java.util.Objects.requireNonNull;
>   */
>  final class MethodTypeDescImpl implements MethodTypeDesc {
>      private final ClassDesc returnType;
> -    private final ClassDesc[] argTypes;
> +    private final ClassDesc[] argTypes;     // trusted array
>  
>      /**
>       * Constructs a {@linkplain MethodTypeDesc} with the specified return type
> @@ -102,14 +102,14 @@ final class MethodTypeDescImpl implements MethodTypeDesc {
>  
>      @Override
>      public MethodTypeDesc changeReturnType(ClassDesc returnType) {
> -        return MethodTypeDesc.of(returnType, argTypes);
> +        return new MethodTypeDescImpl(returnType, argTypes);
>      }
>  
>      @Override
>      public MethodTypeDesc changeParameterType(int index, ClassDesc paramType) {
>          ClassDesc[] newArgs = argTypes.clone();
>          newArgs[index] = paramType;
> -        return MethodTypeDesc.of(returnType, newArgs);
> +        return new MethodTypeDescImpl(returnType, newArgs);
>      }
>  
>      @Override
> @@ -120,7 +120,7 @@ final class MethodTypeDescImpl implements MethodTypeDesc {
>          Cl...

@mlchung I have updated this patch to no longer change the array to a list. Could you take a look? I wish this to be integrated into JDK 21 as it does bring a lot of performance benefits.

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

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1575808993

From darcy at openjdk.org  Mon Jun  5 01:18:26 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 01:18:26 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion: System
 property java.class.version | Java class format version number
Message-ID: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>

Document existing behavior.

Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415

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

Commit messages:
 - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number

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

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

From alanb at openjdk.org  Mon Jun  5 06:08:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 06:08:05 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number
In-Reply-To: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
Message-ID: <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>

On Mon, 5 Jun 2023 01:11:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Document existing behavior.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415

src/java.base/share/classes/java/lang/System.java line 758:

> 756:      *     <td>Greatest Java class file format version recognized by the runtime as {@code "MAJOR.MINOR"}
> 757:      *     where {@link java.lang.reflect.ClassFileFormatVersion#major() MAJOR} and {@code MINOR}
> 758:      *     are both formatted as decimal integers</td></tr>

I'm not sure about using the adjective "Greatest" here, only because "Greatest ... recognized" reads a bit like recognition of greatness when it really wants to convey that it's the highest version recognized.

Does the wording need to take account of running with preview features enabled? 

The table uses "Java runtime" rather than "runtime" in the description of some of the other properties.

In passing, should the descriptions of RELEASE_xxx in ClassFileFormatVersion say "The highest version recognized" rather than the "The version recognized"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1217548926

From alanb at openjdk.org  Mon Jun  5 06:19:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 06:19:27 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
Message-ID: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>

Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:

1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14303/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309408
  Stats: 75 lines in 10 files changed: 27 ins; 32 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14303/head:pull/14303

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

From dholmes at openjdk.org  Mon Jun  5 07:31:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Jun 2023 07:31:12 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

Looks good!

Keeping these tests up-to-date is painful, but as you note this is hopefully stabilized now.

There is one potential, pre-existing, test omission noted below.

Thanks.

test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java line 660:

> 658:         expectedMethods.add(Thread.class.getName() + ".sleep");
> 659:         expectedMethods.add(Thread.class.getName() + ".sleepNanos");
> 660:         expectedMethods.add(Thread.class.getName() + ".sleepNanos0");

I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14303#pullrequestreview-1461876843
PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1217641284

From stefank at openjdk.org  Mon Jun  5 08:23:05 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 5 Jun 2023 08:23:05 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <5QMR3WIYHEm2QUPqwMEb5fX_eHEYZv9qrv9BeJeeooI=.c53f6306-26cf-4d32-966a-c6f6795b760c@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

I welcome this change. We were looking at this code on Friday and was thinking that it would have been good to rename sleep0 and JVM_Sleep. :)

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14303#pullrequestreview-1461982066

From apejovic at openjdk.org  Mon Jun  5 09:04:07 2023
From: apejovic at openjdk.org (Aleksandar Pejovic)
Date: Mon, 5 Jun 2023 09:04:07 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <9UqqGOmXLkrwGFFsrX1IdUCOzdHPOb_bh6rZTi5SgQw=.3b73ac88-8410-409a-b057-cb4837a4a48c@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
 <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
 <ReiS8ogZjIZKxuJNynkiF77HghFDsVTOfbd72sPuXLw=.c5d52edc-01ff-43d0-b199-70a3277b8abe@github.com>
 <LZKxXGJafawMRhT7yMB1T4lRNu06OHsDm-CoscL3m3Y=.4878df0e-2247-4d0e-b650-2f1cce45c69f@github.com>
 <9UqqGOmXLkrwGFFsrX1IdUCOzdHPOb_bh6rZTi5SgQw=.3b73ac88-8410-409a-b057-cb4837a4a48c@github.com>
Message-ID: <ViF1JViq-SjHWWPjuTmXii8yzmeAPvXECIWuzJ23-_c=.45b4e4f3-38f2-425e-a0b7-4194ac979f79@github.com>

On Wed, 31 May 2023 13:49:46 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

>>> I guess I'll have to wait for OCA verification.
>> 
>> Yes.
>> 
>>> One failure is due to a lack of reviewers, so would you be able to do a review?
>> 
>> Yes, I'll try to do a review later today or tomorrow.
>> 
>> Thanks!
>
>> Yes, I'll try to do a review later today or tomorrow.
> 
> Awesome, thanks!

> @pejovica what testing have you done in relation to these changes? We run our container tests in tier5 - have you tested that? Thanks.

@dholmes-ora Thanks for the pointer, I'll post back when I run them.

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

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1576407433

From apejovic at openjdk.org  Mon Jun  5 09:04:10 2023
From: apejovic at openjdk.org (Aleksandar Pejovic)
Date: Mon, 5 Jun 2023 09:04:10 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
Message-ID: <1k0o3AhR5gZkMrmtdpGqRg3MM77JTsh9pcFXraWYydE=.7e768396-ab2f-4778-9dcb-3716f28fddcc@github.com>

On Thu, 1 Jun 2023 08:50:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
>> 
>> This PR reduces the dependencies:
>> - NIO is replaced with regular `java.io` for file access.
>> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
>> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupInfo.java line 110:
> 
>> 108:      */
>> 109:     static CgroupInfo fromCgroupsLine(String line) {
>> 110:         String[] tokens = line.split("\t");
> 
> With this change, we now hard-code the expected delimiter and, thus, depend on what the kernel does. Do we have sufficient evidence this hasn't changed/won't change in the future?

As far as I can tell, the delimiter hasn't changed since the file was introduced, and judging by the kernel mailing list (e.g., see [the following](https://lore.kernel.org/all/Yr5JVHhSUCrbT8OH at mtj.duckdns.org/)), I don't think it will change any time soon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1217759178

From apejovic at openjdk.org  Mon Jun  5 09:10:08 2023
From: apejovic at openjdk.org (Aleksandar Pejovic)
Date: Mon, 5 Jun 2023 09:10:08 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
Message-ID: <5_0qa5a7BPRpPsD1q2i5ZFioDEDTXgtMyY006a8uCCg=.63a64099-70ed-4a33-af86-25203f8aefed@github.com>

On Thu, 1 Jun 2023 09:47:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
>> 
>> This PR reduces the dependencies:
>> - NIO is replaced with regular `java.io` for file access.
>> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
>> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 110:
> 
>> 108: 
>> 109:     public static long convertHierachicalLimitLine(String line) {
>> 110:         String[] tokens = line.split(" ");
> 
> Again, assumes single space (` `) delimited entries in `memory.stat`. I'm not sure we should hard-code this.

This delimiter also hasn't changed since the `memory.stat` file was introduced, and since cgroup v1 is in maintenance mode I'd expect it to stay that way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1217765452

From duke at openjdk.org  Mon Jun  5 09:39:10 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 5 Jun 2023 09:39:10 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
Message-ID: <mmnDcX31n-xxwpFb14LwXHdY6mNeeNgw0Vx2dUiP51M=.e50709d0-0aeb-4b13-aea6-5752dbb7b530@github.com>

On Thu, 1 Jun 2023 08:58:23 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun 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:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

Existing JMH Local test results be tested on LOONGARCH64 show no performance fallback.
<pre><code class="shell">
// parent
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    3  35.731 ? 0.805  ns/op
LocaleDefaults.getDefaultDisplay  avgt    3  36.099 ? 1.037  ns/op
LocaleDefaults.getDefaultFormat   avgt    3  36.123 ? 1.718  ns/op

// current
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    3  35.649 ? 0.264  ns/op
LocaleDefaults.getDefaultDisplay  avgt    3  36.141 ? 1.283  ns/op
LocaleDefaults.getDefaultFormat   avgt    3  36.092 ? 1.371  ns/op

</code></pre>

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1576462477

From sgehwolf at openjdk.org  Mon Jun  5 09:47:06 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 5 Jun 2023 09:47:06 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <1k0o3AhR5gZkMrmtdpGqRg3MM77JTsh9pcFXraWYydE=.7e768396-ab2f-4778-9dcb-3716f28fddcc@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
 <1k0o3AhR5gZkMrmtdpGqRg3MM77JTsh9pcFXraWYydE=.7e768396-ab2f-4778-9dcb-3716f28fddcc@github.com>
Message-ID: <W3X4LmX5D2g5eV-fEoV3eXWljsaA-xMdoK9X7aJFqxk=.be3107a7-a665-485e-9b0b-6a491ca0c89e@github.com>

On Mon, 5 Jun 2023 09:02:06 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupInfo.java line 110:
>> 
>>> 108:      */
>>> 109:     static CgroupInfo fromCgroupsLine(String line) {
>>> 110:         String[] tokens = line.split("\t");
>> 
>> With this change, we now hard-code the expected delimiter and, thus, depend on what the kernel does. Do we have sufficient evidence this hasn't changed/won't change in the future?
>
> As far as I can tell, the delimiter hasn't changed since the file was introduced, and judging by the kernel mailing list (e.g., see [the following](https://lore.kernel.org/all/Yr5JVHhSUCrbT8OH at mtj.duckdns.org/)), I don't think it will change any time soon.

I'm not convinced this is a good change. Going by that mailing list thread, it suggests that people considered changing it. If one of those attempts were successful, it would have broken this code. It makes it rather fragile. The issue, with container detection code going wrong is that you most likely never notice. Translating this to GraalVM means that the native image, would a) detect the wrong version in use or b) fail detection and use host values. In both cases the application will likely misbehave in a container setup with resource limits applied and you won't (easily) know why. So even though it's unlikely to be a problem, there is a chance it could be and it's asking for trouble for no good reason.

Therefore, being conservative about delimiters makes sense here. My choice in this case would be more robust code over relying on external factors. YMMV.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1217815148

From alanb at openjdk.org  Mon Jun  5 10:28:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 10:28:10 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
Message-ID: <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>

On Fri, 2 Jun 2023 04:48:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explain in java.lang.Class how unnamed classes are modeled in core reflection.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update reflective support.

Will this method be tested by the changes in pull/13689?

src/java.base/share/classes/java/lang/Class.java line 29:

> 27: 
> 28: import jdk.internal.javac.PreviewFeature;
> 29: import jdk.internal.misc.PreviewFeatures;

Can you move this so that it's with the other imports of jdk.internal classes?

src/java.base/share/classes/java/lang/Class.java line 194:

> 192:  * <h2><a id=unnamedClasses>Unnamed Classes</a></h2>
> 193:  *
> 194:  * A {@code class} file representing an {@linkplain #isUnnamedClass unnamed class} is generated by

Are you going to reflow this paragraph before you are done, only wondering as there is one line sticking out compared the rest of the paragraph.

src/java.base/share/classes/java/lang/Class.java line 216:

> 214:  * {@linkplain #getSimpleName
> 215:  * simple name} of such an unnamed class is the empty string and the
> 216:  * {@linkplain #getCanonicalName canonical name} is {@code null}.

This sentence is quite long. You might to consider splitting it up, or at minimally put a comma after "empty string" to allow the reader draw breath.

src/java.base/share/classes/java/lang/Class.java line 1881:

> 1879:      * @since 21
> 1880:      */
> 1881:     @PreviewFeature(feature=PreviewFeature.Feature.UNNAMED_CLASSES,

Is there a JLS section to reference?

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

PR Review: https://git.openjdk.org/jdk/pull/14165#pullrequestreview-1462196037
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1217845247
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1217846409
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1217854569
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1217848157

From jlahoda at openjdk.org  Mon Jun  5 10:51:16 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 5 Jun 2023 10:51:16 GMT
Subject: Integrated: 8291966: SwitchBootstrap.typeSwitch could be faster
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <weLZfZgTTfKdVr9VJdd-icCMoLR0UilDTuFkTEsTC6g=.c7cee4b9-77f5-4684-9f17-c63456a858a0@github.com>

On Fri, 5 Aug 2022 16:12:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

This pull request has now been integrated.

Changeset: 9be5769a
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9be5769a68d7cc9dced732649adc4c977b8eac8d
Stats:     197 lines in 2 files changed: 110 ins; 15 del; 72 mod

8291966: SwitchBootstrap.typeSwitch could be faster

Reviewed-by: asotona

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

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

From alanb at openjdk.org  Mon Jun  5 12:45:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 12:45:11 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v7]
In-Reply-To: <wPttW_J88W-KkZeynbBh2dDK9IxwYbkHQhFPK8Ym9TU=.39169dff-b116-416d-8f69-3055054b254e@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
 <8hwJYhcT5DQJpsC0Zzlj_kcWqpw9b8yBcVXMLVJurqA=.593e7ec9-f221-4c09-803a-a2de35bfcdb3@github.com>
 <wPttW_J88W-KkZeynbBh2dDK9IxwYbkHQhFPK8Ym9TU=.39169dff-b116-416d-8f69-3055054b254e@github.com>
Message-ID: <bkxP--Bm8-jTAt2I0v9QjETT7-Bff-FVKyn17HUtoRs=.861403b9-ae58-4954-ac00-e24cf58675cc@github.com>

On Fri, 26 May 2023 15:57:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Would you please review this PR ?
> 
> We are in the last two weeks before JDK 21 rampdown phase 1 and so are rather busy. This PR has not been forgotten. Thanks for your patience.

Yeah, this is docs only so okay to do after the fork for RDP1. I think the current PR is okay but this method, plus FileSystem::getRootDirectories, need a sentence to that something like ?There is no guarantee that the root directory can be accessed?. I don't have an opinion on whether it is this PR or another one.

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1576719785

From jlaskey at openjdk.org  Mon Jun  5 12:47:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 12:47:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v32]
In-Reply-To: <EL34kCYqNb-9aFTsl57w1WI5GyCSIRjzk3Wu6dkZ0D8=.bbd33dfe-a52f-4a5a-b73e-555371dbc94d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <hTESggejmq11w9F6OqK6BGjBGUUumGOqChqyCBFchUQ=.a0208471-ea32-4f81-a1fa-6cc936d50407@github.com>
 <EL34kCYqNb-9aFTsl57w1WI5GyCSIRjzk3Wu6dkZ0D8=.bbd33dfe-a52f-4a5a-b73e-555371dbc94d@github.com>
Message-ID: <pw2yRgYcMnfgehgmT8Tjv3ZD8x56Fx3Qe47R9gBbyF4=.f277b668-1af5-4156-9035-85bf2717b7d2@github.com>

On Sat, 3 Jun 2023 01:53:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName
>
> src/java.base/share/classes/java/lang/Class.java line 1884:
> 
>> 1882:                     reflective=true)
>> 1883:     public boolean isUnnamedClass() {
>> 1884:         return PreviewFeatures.isEnabled() && isSynthetic() && isTopLevelClass();
> 
> Please add a check for final-ness as @mlchung suggested in the other PR of the reflection changes stand-alone.

Changing

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 1379:
> 
>> 1377:          @Override @DefinedBy(Api.LANGUAGE_MODEL)
>> 1378:          public Name getSimpleName() {
>> 1379:              // return isUnnamed() ? name.subName(0, 0) /* empty name */ : name;
> 
> This line could be deleted.

Changing

> test/langtools/tools/javac/processing/model/element/TestUnnamedClass.java line 140:
> 
>> 138:         }
>> 139: 
>> 140:         if (unnamedClass.getSimpleName().isEmpty()) {
> 
> Presumably the sense of the predicates testing names needs to now be reserved due to subsequent updates to the javax.lang.model support.

True, but we should ensure that what we are shipping now does what we claim.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1218020010
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1218020222
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1218022085

From jlaskey at openjdk.org  Mon Jun  5 12:51:11 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 12:51:11 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>
Message-ID: <0rctTE2XA0-LgFZvupeJi89ozvPWxKe7A9mbFodVOV4=.4fabf801-fb61-4a01-a14c-a4cfd812e842@github.com>

On Mon, 5 Jun 2023 10:08:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update reflective support.
>
> src/java.base/share/classes/java/lang/Class.java line 29:
> 
>> 27: 
>> 28: import jdk.internal.javac.PreviewFeature;
>> 29: import jdk.internal.misc.PreviewFeatures;
> 
> Can you move this so that it's with the other imports of jdk.internal classes?

Changing in primary PR - https://github.com/openjdk/jdk/pull/13689

> src/java.base/share/classes/java/lang/Class.java line 194:
> 
>> 192:  * <h2><a id=unnamedClasses>Unnamed Classes</a></h2>
>> 193:  *
>> 194:  * A {@code class} file representing an {@linkplain #isUnnamedClass unnamed class} is generated by
> 
> Are you going to reflow this paragraph before you are done, only wondering as there is one line sticking out compared the rest of the paragraph.

Changing in primary PR - https://github.com/openjdk/jdk/pull/13689

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1218025885
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1218027536

From jlaskey at openjdk.org  Mon Jun  5 12:55:11 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 12:55:11 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>
Message-ID: <ws9yjqOLdwNIeAUaJYtBzk8n09xXeTHB8c4zA0bHJkk=.9e909e94-f310-447a-9671-2761bf542bcd@github.com>

On Mon, 5 Jun 2023 10:11:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update reflective support.
>
> src/java.base/share/classes/java/lang/Class.java line 1881:
> 
>> 1879:      * @since 21
>> 1880:      */
>> 1881:     @PreviewFeature(feature=PreviewFeature.Feature.UNNAMED_CLASSES,
> 
> Is there a JLS section to reference?

Changing in primary PR - https://github.com/openjdk/jdk/pull/13689

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1218031133

From jlaskey at openjdk.org  Mon Jun  5 13:00:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 13:00:08 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
 <XxM57tufUlVky8-Tw_vxPLlzkB7oC-Z0sL7RH_d7VyY=.a8271d31-85ab-4c9a-a42a-9478e294aded@github.com>
Message-ID: <u-M-S5TfPpoXIjPr5lCPWIJyMyAtLmTRVHG4-pUF2GM=.9be9cbc8-d255-43d3-b32e-2d38dc33f3d9@github.com>

On Mon, 5 Jun 2023 10:17:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update reflective support.
>
> src/java.base/share/classes/java/lang/Class.java line 216:
> 
>> 214:  * {@linkplain #getSimpleName
>> 215:  * simple name} of such an unnamed class is the empty string and the
>> 216:  * {@linkplain #getCanonicalName canonical name} is {@code null}.
> 
> This sentence is quite long. You might to consider splitting it up, or at minimally put a comma after "empty string" to allow the reader draw breath.

This was the agreed wording.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1218038932

From jlaskey at openjdk.org  Mon Jun  5 13:40:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 13:40:07 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v33]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <IPaVnv3u_QCrSAxgofGpRMWZKygUOP8SXffRk39YDks=.016315fc-4cd9-4452-9eea-7d2c095fa8c9@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 53 commits:

 - Merge branch 'master' into 8306112
 - Requested clean ups
 - Source code launcher to use getSimpleName() when launching unnamed class
 - Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName
 - Use getQualifiedName() to indicate unnamed class
 - ClassSymbol#getSimpleName() returning empty name breaks some tools
 - Merge branch 'master' into 8306112
 - Update reflection to follow spec
 - Merge branch 'master' into 8306112
 - Integrating JDK-8308913
 - ... and 43 more: https://git.openjdk.org/jdk/compare/6d511f13...94d1eefd

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=32
  Stats: 1690 lines in 41 files changed: 1512 ins; 32 del; 146 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From dl at openjdk.org  Mon Jun  5 13:52:36 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 5 Jun 2023 13:52:36 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted"
Message-ID: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>

Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.

This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

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

Commit messages:
 - Rework versioning
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Reduce contention
 - minor improvements and renamings
 - Merge branch 'openjdk:master' into JDK-8288899
 - Add invokeAnyUninterruptibly
 - ... and 29 more: https://git.openjdk.org/jdk/compare/6edd786b...6a116f50

Changes: https://git.openjdk.org/jdk/pull/14301/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288899
  Stats: 2951 lines in 6 files changed: 1125 ins; 658 del; 1168 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

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

From asotona at openjdk.org  Mon Jun  5 14:31:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 14:31:46 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v4]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <LbUgxZSUkT-Ekx4__NEMMaFw1w_KqVJB0L_DArsJzYk=.61f6c5eb-7999-47f0-a3ef-3397989577b5@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> 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 23 additional commits since the last revision:

 - Merge branch 'master' into JDK-8308899-context
 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - added Classfile context parameter to ClasRemapper::remapClass
 - records and methods implementations moved from Classfile to ClassfileImpl
 - added Classfile::buildTo override
 - implementation of Classfile::withOptions(Option... options)
   ClassfileImpl made immutable
   "options" use across implementation renamed to "context"
 - ... and 13 more: https://git.openjdk.org/jdk/compare/7990f646...7d431af9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/f8915f91..7d431af9

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

  Stats: 6081 lines in 122 files changed: 4664 ins; 863 del; 554 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun  5 14:38:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 14:38:47 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v3]
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <EIzKhYeQ5d0UYqrrDQdx0JuUhSU9RpksOwAcyXgekVs=.29485271-f5aa-4602-a4ec-84d4d46ddee7@github.com>

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> 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 branch 'master' into JDK-8308842-exceptions
 - fixed javadoc
 - 8308842: Consolidate exceptions thrown from Class-File API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14143/files
  - new: https://git.openjdk.org/jdk/pull/14143/files/8bc444df..65a7e70a

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

  Stats: 36795 lines in 720 files changed: 29233 ins; 3454 del; 4108 mod
  Patch: https://git.openjdk.org/jdk/pull/14143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14143/head:pull/14143

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

From asotona at openjdk.org  Mon Jun  5 14:42:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 14:42:32 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

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

  fixed copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/7d431af9..965dcba8

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

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

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

From briangoetz at openjdk.org  Mon Jun  5 15:07:11 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Mon, 5 Jun 2023 15:07:11 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v3]
In-Reply-To: <EIzKhYeQ5d0UYqrrDQdx0JuUhSU9RpksOwAcyXgekVs=.29485271-f5aa-4602-a4ec-84d4d46ddee7@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
 <EIzKhYeQ5d0UYqrrDQdx0JuUhSU9RpksOwAcyXgekVs=.29485271-f5aa-4602-a4ec-84d4d46ddee7@github.com>
Message-ID: <xtYHtq_bEN09bSE83bKQ25gaWzk__5MKdZTmc9nqbj8=.49b78a83-51c9-4a18-9b9e-39d3ad5c5398@github.com>

On Mon, 5 Jun 2023 14:38:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
>> 
>> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
>> 
>> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
>> 
>> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
>> 
>> 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 branch 'master' into JDK-8308842-exceptions
>  - fixed javadoc
>  - 8308842: Consolidate exceptions thrown from Class-File API

Reviewed, only minor comment is the one about constructors in the new exception class.

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java line 42:

> 40:         super();
> 41:     }
> 42: 

Exception classes in the JDK generally have four constructors: (), (Throwable), (String), and (String, Throwable).

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

Marked as reviewed by briangoetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14143#pullrequestreview-1462765241
PR Review Comment: https://git.openjdk.org/jdk/pull/14143#discussion_r1218206593

From alanb at openjdk.org  Mon Jun  5 15:13:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 15:13:06 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
Message-ID: <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>

On Mon, 5 Jun 2023 07:26:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
>> 
>> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
>> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java line 660:
> 
>> 658:         expectedMethods.add(Thread.class.getName() + ".sleep");
>> 659:         expectedMethods.add(Thread.class.getName() + ".sleepNanos");
>> 660:         expectedMethods.add(Thread.class.getName() + ".sleepNanos0");
> 
> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.

> There is one potential, pre-existing, test omission noted below.
> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.

The monitoring/stress/thread tests will fail if they observe an unexpected method name in the stack trace. I don't think it can happen because the tests poll the thread state and for SleepingThread, it will sample the stack trace when the thread state is timed-wait. The beforeSleep/afterSleep methods won't in the stack trace when sleeping. It would be harmless to add them in that they aren't going to cause these tests to fail but might help with any further changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1218215964

From asotona at openjdk.org  Mon Jun  5 16:08:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 16:08:13 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v3]
In-Reply-To: <xtYHtq_bEN09bSE83bKQ25gaWzk__5MKdZTmc9nqbj8=.49b78a83-51c9-4a18-9b9e-39d3ad5c5398@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
 <EIzKhYeQ5d0UYqrrDQdx0JuUhSU9RpksOwAcyXgekVs=.29485271-f5aa-4602-a4ec-84d4d46ddee7@github.com>
 <xtYHtq_bEN09bSE83bKQ25gaWzk__5MKdZTmc9nqbj8=.49b78a83-51c9-4a18-9b9e-39d3ad5c5398@github.com>
Message-ID: <it8t97cycSPTpMIz2KbCQQvIsUkrtfTnAOzhosX4TnQ=.5b2b0d67-6d34-4210-b158-6c20c592f0e1@github.com>

On Mon, 5 Jun 2023 15:03:01 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8308842-exceptions
>>  - fixed javadoc
>>  - 8308842: Consolidate exceptions thrown from Class-File API
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java line 42:
> 
>> 40:         super();
>> 41:     }
>> 42: 
> 
> Exception classes in the JDK generally have four constructors: (), (Throwable), (String), and (String, Throwable).

I'll add missing constructors, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14143#discussion_r1218289371

From jlaskey at openjdk.org  Mon Jun  5 16:11:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 16:11:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v34]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <ZPAfVZ7RRWfoKFFwuxbPe16WP5HK46MUrMUQSkP2ZJ0=.b43e3dc3-21c2-4c4c-818c-00890ef9afc3@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8306112
 - Final clean up
 - Merge branch 'master' into 8306112
 - Requested clean ups
 - Source code launcher to use getSimpleName() when launching unnamed class
 - Update the specification for TypeElement#getQualifiedName and TypeElement#getSimpleName
 - Use getQualifiedName() to indicate unnamed class
 - ClassSymbol#getSimpleName() returning empty name breaks some tools
 - Merge branch 'master' into 8306112
 - Update reflection to follow spec
 - ... and 45 more: https://git.openjdk.org/jdk/compare/5cd8af76...663ca88f

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

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=33
  Stats: 1685 lines in 40 files changed: 1510 ins; 32 del; 143 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From asotona at openjdk.org  Mon Jun  5 16:29:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 16:29:28 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v4]
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <lAIx3tezVNTqunSvIS5iaYbq_UzoO_4oia3wkUyXr68=.7cd88fdc-b96e-4c55-9dc9-eea9e036314b@github.com>

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

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

  added missing ConstantPoolException constructors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14143/files
  - new: https://git.openjdk.org/jdk/pull/14143/files/65a7e70a..36d29858

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

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

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

From briangoetz at openjdk.org  Mon Jun  5 16:38:20 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Mon, 5 Jun 2023 16:38:20 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
Message-ID: <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>

On Mon, 5 Jun 2023 14:42:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed copyright header

Overall this looks pretty clean.  I like how simply it flows through the implementation classes.  There are a number of methods and classes, especially in Classfile, which need some more spec.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 50:

> 48: /**
> 49:  * Main entry points for parsing, transforming, and generating classfiles.
> 50:  */

Now that this is not just a bag of static methods any more, we need to have some spec text about what a Classfile is.  Something like:

Represents a context for parsing, transforming, and generating classfiles.  A `Classfile` has a set of options that condition how parsing and generation is done.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 54:

> 52:         permits ClassfileImpl {
> 53: 
> 54:     static Classfile of() {

Classfile::of needs specification

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 63:

> 61: 
> 62:     Classfile withOptions(Option... options);
> 63: 

Classfile::withOptions needs specification

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:

> 64:     /**
> 65:      * An option that affects the writing of classfiles.
> 66:      */

Options affect parsing as well as writing now

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 82:

> 80:     static ConstantPoolBuilder of() {
> 81:         return new SplitConstantPool();
> 82:     }

The old ctors here were (ClassModel) and (Options), where the ClassModel version had a trail of breadcrumbs back to options.  The new ctors are (ClassModel) and no-args, which is a slight departure.  What use did CPB make of options in the first place, if any?

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

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1462788383
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218222043
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218223437
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218223102
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218223991
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218316864

From asotona at openjdk.org  Mon Jun  5 16:44:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 16:44:23 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v5]
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <Tx-mSRa25o2yb1HckkUfnykooccUW9F9bBabs88IgMI=.6d27f7a0-941b-4983-963c-1d2ecd171809@github.com>

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

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

  javadoc fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14143/files
  - new: https://git.openjdk.org/jdk/pull/14143/files/36d29858..2454c8e2

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

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

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

From jlaskey at openjdk.org  Mon Jun  5 16:55:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 16:55:08 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v35]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <LiCt6Krocrs0tWjbMb1gEx7ReeTu2KuqqZp-flpCEg0=.18cc8168-1789-431c-b0bd-89191a061f20@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

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

  -Xprint unnamed classes to use  e.getSimpleName()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/663ca88f..d0fdf694

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=33-34

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

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

From shade at openjdk.org  Mon Jun  5 17:28:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jun 2023 17:28:08 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

I think we need to delay this until [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in case we would like to revert [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).

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

PR Review: https://git.openjdk.org/jdk/pull/14303#pullrequestreview-1463041304

From asotona at openjdk.org  Mon Jun  5 17:42:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 17:42:07 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
 <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
Message-ID: <WfgarsYk8njBoRYiaNLB9gZxQHK5MGLe2-6SZdeqgDs=.738f4acf-1ee6-466e-a376-e9333d640c98@github.com>

On Mon, 5 Jun 2023 16:30:16 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright header
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolBuilder.java line 82:
> 
>> 80:     static ConstantPoolBuilder of() {
>> 81:         return new SplitConstantPool();
>> 82:     }
> 
> The old ctors here were (ClassModel) and (Options), where the ClassModel version had a trail of breadcrumbs back to options.  The new ctors are (ClassModel) and no-args, which is a slight departure.  What use did CPB make of options in the first place, if any?

CPB was only holder of options and others took the options from CPB.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218391052

From darcy at openjdk.org  Mon Jun  5 18:01:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 18:01:54 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v2]
In-Reply-To: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
Message-ID: <lXxhKomkmG0ZNT1jv6Q7FHelc3XpWKmvNZa2ZwhxARI=.f465d68e-727e-46d5-be19-b4ea62eccec8@github.com>

> Document existing behavior.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415

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

 - Merge branch 'master' into JDK-8295071
 - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14305/files
  - new: https://git.openjdk.org/jdk/pull/14305/files/9d744d5b..5c7e4172

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

  Stats: 1564 lines in 38 files changed: 1084 ins; 184 del; 296 mod
  Patch: https://git.openjdk.org/jdk/pull/14305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14305/head:pull/14305

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

From mchung at openjdk.org  Mon Jun  5 18:05:21 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 5 Jun 2023 18:05:21 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v5]
In-Reply-To: <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>
Message-ID: <7QpluTpgWuXPhJixDBTovoZsOsQAVUUmd8LJ4q9L8Kg=.65b21779-218e-4e16-b69a-3bff366c42a5@github.com>

On Sun, 4 Jun 2023 23:52:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
>> 
>> 
>> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
>> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
>> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
>> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
>> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
>> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
>> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
>> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
>> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
>> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
>> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
>> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
>> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
>> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
>> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
>> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
>> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op
>
> 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:
> 
>  - Forgot to upload latest micro
>  - general optimizations to MTD, no longer change backing storage

Some comments in `MethodTypeDesc` and its implementation.  Will take a look at the test.

I'd like to see the ClassFile implementation changes in a separate PR that needs @asotona to give input and review.    The proposed change in the ClassFile implementation is trivial but I can't really tell what the performance issue is (of course, I know it avoids the array allocation).

For ClassFile performance issues, it would be useful to have the understanding of the major issues that contribute to the performance overhead.   That would help consider the fixes and alternatives.

src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 99:

> 97:      */
> 98:     static MethodTypeDesc of(ClassDesc returnDesc, ClassDesc... paramDescs) {
> 99:         if (paramDescs.length == 0)

`paramDescs` could be null.

src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 205:

> 203:      */
> 204:     default String descriptorString() {
> 205:         var sj = new StringJoiner("", "(", ")" + returnType().descriptorString());

`MethodTypeDescImpl` is the only class implementing `MethodTypeDesc` and implements `descriptorString()`.    This default implementation is not needed.   Should the implementation be moved to `MethodTypeDescImpl::descriptorString`?

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 84:

> 82:             paramTypes = new ClassDesc[paramCount];
> 83:             for (int i = 0; i < paramCount; i++) {
> 84:                 paramTypes[i] = validateParameter(ClassDesc.ofDescriptor(types.get(i + 1)));

It seems useful to have a static factory method to take a trusted copy of parameter types and it will validate the parameters before constructing `MethodTypeDescImpl` instance.   Parameter validation in one single place.    Several methods doing the validation can simply call this factory method and the code would be cleaner.

`insertParameterTypes` can call it as well and overhead of re-validating existing parameter types isn't a big issue.

test/jdk/java/lang/constant/MethodTypeDescTest.java line 64:

> 62:         assertEquals(r, MethodTypeDesc.of(r.returnType(), r.parameterList().stream().toArray(ClassDesc[]::new)));
> 63:         assertEquals(r, MethodTypeDesc.of(r.returnType(), IntStream.range(0, r.parameterCount())
> 64:                 .mapToObj(r::parameterType)

this reformatting may be accidental.  Please keep the original format.   Same applies to other reformatted lines in this file.

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

PR Review: https://git.openjdk.org/jdk/pull/13186#pullrequestreview-1463008651
PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218356523
PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218369052
PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218377366
PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218380489

From bpb at openjdk.org  Mon Jun  5 18:17:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Jun 2023 18:17:37 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v7]
In-Reply-To: <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
Message-ID: <F9xyr06DfR2e5-wXkOBRuHUCXVgyr6FUQ6gn3TsYeCA=.0cc97d27-f216-4480-885a-59c75bec3b11@github.com>

On Mon, 22 May 2023 07:27:00 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SecurityException paragraph

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

> 1819:      * root directories of the available filesystem roots.  It is guaranteed
> 1820:      * that the canonical pathname of any file physically present on the local
> 1821:      * machine will begin with one of the roots returned by this method.

@Nagata-Haruhito Per @AlanBateman 's suggestion, would you please add this sentence

?There is no guarantee that the root directory can be accessed?

or the equivalent here after ?returned by this method? and after the sentence that begins with ?A file system ...? in the specification of `java.nio.file.FileSystem::getRootDirectories` and so update this PR?

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1218417925

From darcy at openjdk.org  Mon Jun  5 18:17:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 18:17:53 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v2]
In-Reply-To: <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
Message-ID: <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>

On Mon, 5 Jun 2023 06:05:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8295071
>>  - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number
>
> src/java.base/share/classes/java/lang/System.java line 758:
> 
>> 756:      *     <td>Greatest Java class file format version recognized by the runtime as {@code "MAJOR.MINOR"}
>> 757:      *     where {@link java.lang.reflect.ClassFileFormatVersion#major() MAJOR} and {@code MINOR}
>> 758:      *     are both formatted as decimal integers</td></tr>
> 
> I'm not sure about using the adjective "Greatest" here, only because "Greatest ... recognized" reads a bit like recognition of greatness when it really wants to convey that it's the highest version recognized.
> 
> Does the wording need to take account of running with preview features enabled? 
> 
> The table uses "Java runtime" rather than "runtime" in the description of some of the other properties.
> 
> In passing, should the descriptions of RELEASE_xxx in ClassFileFormatVersion say "The highest version recognized" rather than the "The version recognized"?

Update PR and CSR to use the wording:

"Latest Java class file format version recognized by the Java runtime as "MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"

While it wouldn't be unreasonable to assume that when running under --enable-preview that the minor version was 65535, it is printed out as 0 with or without preview being enabled.

I didn't want to broach preview-ness as part of this update to either promise or document the current behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1218416628

From asotona at openjdk.org  Mon Jun  5 18:23:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:23:52 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v6]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <erbC-r7QGPLY-J2CQZ3KalgtekkaS90JX2MmDc9yuBM=.19bbe475-3a07-48a8-a518-4832d9e5f2eb@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - added missing javadoc
 - simplified options names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/965dcba8..9c20d929

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

  Stats: 81 lines in 20 files changed: 13 ins; 5 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From asotona at openjdk.org  Mon Jun  5 18:23:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:23:58 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v5]
In-Reply-To: <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <g5yd8Ec5FUYC7ievbwZrU9e3m-xmC6O3m4OqT34hz9g=.5531a22b-b23b-422e-9188-95f07be87e3b@github.com>
 <X3pGQww5dd4ZO1jEq6KmT6Bp4prLBydxKCuEF6V7Mow=.3e9d4c3b-4832-4c27-9150-05036f7f71ff@github.com>
Message-ID: <xCfunkBUsxMwBz2806kCEjo818D8W0JtqMe6jClZAzE=.cc905cb9-47e2-4d05-8557-e6e840b5d3df@github.com>

On Mon, 5 Jun 2023 15:14:35 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed copyright header
>
> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 50:
> 
>> 48: /**
>> 49:  * Main entry points for parsing, transforming, and generating classfiles.
>> 50:  */
> 
> Now that this is not just a bag of static methods any more, we need to have some spec text about what a Classfile is.  Something like:
> 
> Represents a context for parsing, transforming, and generating classfiles.  A `Classfile` has a set of options that condition how parsing and generation is done.

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 54:
> 
>> 52:         permits ClassfileImpl {
>> 53: 
>> 54:     static Classfile of() {
> 
> Classfile::of needs specification

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 63:
> 
>> 61: 
>> 62:     Classfile withOptions(Option... options);
>> 63: 
> 
> Classfile::withOptions needs specification

Fixed, thanks.

> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66:
> 
>> 64:     /**
>> 65:      * An option that affects the writing of classfiles.
>> 66:      */
> 
> Options affect parsing as well as writing now

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431266
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431345
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431300
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1218431386

From asotona at openjdk.org  Mon Jun  5 18:30:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:30:23 GMT
Subject: Integrated: 8308842: Consolidate exceptions thrown from Class-File API
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <NPZj7GUH_nYvNUXjGojK435TEGsHwbvcmaE4WLZiW8c=.aa6c23c0-1c1b-448d-9124-65d0cb7f6452@github.com>

On Thu, 25 May 2023 08:29:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 4b8922f5
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b8922f57611d06a9bea5c94e2f4493dc42a2053
Stats:     154 lines in 15 files changed: 90 ins; 7 del; 57 mod

8308842: Consolidate exceptions thrown from Class-File API

Reviewed-by: briangoetz

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

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

From jlaskey at openjdk.org  Mon Jun  5 18:48:56 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 5 Jun 2023 18:48:56 GMT
Subject: Integrated: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview)
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <wgo5PLPjk9AGBUnL1OZHyZmjYvYA9YKuqIadaHHC0YA=.426c5759-14d2-4afb-9ade-d998e05a3f37@github.com>

On Thu, 27 Apr 2023 12:38:11 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Add flexible main methods and anonymous main classes to the Java language.

This pull request has now been integrated.

Changeset: 98b53c06
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98b53c06cfffe7b2e21968546b4aa1523f31132e
Stats:     1685 lines in 40 files changed: 1510 ins; 32 del; 143 mod

8306112: Implementation of JEP 445: Unnamed Classes and Instance Main Methods (Preview)
8308613: javax.lang.model updates for JEP 445 (preview)
8308913: Update core reflection for JEP 445 (preview)

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Joe Darcy <darcy at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Jim Laskey <jlaskey at openjdk.org>
Co-authored-by: Adam Sotona <asotona at openjdk.org>
Reviewed-by: mcimadamore, vromero, darcy

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

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

From dl at openjdk.org  Mon Jun  5 18:58:58 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 5 Jun 2023 18:58:58 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for poll()
Message-ID: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>

This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

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

Commit messages:
 - Use Thread.isVirtual to distinguish spin vs immediate block cases

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

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

From asotona at openjdk.org  Mon Jun  5 18:59:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 5 Jun 2023 18:59:07 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v7]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <tUOLpZqt3ikr1-fNNxDlS-zfxXF8SKVbuipXpxXJyaM=.c27de293-2ca8-4452-b405-966895376f98@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> 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 27 commits:

 - Merge branch 'master' into JDK-8308899-context
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
   #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
   #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
   #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - added missing javadoc
 - simplified options names
 - fixed copyright header
 - Merge branch 'master' into JDK-8308899-context
 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - fixed snippets and added SnippetsTest
 - fixed javadoc
 - ... and 17 more: https://git.openjdk.org/jdk/compare/4b8922f5...0c3c1913

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

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=06
  Stats: 1603 lines in 106 files changed: 491 ins; 212 del; 900 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From never at openjdk.org  Mon Jun  5 19:01:23 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 5 Jun 2023 19:01:23 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <1vHZFp-j2AKjYTX2bd_1RxQ2Ix252OCbqJ0m-AGaVTs=.b64ea885-8b22-45ad-8a76-b041a764a5de@github.com>

On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real  ...

I don't really love the hard code parsing of the HashMap.  What properties are actually required for JVMCI?  It seems to me that the contents of Arguments::system_properties() should contain all the properties we want to advertise to JVMCI.  That would have avoid having to decode them after they've been converted into Java objects.

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

PR Comment: https://git.openjdk.org/jdk/pull/14291#issuecomment-1577305531

From never at openjdk.org  Mon Jun  5 19:20:25 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 5 Jun 2023 19:20:25 GMT
Subject: RFR: 8309501: Remove workaround in bin/idea.sh for non standard JVMCI
 file layout
Message-ID: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>

This allows bin/idea.sh to properly see the JVMCI files again.

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

Commit messages:
 - 8309501: Remove workaround in bin/idea.sh for non standard JVMCI file layout

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

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

From mchung at openjdk.org  Mon Jun  5 19:41:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 5 Jun 2023 19:41:04 GMT
Subject: RFR: 8301721: lookup.findSpecial fails on Object method call from
 interface
Message-ID: <ngx6hmVa6YcVebkWTP90YEw83sBSjzX5CEHZNLpZ1aQ=.f0365180-b052-4126-85a3-5d16028f32bc@github.com>

Lookup.findSpecial fails on Object method call from an interface because of a bug in the implementation calling `Class::getSuperclass` on an interface which has no superclass.   The implementation should only search the method from its superclass only if it's a class.   This patch is trivial and skip the superclass search if it's an interface.

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

Commit messages:
 - clean up test
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8301721
 - 8301721: lookup.findSpecial fails on Object method call from interface

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

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

From alanb at openjdk.org  Mon Jun  5 19:46:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 19:46:53 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>
Message-ID: <MYT2jZZfh3gpAf3ovevvUHF4b1UhCnZfHdrJ7bmuBxk=.d0671acf-8f9d-4913-903a-8f5dde98a981@github.com>

On Mon, 5 Jun 2023 17:25:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think we need to delay this until [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in case we would like to revert [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).

Okay, I won't integrate this until we see what the issue is. That said, if the sub-mills support needs to be reverted then I think we should keep the interface as nanos on the bound between the VM and the libraries. The reason is that it's mostly nanos at the Java level now, meaning 2 out of the 3 sleep methods support sub-mills, and the virtual thread sleep and the JFR event are in nanos too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14303#issuecomment-1577374410

From dnsimon at openjdk.org  Mon Jun  5 19:58:58 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 5 Jun 2023 19:58:58 GMT
Subject: RFR: 8309501: Remove workaround in bin/idea.sh for non standard
 JVMCI file layout
In-Reply-To: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>
References: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>
Message-ID: <0Gk3T7xF9-LaTG7tpYdH3oa-hb8OKXw4jIkTb9DtIT4=.06bc15b6-4503-456a-bcb9-bb913d7e2ea1@github.com>

On Mon, 5 Jun 2023 19:12:52 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This allows bin/idea.sh to properly see the JVMCI files again.

Marked as reviewed by dnsimon (Committer).

Finally ;-)

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

PR Review: https://git.openjdk.org/jdk/pull/14318#pullrequestreview-1463296723
PR Comment: https://git.openjdk.org/jdk/pull/14318#issuecomment-1577386454

From cjplummer at openjdk.org  Mon Jun  5 20:10:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 20:10:54 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
 <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>
Message-ID: <kQ3W95PGzZJZlAETD5X1vZLJrr2D6MQaUGYuANKzPEU=.8f8e19b2-d2d4-462e-b05f-b608e69549b8@github.com>

On Mon, 5 Jun 2023 15:10:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java line 660:
>> 
>>> 658:         expectedMethods.add(Thread.class.getName() + ".sleep");
>>> 659:         expectedMethods.add(Thread.class.getName() + ".sleepNanos");
>>> 660:         expectedMethods.add(Thread.class.getName() + ".sleepNanos0");
>> 
>> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.
>
>> There is one potential, pre-existing, test omission noted below.
>> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.
> 
> The monitoring/stress/thread tests will fail if they observe an unexpected method name in the stack trace. I don't think it can happen because the tests poll the thread state and for SleepingThread, it will sample the stack trace when the thread state is timed-wait. The beforeSleep/afterSleep methods won't in the stack trace when sleeping. It would be harmless to add them in that they aren't going to cause these tests to fail but might help with any further changes.

The following commit in loom heavily modified this file with a lot of added expected methods. There are other related tests with similar changes. I'm not so sure I understand the need for so many additions, and also why expectedLength is so out of sync with the number of added method. I don't believe this commit was reviewed individually, but was just part of the overall loom review when merge into jdk. Perhaps it should be revisited.

https://github.com/openjdk/loom/commit/26e66bc1a6a0dd735c8138a696809caba3e82b26

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1218539693

From mchung at openjdk.org  Mon Jun  5 20:11:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 5 Jun 2023 20:11:56 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v4]
In-Reply-To: <Z5KdxF-FS6CtSQUg1Jg4iFyxQjLInqQhvXMre-xdbC0=.bd7107e2-c9bf-4660-9009-1dfaa18febbb@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <Z5KdxF-FS6CtSQUg1Jg4iFyxQjLInqQhvXMre-xdbC0=.bd7107e2-c9bf-4660-9009-1dfaa18febbb@github.com>
Message-ID: <jPusp-2hoofQJlaeRNLJS7WH2OwGTvQTqt2F-1pQdUs=.75f0620f-6f28-4949-8347-2435178f3372@github.com>

On Thu, 1 Jun 2023 13:43:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Sync up from loom repo
>  - Merge
>  - Sync with loom repo, re-work ScopedValue class description
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a46b5acc...cc902ce6

I reviewed the implementation changes to promote an incubating API to a preview API.  That part looks good.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13932#pullrequestreview-1463317525

From erikj at openjdk.org  Mon Jun  5 20:14:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 Jun 2023 20:14:51 GMT
Subject: RFR: 8309501: Remove workaround in bin/idea.sh for non standard
 JVMCI file layout
In-Reply-To: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>
References: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>
Message-ID: <AJ-Ipv4myhMkPdnuqgiAESCpYML_RODjvZov02JRZE8=.369f362f-f598-4b28-a5af-904e191937a2@github.com>

On Mon, 5 Jun 2023 19:12:52 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This allows bin/idea.sh to properly see the JVMCI files again.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14318#pullrequestreview-1463324474

From darcy at openjdk.org  Mon Jun  5 20:19:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 20:19:07 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v4]
In-Reply-To: <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <EXcqowBv1-HTIfStJ-vIZn7c3OCy3yuHCuoK60Qm5-Q=.e25cee89-a18a-4378-a1af-5fbdc4acd087@github.com>
Message-ID: <OmhaWDYhULTSadw7_EjsJfBbx58KXnm1g_NxwA5_TuU=.d02537b2-c876-4513-a507-74664ef0f610@github.com>

On Fri, 2 Jun 2023 04:48:35 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Explain in java.lang.Class how unnamed classes are modeled in core reflection.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update reflective support.

The changes for JDK-8308913 were integrated as part of the main JEP 445 PR; closing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14165#issuecomment-1577416694

From darcy at openjdk.org  Mon Jun  5 20:19:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 20:19:09 GMT
Subject: Withdrawn: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <0x4tHZLix1QJgmih0k2gHKDNXDJcyKNsjsqheKpRXZ4=.dde59617-56c8-44cc-b73b-c9e4c6e8a8f9@github.com>

On Fri, 26 May 2023 02:06:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Jun  5 21:04:10 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 5 Jun 2023 21:04:10 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
In-Reply-To: <TWCccPKtK5maQ3__2M8m6crRhBaIQGR_YDQGsqqSliA=.eadf8f5e-2a4a-4c70-baad-2b2a645c0025@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
 <TWCccPKtK5maQ3__2M8m6crRhBaIQGR_YDQGsqqSliA=.eadf8f5e-2a4a-4c70-baad-2b2a645c0025@github.com>
Message-ID: <Ks4GzY0XZOEfLEqY4XYe4BCNHtLOn4BtNosTgQg7btk=.326ae6e0-eed8-4916-917a-31e572f29be0@github.com>

On Wed, 31 May 2023 14:05:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Reflecting review feedback.
>>  - Merge branch 'master' into JDK-8291966
>>  - Adding comments
>>  - Improving performance
>>  - Merge branch 'master' into JDK-8291966
>>  - 8291966: SwitchBootstrap.typeSwitch could be faster
>
> This patch is intended to eliminate some consecutive unnecessary tests like in case like:
> 
> switch (o) {
>     case Runnable r when ... -> {}
>     case Runnable r when ... -> {}
>     case Runnable r when ... -> {}
>     case Object o -> {}
> }
> 
> 
> If `o` is not a `Runnable`, the `instanceof` will only happen for the first case, and the rest will be skipped, as these tests could not pass. But (as a current limitation), if it is not a consecutive run, the duplicate `instanceof` checks will still happen.
> 
> I am quite sure there are ways to improve the bootstrap further, but might be better to have some (more) real-world examples to know what to optimize for.

@lahodaj
> This patch is intended to eliminate some consecutive unnecessary tests like in case like:
> 
> ```java
> switch (o) {
>     case Runnable r when ... -> {}
>     case Runnable r when ... -> {}
>     case Runnable r when ... -> {}
>     case Object o -> {}
> }
> ```

I would expect that the above code would produce bytecode equivalent to:

loop: for (int _i = 0;;) {
	switch (invokedynamic typeSwitch(o, _i) { Runnable.class, Object.class }) {
		case 0 /* Runnable */ -> {
			_i++;
			Runnable r = (Runnable) o;
			if (...) {
				break loop;
			} else if (...) {
				break loop;
			} else if (...) {
				break loop;
			}
			continue loop;
		}
		case 1 /* Object */ -> {
			_i++;
			break loop;
		}
		case -1 -> throw new NullPointerException();
		default -> throw new MatchException();
	}
}

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

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1577468813

From darcy at openjdk.org  Mon Jun  5 21:14:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 5 Jun 2023 21:14:46 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v3]
In-Reply-To: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
Message-ID: <WV3Mn3ru05770nLHgK3zULHV6l3MJIDQYswx6tJf1pM=.6344b785-0aa7-4d27-96e2-b5e77d7a82d4@github.com>

> Document existing behavior.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14305/files
  - new: https://git.openjdk.org/jdk/pull/14305/files/5c7e4172..33bb646b

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

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

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

From mchung at openjdk.org  Mon Jun  5 21:36:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 5 Jun 2023 21:36:52 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v3]
In-Reply-To: <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
 <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>
Message-ID: <mYCrZ-f5CXsPCZIOUDSvBEXsDUVgaaPyAcvJfjAvxtk=.8f967e7c-7038-40ea-a80e-bf84bfd074cc@github.com>

On Mon, 5 Jun 2023 18:02:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 758:
>> 
>>> 756:      *     <td>Greatest Java class file format version recognized by the runtime as {@code "MAJOR.MINOR"}
>>> 757:      *     where {@link java.lang.reflect.ClassFileFormatVersion#major() MAJOR} and {@code MINOR}
>>> 758:      *     are both formatted as decimal integers</td></tr>
>> 
>> I'm not sure about using the adjective "Greatest" here, only because "Greatest ... recognized" reads a bit like recognition of greatness when it really wants to convey that it's the highest version recognized.
>> 
>> Does the wording need to take account of running with preview features enabled? 
>> 
>> The table uses "Java runtime" rather than "runtime" in the description of some of the other properties.
>> 
>> In passing, should the descriptions of RELEASE_xxx in ClassFileFormatVersion say "The highest version recognized" rather than the "The version recognized"?
>
> Update PR and CSR to use the wording:
> 
> "Latest Java class file format version recognized by the Java runtime as "MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"
> 
> While it wouldn't be unreasonable to assume that when running under --enable-preview that the minor version was 65535, it is printed out as 0 with or without preview being enabled.
> 
> I didn't want to broach preview-ness as part of this update to either promise or document the current behavior.

Related to Alan's comment on RELEASE_xxx in ClassFileFormatVersion, perhaps the class description can clarify that a class file version has major version number `M` and minor version number `m` and a Java Virtual Machine implementation can support a class file format of version v if and only if v lies in some contiguous range Mi.0 ? v ? Mj.m.   RELEASE_xxx represents the major version number. 

That way, the description of RELEASE_xxx can remain to say "The version recognized...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1218619362

From iris at openjdk.org  Mon Jun  5 21:42:55 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 5 Jun 2023 21:42:55 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v3]
In-Reply-To: <WV3Mn3ru05770nLHgK3zULHV6l3MJIDQYswx6tJf1pM=.6344b785-0aa7-4d27-96e2-b5e77d7a82d4@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <WV3Mn3ru05770nLHgK3zULHV6l3MJIDQYswx6tJf1pM=.6344b785-0aa7-4d27-96e2-b5e77d7a82d4@github.com>
Message-ID: <mfWtm7VzWnnOGUzNgZ3VwCeOE_sIzOJetU3zqbw3CRs=.e23cc901-041c-4a32-b00b-c1075e6176a0@github.com>

On Mon, 5 Jun 2023 21:14:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Document existing behavior.
>> 
>> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14305#pullrequestreview-1463528177

From iris at openjdk.org  Mon Jun  5 21:42:56 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 5 Jun 2023 21:42:56 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v3]
In-Reply-To: <mYCrZ-f5CXsPCZIOUDSvBEXsDUVgaaPyAcvJfjAvxtk=.8f967e7c-7038-40ea-a80e-bf84bfd074cc@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
 <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>
 <mYCrZ-f5CXsPCZIOUDSvBEXsDUVgaaPyAcvJfjAvxtk=.8f967e7c-7038-40ea-a80e-bf84bfd074cc@github.com>
Message-ID: <MZ3-dAAGpVj_oPJ5VR5Y00kTK97PEhIHlKf2nbT60E4=.19c43172-7d04-4412-8815-b1d522ca951c@github.com>

On Mon, 5 Jun 2023 21:34:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Update PR and CSR to use the wording:
>> 
>> "Latest Java class file format version recognized by the Java runtime as "MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"
>> 
>> While it wouldn't be unreasonable to assume that when running under --enable-preview that the minor version was 65535, it is printed out as 0 with or without preview being enabled.
>> 
>> I didn't want to broach preview-ness as part of this update to either promise or document the current behavior.
>
> Related to Alan's comment on RELEASE_xxx in ClassFileFormatVersion, perhaps the class description can clarify that a class file version has major version number `M` and minor version number `m` and a Java Virtual Machine implementation can support a class file format of version v if and only if v lies in some contiguous range Mi.0 ? v ? Mj.m.   RELEASE_xxx represents the major version number. 
> 
> That way, the description of RELEASE_xxx can remain to say "The version recognized...".

The decimal integer should be unsigned and without leading zeros.  A regex similar to that provided by Runtime.Version would make things clear.  I think that Mandy's suggestion would be a reasonable alternative as the Java class file version number isn't truly arbitrary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1218623501

From naoto at openjdk.org  Mon Jun  5 21:50:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 Jun 2023 21:50:56 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
Message-ID: <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>

On Fri, 2 Jun 2023 01:07:27 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> SUN Guoyun 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:
>> 
>>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 369:
> 
>> 367:             BaseLocale l = key.holder;
>> 368:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
>> 369:             return (new Key(locale)).getBaseLocale();
> 
> Perhaps a more rigorous approach would look like this?
> <pre><code class="java">
> BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
> BaseLocal value = (new Key(locale)).getBaseLocale();
> Reference.reachabilityFence(locale);
> return value;
> </code></pre>
> But the current patch has passed the tests with `-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, so I think the current patch is OK.

I still don't see a clear explanation of how the proposed patch fixes the problem. Also, I would appreciate the reasoning in the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1218629550

From bchristi at openjdk.org  Mon Jun  5 22:03:55 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 5 Jun 2023 22:03:55 GMT
Subject: RFR: 8308167: SequencedMap::firstEntry throws NPE when first entry
 has null key or value
In-Reply-To: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
References: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
Message-ID: <Inw_XsVUOEAmZiK6pi7HpJPggfo5OrErwSEG7aiNtDg=.0ed0e06d-8baf-4f95-9347-b35e496be536@github.com>

On Fri, 2 Jun 2023 01:12:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Create and use new NullableKeyValueHolder class to accommodate map entries whose key or value might be null.

Changes look good.
    
An observation:
`TreeMap` implements `SequencedMap`, and I see that its `firstEntry()` and related methods use `AbstractMap.SimpleImmutableEntry` (via `exportEntry()`), despite it being serializable. However, this is long-standing code (from 1.6, perhaps?), and `TreeMap` is itself serializable. So, leaving it as is seems the right thing to do.

src/java.base/share/classes/jdk/internal/util/NullableKeyValueHolder.java line 65:

> 63:  * Map.of might still need to reject nulls, and so would Map.ofEntries) but allowing
> 64:  * a Map.Entry itself to contain nulls seems beneficial in general. If this is done,
> 65:  * merging KeyValueHolder and NullableKeyValueHolder should be reconsidered.

I think having this background and explanation in the docs for this internal class is fine.
IMO, this information would also be useful to have in the bug report.

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

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14278#pullrequestreview-1463441861
PR Review Comment: https://git.openjdk.org/jdk/pull/14278#discussion_r1218591121

From liach at openjdk.org  Mon Jun  5 22:36:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 Jun 2023 22:36:53 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v5]
In-Reply-To: <7QpluTpgWuXPhJixDBTovoZsOsQAVUUmd8LJ4q9L8Kg=.65b21779-218e-4e16-b69a-3bff366c42a5@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>
 <7QpluTpgWuXPhJixDBTovoZsOsQAVUUmd8LJ4q9L8Kg=.65b21779-218e-4e16-b69a-3bff366c42a5@github.com>
Message-ID: <pbwfwQKvDPX-rlsNjKpNtBkJl7nxdTkVAQqJi6Xd2VA=.3253d980-146d-4b74-945b-6b8f9aed825f@github.com>

On Mon, 5 Jun 2023 17:27:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Forgot to upload latest micro
>>  - general optimizations to MTD, no longer change backing storage
>
> src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 84:
> 
>> 82:             paramTypes = new ClassDesc[paramCount];
>> 83:             for (int i = 0; i < paramCount; i++) {
>> 84:                 paramTypes[i] = validateParameter(ClassDesc.ofDescriptor(types.get(i + 1)));
> 
> It seems useful to have a static factory method to take a trusted copy of parameter types and it will validate the parameters before constructing `MethodTypeDescImpl` instance.   Parameter validation in one single place.    Several methods doing the validation can simply call this factory method and the code would be cleaner.
> 
> `insertParameterTypes` can call it as well and overhead of re-validating existing parameter types isn't a big issue.

Should I just keep track of the slot count of MethodTypeDesc instead? Having a slot count implicitly requires validating the parameters, and the slot count can be used to eagerly reject `resolveConstantDesc` on MTD with over 255 slots.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218664978

From mchung at openjdk.org  Mon Jun  5 23:06:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 5 Jun 2023 23:06:53 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v5]
In-Reply-To: <pbwfwQKvDPX-rlsNjKpNtBkJl7nxdTkVAQqJi6Xd2VA=.3253d980-146d-4b74-945b-6b8f9aed825f@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>
 <7QpluTpgWuXPhJixDBTovoZsOsQAVUUmd8LJ4q9L8Kg=.65b21779-218e-4e16-b69a-3bff366c42a5@github.com>
 <pbwfwQKvDPX-rlsNjKpNtBkJl7nxdTkVAQqJi6Xd2VA=.3253d980-146d-4b74-945b-6b8f9aed825f@github.com>
Message-ID: <j_dILDX8I0mJA6KXRRX9WVm21Mzon6UUlGoMhVRPAA8=.6453de1c-6074-46f3-a8df-88ba4e9c4701@github.com>

On Mon, 5 Jun 2023 22:34:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 84:
>> 
>>> 82:             paramTypes = new ClassDesc[paramCount];
>>> 83:             for (int i = 0; i < paramCount; i++) {
>>> 84:                 paramTypes[i] = validateParameter(ClassDesc.ofDescriptor(types.get(i + 1)));
>> 
>> It seems useful to have a static factory method to take a trusted copy of parameter types and it will validate the parameters before constructing `MethodTypeDescImpl` instance.   Parameter validation in one single place.    Several methods doing the validation can simply call this factory method and the code would be cleaner.
>> 
>> `insertParameterTypes` can call it as well and overhead of re-validating existing parameter types isn't a big issue.
>
> Should I just keep track of the slot count of MethodTypeDesc instead? Having a slot count implicitly requires validating the parameters, and the slot count can be used to eagerly reject `resolveConstantDesc` on MTD with over 255 slots.

I don't think `resolveConstantDesc` is performance-sensitive that needs the eager checking of the number of parameter slots.  Also the common case is to resolve a good MethodType with <= 255 parameter slots.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218681876

From liach at openjdk.org  Mon Jun  5 23:38:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 Jun 2023 23:38:11 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v6]
In-Reply-To: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
Message-ID: <7Fdmlm1dPVZvr0ZVDtdqLS12AYtOJrG0qGOYdpy4Fzk=.2ee01753-e3e6-4879-8f66-9e81b4e2b7d8@github.com>

> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
> 
> 
> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op

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

  Fixes for review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13186/files
  - new: https://git.openjdk.org/jdk/pull/13186/files/f71c0fab..6d47e9bf

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

  Stats: 84 lines in 6 files changed: 22 ins; 21 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/13186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13186/head:pull/13186

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

From liach at openjdk.org  Mon Jun  5 23:38:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 5 Jun 2023 23:38:12 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v5]
In-Reply-To: <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <H4Z625uuQITJwvb1_p-5Nttwi6yNY1Rx4IFVAsybnLs=.ca7158ed-07d0-4049-8e6e-2e7e717219eb@github.com>
Message-ID: <77iNBjcSyZDhdgJBQXwMEz3B9cMVKjRQtDHQWFgLsv0=.a4c37a2e-5262-45cf-89eb-366aa3683aae@github.com>

On Sun, 4 Jun 2023 23:52:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
>> 
>> 
>> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
>> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
>> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
>> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
>> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
>> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
>> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
>> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
>> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
>> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
>> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
>> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
>> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
>> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
>> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
>> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
>> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op
>
> 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:
> 
>  - Forgot to upload latest micro
>  - general optimizations to MTD, no longer change backing storage

I added an `ofTrusted` factory in MTD impl to validate a trusted parameter array. The name is intentionally chosen to distinguish from the regular `MethodTypeDesc.of` which accepts untrusted arrays.

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

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1577686771

From smarks at openjdk.org  Tue Jun  6 00:23:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 6 Jun 2023 00:23:08 GMT
Subject: Integrated: 8308167: SequencedMap::firstEntry throws NPE when first
 entry has null key or value
In-Reply-To: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
References: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
Message-ID: <NtTPG3X7DR1zGtKl5QGEL3aPC_AKMfyICp7C8Iiw7nk=.31dae6ed-be9d-41b4-bdef-fd7f40c02da2@github.com>

On Fri, 2 Jun 2023 01:12:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Create and use new NullableKeyValueHolder class to accommodate map entries whose key or value might be null.

This pull request has now been integrated.

Changeset: 6d155a47
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6d155a47f13ff80cf7a9de363fc5ae2943b6603a
Stats:     214 lines in 4 files changed: 208 ins; 0 del; 6 mod

8308167: SequencedMap::firstEntry throws NPE when first entry has null key or value

Reviewed-by: bchristi

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

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

From smarks at openjdk.org  Tue Jun  6 00:23:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 6 Jun 2023 00:23:06 GMT
Subject: RFR: 8308167: SequencedMap::firstEntry throws NPE when first entry
 has null key or value
In-Reply-To: <Inw_XsVUOEAmZiK6pi7HpJPggfo5OrErwSEG7aiNtDg=.0ed0e06d-8baf-4f95-9347-b35e496be536@github.com>
References: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
 <Inw_XsVUOEAmZiK6pi7HpJPggfo5OrErwSEG7aiNtDg=.0ed0e06d-8baf-4f95-9347-b35e496be536@github.com>
Message-ID: <d4APeqx7fjCCW-22IEOpegg_lijnoJ_X8YO9m_RSSbk=.c408f955-d7e1-4407-be3f-46638938b95a@github.com>

On Mon, 5 Jun 2023 21:03:18 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Create and use new NullableKeyValueHolder class to accommodate map entries whose key or value might be null.
>
> src/java.base/share/classes/jdk/internal/util/NullableKeyValueHolder.java line 65:
> 
>> 63:  * Map.of might still need to reject nulls, and so would Map.ofEntries) but allowing
>> 64:  * a Map.Entry itself to contain nulls seems beneficial in general. If this is done,
>> 65:  * merging KeyValueHolder and NullableKeyValueHolder should be reconsidered.
> 
> I think having this background and explanation in the docs for this internal class is fine.
> IMO, this information would also be useful to have in the bug report.

I'll add a note to the bug report pointing to this rationale.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14278#discussion_r1218735097

From smarks at openjdk.org  Tue Jun  6 00:23:04 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 6 Jun 2023 00:23:04 GMT
Subject: RFR: 8308167: SequencedMap::firstEntry throws NPE when first entry
 has null key or value
In-Reply-To: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
References: <4oXToDIsaO3U3IzQqHeqccp2c6C2ZgeqLsldzqrHyiQ=.21611d5d-2941-4b99-9883-b6e0b8e2db3b@github.com>
Message-ID: <Q6caLrsCnrYxt6fxhTCc7jH-bQ1b2kIUz1pZ7tFdtyY=.2a4b12be-c91b-4dff-a78e-5d6a95c5d334@github.com>

On Fri, 2 Jun 2023 01:12:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Create and use new NullableKeyValueHolder class to accommodate map entries whose key or value might be null.

Thanks for looking at this.

Yeah, the serializability of various Entry objects that are exposed through the APIs is all over the map, so to speak. Note that entries obtained from the entrySet() of HashMap and TreeMap are _not_ serializable. These are actual internal nodes of the respective Map implementations. But TreeMap uses AbstractMap.SimpleImmutableEntry in several places to disconnect the returned entry from the map, and that class is serializable. Oh well. (And yes that code dated back to the beginning of the available OpenJDK history, which puts it at JDK 1.6 or at least certainly before 7.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14278#issuecomment-1577719707

From mchung at openjdk.org  Tue Jun  6 00:24:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 6 Jun 2023 00:24:59 GMT
Subject: RFR: 8309413: General improvements to MethodTypeDesc
 implementation [v6]
In-Reply-To: <7Fdmlm1dPVZvr0ZVDtdqLS12AYtOJrG0qGOYdpy4Fzk=.2ee01753-e3e6-4879-8f66-9e81b4e2b7d8@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <7Fdmlm1dPVZvr0ZVDtdqLS12AYtOJrG0qGOYdpy4Fzk=.2ee01753-e3e6-4879-8f66-9e81b4e2b7d8@github.com>
Message-ID: <Y0yU8w00tOK3hDmlKyiQinSoI5Wy0h-UGT2G2RV7S7Y=.e5954d75-0f83-4e2f-b935-fd4e38223919@github.com>

On Mon, 5 Jun 2023 23:38:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
>> 
>> 
>> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
>> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
>> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
>> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
>> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
>> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
>> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
>> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
>> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
>> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
>> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
>> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
>> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
>> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
>> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
>> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
>> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes for review

Thanks for the change and it looks better.   I updated the description of JDK-8309413 to make it clearer.

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 57:

> 55:      * @param validatedArgTypes {@link ClassDesc}s describing the trusted and validated parameter types
> 56:      */
> 57:     MethodTypeDescImpl(ClassDesc returnType, ClassDesc[] validatedArgTypes) {

Can make this constructor private to prevent accidental use with invalidated argTypes.   `MethodTypeDesc.of(ClassDesc returnDesc)` can call `ofTrusted` factory method.

src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line 106:

> 104:         } else {
> 105:             result = new MethodTypeDescImpl(returnType, ConstantUtils.EMPTY_CLASSDESC);
> 106:         }

Suggestion:

        int paramCount = types.size() - 1;
        var paramTypes = paramCount > 0 ? new ClassDesc[paramCount] : ConstantUtils.EMPTY_CLASSDESC;
        for (int i = 0; i < paramCount; i++) {
            paramTypes[i] = ClassDesc.ofDescriptor(types.get(i + 1));
        }
        result = ofTrusted(returnType, paramTypes);

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

PR Review: https://git.openjdk.org/jdk/pull/13186#pullrequestreview-1463810992
PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218713450
PR Review Comment: https://git.openjdk.org/jdk/pull/13186#discussion_r1218736291

From liach at openjdk.org  Tue Jun  6 00:37:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 00:37:18 GMT
Subject: RFR: 8309413: Improve the performance of
 MethodTypeDesc::descriptorString [v7]
In-Reply-To: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
Message-ID: <QX9hxI-nNyUJi5ABhCchv_xJVlu51FQ5OI9OlKWyPJA=.51e03182-6335-43e4-a8d5-846716fa150f@github.com>

> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
> 
> 
> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op

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

 - Review changes
 - Apply suggestions from code review
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13186/files
  - new: https://git.openjdk.org/jdk/pull/13186/files/6d47e9bf..fa66020a

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

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

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

From mchung at openjdk.org  Tue Jun  6 01:08:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 6 Jun 2023 01:08:54 GMT
Subject: RFR: 8309413: Improve the performance of
 MethodTypeDesc::descriptorString [v7]
In-Reply-To: <QX9hxI-nNyUJi5ABhCchv_xJVlu51FQ5OI9OlKWyPJA=.51e03182-6335-43e4-a8d5-846716fa150f@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <QX9hxI-nNyUJi5ABhCchv_xJVlu51FQ5OI9OlKWyPJA=.51e03182-6335-43e4-a8d5-846716fa150f@github.com>
Message-ID: <4vPDkJ5nuZJAcnATKO3WrThcR_zxbrzoUmM8S-Eixqc=.1ed0ca7e-e319-4704-b554-f08a12c65342@github.com>

On Tue, 6 Jun 2023 00:37:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
>> 
>> 
>> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
>> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
>> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
>> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
>> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
>> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
>> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
>> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
>> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
>> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
>> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
>> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
>> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
>> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
>> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
>> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
>> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review changes
>  - Apply suggestions from code review
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13186#pullrequestreview-1463960042

From darcy at openjdk.org  Tue Jun  6 01:36:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 01:36:54 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v3]
In-Reply-To: <MZ3-dAAGpVj_oPJ5VR5Y00kTK97PEhIHlKf2nbT60E4=.19c43172-7d04-4412-8815-b1d522ca951c@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
 <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>
 <mYCrZ-f5CXsPCZIOUDSvBEXsDUVgaaPyAcvJfjAvxtk=.8f967e7c-7038-40ea-a80e-bf84bfd074cc@github.com>
 <MZ3-dAAGpVj_oPJ5VR5Y00kTK97PEhIHlKf2nbT60E4=.19c43172-7d04-4412-8815-b1d522ca951c@github.com>
Message-ID: <erOlNd7RKExeGwKNcczF9Vg98vYcQugqrWiufwu0HTw=.5aa67c8a-b4a8-460e-aec1-13e4ef118069@github.com>

On Mon, 5 Jun 2023 21:39:49 GMT, Iris Clark <iris at openjdk.org> wrote:

> The decimal integer should be unsigned and without leading zeros. A regex similar to that provided by Runtime.Version would make things clear. I think that Mandy's suggestion would be a reasonable alternative as the Java class file version number isn't truly arbitrary.

A quick note on API philosophy, in its current version the PR proposes to go from very imprecise information:

"Java class format version number"

to to moderate level of precision:

"Latest Java class file format version recognized by the Java runtime as "MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"

Especially given the terse description of most of the property keys, I don't think grammar-level detailing is necessary in this context.

For example, to me the specification of, say, Method.toString is unhelpful to the reader since the gist of the semantics are overwhelmed with details as if the primary consumer was a parser rather than a human reader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1218767482

From duke at openjdk.org  Tue Jun  6 02:33:52 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 6 Jun 2023 02:33:52 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
Message-ID: <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>

On Mon, 5 Jun 2023 21:48:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 369:
>> 
>>> 367:             BaseLocale l = key.holder;
>>> 368:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
>>> 369:             return (new Key(locale)).getBaseLocale();
>> 
>> Perhaps a more rigorous approach would look like this?
>> <pre><code class="java">
>> BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
>> BaseLocal value = (new Key(locale)).getBaseLocale();
>> Reference.reachabilityFence(locale);
>> return value;
>> </code></pre>
>> But the current patch has passed the tests with `-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot`, so I think the current patch is OK.
>
> I still don't see a clear explanation of how the proposed patch fixes the problem. Also, I would appreciate the reasoning in the comments.

For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.

That's why I didn't use `Reference.reachabilityFence(locale)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1218793510

From duke at openjdk.org  Tue Jun  6 03:03:30 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 6 Jun 2023 03:03:30 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v4]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <D8om79XyCpwmSnuz9P0j412JAe4DuvPqu9nz03EdXdU=.f10c4b1b-1d94-482d-9944-660651b63b9b@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

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

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/a09f1b6f..75fd5951

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

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

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

From jpai at openjdk.org  Tue Jun  6 04:57:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jun 2023 04:57:51 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
Message-ID: <98fLhdNGS8lR2zjfCGVclbqpuizh5Bh2-F9_sBM_dwE=.a3ac2d37-219a-456e-8063-0c15fe460ecd@github.com>

On Thu, 1 Jun 2023 16:18:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.

src/java.base/share/classes/java/util/SequencedMap.java line 268:

> 266:      * Its {@link SequencedSet#reversed reversed} method returns the {@link
> 267:      * #sequencedKeySet sequencedKeySet} view of the {@link #reversed reversed} view of
> 268:      * this map. Each of its other methods calls the corresponding method of the {@link

Hello Stuart, should this (and other similar places in this PR) instead be:

Each of its other methods call

call instead of calls?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14267#discussion_r1218897055

From jpai at openjdk.org  Tue Jun  6 05:01:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 6 Jun 2023 05:01:51 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
Message-ID: <hzkKoDYYnU05Jre-XHcijpsfAZ52PsC_CG1AB8Pf6Ow=.9932a45c-eb9c-4ef0-ba49-54bdb88dcd92@github.com>

On Thu, 1 Jun 2023 16:18:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.

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

> 906:         public boolean add(E t) { throw uoe(); }
> 907:         public boolean addAll(Collection<? extends E> c) { throw uoe(); }
> 908:         public void clear() { view().clear(); }

Each of these methods should perhaps have the `@Override` to make it clear that these correspond to the interface this class is implementing. But I see that the `AbstractMap` class itself doesn't use `@Override` anywhere, so I think it's OK to keep it consistent in its current form in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14267#discussion_r1218900019

From darcy at openjdk.org  Tue Jun  6 05:07:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 05:07:52 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
Message-ID: <36STI0UbvTjXyJJ7b7bZLoQyPjqY1lnzgTElu1Jly2Q=.3a93204a-2a73-4339-bdea-bcd89d9158fa@github.com>

On Thu, 1 Jun 2023 16:18:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14267#pullrequestreview-1464266624

From alanb at openjdk.org  Tue Jun  6 07:13:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 07:13:15 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v5]
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <Sb-ExPhDtN54QLKJxfoNEIEfF9rn6ixQlsD_QVtF0Dk=.f4fc7b17-8f8d-4ae3-b350-bbd36a5dd695@github.com>

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

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

 - Fix typo in javadoc
 - Merge
 - Merge
 - Sync up from loom repo
 - Merge
 - Sync with loom repo, re-work ScopedValue class description
 - Sync up from loom repo
 - Remove csm.Threads
 - Merge
 - Test should not be in update for main line
 - ... and 8 more: https://git.openjdk.org/jdk/compare/2e9eff56...0f514588

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

Changes: https://git.openjdk.org/jdk/pull/13932/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13932&range=04
  Stats: 9229 lines in 40 files changed: 4856 ins; 4315 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/13932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13932/head:pull/13932

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

From goetz at openjdk.org  Tue Jun  6 08:23:51 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 6 Jun 2023 08:23:51 GMT
Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base
In-Reply-To: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
References: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
Message-ID: <-yWpqiFZdPQLUCdoh0AObCt0RLIgVZpXIBdQFTAKidQ=.f35114ab-6248-4c50-9f50-d9015dbc204b@github.com>

On Fri, 2 Jun 2023 10:08:09 GMT, JoKern65 <duke at openjdk.org> wrote:

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.base.
> 
> Compiling on AIX with xlc17 which contains the new clang 15 frontend
> shows the following warnings.
> 
> built by make/modules/java.base/Lib.gmk
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
> ^
> 
> 
> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> end = (void *)nddp + size;
> 
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
> #elif _ALLBSD_SOURCE
> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten.
> 
> built by make/modules/java.base/lib/CoreLibraries.gmk
> 
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
> if (ret < sizeof(psinfo_t)) {
> ProcessHandleImpl_unix.c:  Just using the proper type `size_t` instead of `int`.
> 
> 
> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> addr < p->ldinfo_textorg + p->ldinfo_textsize) {
> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk
> 
> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> void ZLIB_INTERNAL inflate_fast(strm, start)
> ^
> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> vfprintf(stderr, fmt, vl);
> ^~~
> 
> The test library libGetXSpace.c also shows a warning.
> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.

Lib.gmk / DefaultProxySelector.c
Fixing this in the file would require a larger rework. Good.
Lib.gmk / NetworkInterface.c
This looks as if it could also be fixed in the code.
But previously, other warnings have not been fixed either.
So I'm fine with this.


CoreLibraries / deprecated-non-prototype
Fixes warning in zlib, we should not touch the code
there as it is from external. Good.

CoreLibraries / format-nonliteral
In hotspot, these warnings have been fixed, or
an attribute is used to disable them locally.
These places pop up in code scanners, too.
See compilerWarnings.hpp / ATTRIBUTE_PRINTF().
The code here can not be fixed, and
I don't see any usage of the attribute or similar
in java.base, so disabling the warning seems fine to me.
Also, it's treated similar in the other
compile block.

java_md_aix.c: good.

ProcessHandleImpl_unix.c: good

UnixNativeDispatcher.c: definitely an improvement to the code!

libGetXSpace.c: good. A test library

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

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14281#pullrequestreview-1464571177

From alanb at openjdk.org  Tue Jun  6 08:43:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 08:43:52 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v3]
In-Reply-To: <erOlNd7RKExeGwKNcczF9Vg98vYcQugqrWiufwu0HTw=.5aa67c8a-b4a8-460e-aec1-13e4ef118069@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
 <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>
 <mYCrZ-f5CXsPCZIOUDSvBEXsDUVgaaPyAcvJfjAvxtk=.8f967e7c-7038-40ea-a80e-bf84bfd074cc@github.com>
 <MZ3-dAAGpVj_oPJ5VR5Y00kTK97PEhIHlKf2nbT60E4=.19c43172-7d04-4412-8815-b1d522ca951c@github.com>
 <erOlNd7RKExeGwKNcczF9Vg98vYcQugqrWiufwu0HTw=.5aa67c8a-b4a8-460e-aec1-13e4ef118069@github.com>
Message-ID: <h23-TxkloW1vKVfOftTi6eWXd2v0QVNgYW3vwHYEOsU=.928067cd-f484-4c82-a7bb-c77813df186c@github.com>

On Tue, 6 Jun 2023 01:34:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> "Latest Java class file format version recognized by the Java runtime as "MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"

Okay, and linking to ClassFileFormatVersion.latest() is good.

Again, just to lobby for putting an adjective into the ClassFileFormatVersion.RELEASE_XX descriptions to make it clearer than the value is the latest version recognized rather than single version that the wording currently suggests.

> While it wouldn't be unreasonable to assume that when running under --enable-preview that the minor version was 65535, it is printed out as 0 with or without preview being enabled.
> 
> I didn't want to broach preview-ness as part of this update to either promise or document the current behavior.

You're right, I shouldn't have brought this up here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1219189988

From alanb at openjdk.org  Tue Jun  6 10:12:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 10:12:54 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <kQ3W95PGzZJZlAETD5X1vZLJrr2D6MQaUGYuANKzPEU=.8f8e19b2-d2d4-462e-b05f-b608e69549b8@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
 <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>
 <kQ3W95PGzZJZlAETD5X1vZLJrr2D6MQaUGYuANKzPEU=.8f8e19b2-d2d4-462e-b05f-b608e69549b8@github.com>
Message-ID: <8l9FG4c1c4Ydlv3gQBiramw0YpSthxC-4wXOxVWiIOE=.b14f4319-2ecf-47ea-8118-5a3fe60d92c2@github.com>

On Mon, 5 Jun 2023 20:05:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following commit in loom heavily modified this file with a lot of added expected methods. There are other related tests with similar changes. I'm not so sure I understand the need for so many additions, and also why expectedLength is so out of sync with the number of added method. I don't believe this commit was reviewed individually, but was just part of the overall loom review when merge into jdk. Perhaps it should be revisited.

These tests aren't easy to read or maintain, it would be good to re-visit them. In some cases, the tests capture the stack trace asynchronously so the test needs to know about all code paths.

As regards ThreadController, used by the nsk/monitoring/stress/thread/straceXXX tests, the main thread waits at a barrier (a CountDownLatch) until all sleeping threads are ready to sleep. Once the main thread is released, it checks all the sleepers are in TIMED_WAITING state and samples their stack traces with the ThreadMXBean and related APIs. The test fails if there are frames corresponding to methods that the test doesn't know about. If a thread is sleeping then we shouldn't see frames for beforeSleep/afterSlee. My reading of these tests is that the main thread could poll a SleepingThread after it counts down and before it parks in sleep. It's doing an expensive ThreadMXBean::getAllThreadIds once released and that may explain why it hasn't been seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1219348675

From apejovic at openjdk.org  Tue Jun  6 10:13:53 2023
From: apejovic at openjdk.org (Aleksandar Pejovic)
Date: Tue, 6 Jun 2023 10:13:53 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <W3X4LmX5D2g5eV-fEoV3eXWljsaA-xMdoK9X7aJFqxk=.be3107a7-a665-485e-9b0b-6a491ca0c89e@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
 <1k0o3AhR5gZkMrmtdpGqRg3MM77JTsh9pcFXraWYydE=.7e768396-ab2f-4778-9dcb-3716f28fddcc@github.com>
 <W3X4LmX5D2g5eV-fEoV3eXWljsaA-xMdoK9X7aJFqxk=.be3107a7-a665-485e-9b0b-6a491ca0c89e@github.com>
Message-ID: <uRgZv0wRJ0FHm8CaPz1Cy0snCg42633zSZTQNwiv3Bs=.110fda28-b928-40c8-a35e-074f8568fc5c@github.com>

On Mon, 5 Jun 2023 09:44:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> As far as I can tell, the delimiter hasn't changed since the file was introduced, and judging by the kernel mailing list (e.g., see [the following](https://lore.kernel.org/all/Yr5JVHhSUCrbT8OH at mtj.duckdns.org/)), I don't think it will change any time soon.
>
> I'm not convinced this is a good change. Going by that mailing list thread, it suggests that people considered changing it. If one of those attempts were successful, it would have broken this code. It makes it rather fragile. The issue, with container detection code going wrong is that you most likely never notice. Translating this to GraalVM means that the native image, would a) detect the wrong version in use or b) fail detection and use host values. In both cases the application will likely misbehave in a container setup with resource limits applied and you won't (easily) know why. So even though it's unlikely to be a problem, there is a chance it could be and it's asking for trouble for no good reason.
> 
> Therefore, being conservative about delimiters makes sense here. My choice in this case would be more robust code over relying on external factors. YMMV.

Okay, so how about something like the following, would that be more acceptable?
Suggestion:

        String[] tokens = Collections.list(new StringTokenizer(line, " \t")).toArray(new String[0]);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1219348952

From mcimadamore at openjdk.org  Tue Jun  6 10:35:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 Jun 2023 10:35:09 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v6]
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <Vsuf88ibaJ0trBF2u8MS1Lng5JtVvZHjK0z434S8mgs=.ba1db33f-f9d1-4a7e-a7de-aa191f4464bd@github.com>

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an ...

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

 - Merge branch 'master' into javadoc_fixes
 - Fix issue with ArithmeticException not being wrapped in IAE for SequenceLayout::withElementCount
   Fix issue with IAE thrown instead of UOE for ValueLayout::arrayElementVarHandle
   Add apiNote to MemorySegment::address re. reachability
 - Missed a review comment
 - Use more `{@return}` tags
 - Address review comments
 - Fix wrong link in layout well-formedness doc
 - Improve javadoc on supported linker layouts
 - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
 - Merge branch 'master' into javadoc_fixes
 - Add overflow tests
 - ... and 19 more: https://git.openjdk.org/jdk/compare/01455a07...b59edd93

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

Changes: https://git.openjdk.org/jdk/pull/14098/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=05
  Stats: 963 lines in 28 files changed: 357 ins; 138 del; 468 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

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

From alanb at openjdk.org  Tue Jun  6 10:39:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 10:39:53 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
Message-ID: <nHWKBDBa5rSqsKptFta843KpUl4zCNgWZI_8eRjHrkg=.ef4fef83-85be-4af1-9c0f-e8fa9f6be61c@github.com>

On Thu, 1 Jun 2023 16:18:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14267#pullrequestreview-1464867310

From liach at openjdk.org  Tue Jun  6 11:16:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 11:16:57 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v8]
In-Reply-To: <gotPxtkGGDqNkx5908vAQvuXufrubBUh6sxYK-CKgbI=.82b77e30-f114-418c-9ab6-4ea0d33eafc0@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <gotPxtkGGDqNkx5908vAQvuXufrubBUh6sxYK-CKgbI=.82b77e30-f114-418c-9ab6-4ea0d33eafc0@github.com>
Message-ID: <J3k7ZSn4ZLJOjiFIPW8nNXMB4g3chGGGPS6B3DjI8p0=.a99462a9-fd0d-4895-bc2a-2e53aceb42db@github.com>

On Tue, 9 May 2023 04:17:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into invoke-test-classfile
>  - Switch to ConstantDescs for <init> <clinit> and void constants
>  - Merge AnnotationsTest, remove ModuleTargetAttribute call
>  - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
>  - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge branch 'master' into invoke-test-classfile
>  - Fix LambdaStackTrace after running
>  - formatting
>  - Fix failed LambdaStackTrace test, use more convenient APIs
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/d9052b94...5db1e957

keep-alive; this will be updated for the classfile object update.

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

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1578507931

From alanb at openjdk.org  Tue Jun  6 11:44:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 11:44:53 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll()
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <kjK6x4H1mlzGxOlPtNMHlFCGfSzHdBwZoXeN97UWBhU=.5ea68b29-d559-4926-920a-7e58fcb51625@github.com>

On Mon, 5 Jun 2023 18:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

This looks okay to me, it was a bit easier than I expected.

The only comment I have is an interrupt while spinning won't be noticed until count goes to 0, that should be rare enough that it doesn't matter. We might have to tune SPIN_FOR_TIMEOUT_THRESHOLD at some point for virtual threads.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14317#pullrequestreview-1464982532

From asotona at openjdk.org  Tue Jun  6 12:15:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 6 Jun 2023 12:15:07 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v4]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <1l1hrTeZ3i2uTju6KVyTWCoSIJJ-A7nWOATG6b6FGQ8=.a327ed72-3e20-4f2b-8c94-ca257c69bdf8@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use 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 218 commits:

 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - ... and 208 more: https://git.openjdk.org/jdk/compare/98b53c06...a688bf49

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=03
  Stats: 3638 lines in 22 files changed: 835 ins; 1716 del; 1087 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From sgehwolf at openjdk.org  Tue Jun  6 12:23:54 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 6 Jun 2023 12:23:54 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <uRgZv0wRJ0FHm8CaPz1Cy0snCg42633zSZTQNwiv3Bs=.110fda28-b928-40c8-a35e-074f8568fc5c@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
 <1k0o3AhR5gZkMrmtdpGqRg3MM77JTsh9pcFXraWYydE=.7e768396-ab2f-4778-9dcb-3716f28fddcc@github.com>
 <W3X4LmX5D2g5eV-fEoV3eXWljsaA-xMdoK9X7aJFqxk=.be3107a7-a665-485e-9b0b-6a491ca0c89e@github.com>
 <uRgZv0wRJ0FHm8CaPz1Cy0snCg42633zSZTQNwiv3Bs=.110fda28-b928-40c8-a35e-074f8568fc5c@github.com>
Message-ID: <Nka3287F8P_V7mZ6U0UOIdLCFKaYdwcXJ4NGMKYOeHE=.ee892713-b3f8-4d14-a0c0-38cb64f9412b@github.com>

On Tue, 6 Jun 2023 10:10:38 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

>> I'm not convinced this is a good change. Going by that mailing list thread, it suggests that people considered changing it. If one of those attempts were successful, it would have broken this code. It makes it rather fragile. The issue, with container detection code going wrong is that you most likely never notice. Translating this to GraalVM means that the native image, would a) detect the wrong version in use or b) fail detection and use host values. In both cases the application will likely misbehave in a container setup with resource limits applied and you won't (easily) know why. So even though it's unlikely to be a problem, there is a chance it could be and it's asking for trouble for no good reason.
>> 
>> Therefore, being conservative about delimiters makes sense here. My choice in this case would be more robust code over relying on external factors. YMMV.
>
> Okay, so how about something like the following, would that be more acceptable?
> Suggestion:
> 
>         String[] tokens = Collections.list(new StringTokenizer(line, " \t")).toArray(new String[0]);

`StringTokenizer()` is a legacy class and is discouraged in new code. So not ideal either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14216#discussion_r1219542380

From jlaskey at openjdk.org  Tue Jun  6 12:46:52 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 6 Jun 2023 12:46:52 GMT
Subject: RFR: JDK-8309534 @JEP(number=430,
 title="String Templates") should use default status
Message-ID: <WTnnQOrtKMUK70PZM6fLkZrRJb_3YBXubD3ZF24DnSU=.32899959-47c9-48aa-8d9d-c0a8270084a1@github.com>

Status was incorrectly specified as 

@JEP(number=430, title="String Templates", status="First Preview") 

Should be 

@JEP(number=430, title="String Templates)

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

Commit messages:
 - Status incorrectly specified

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

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

From alanb at openjdk.org  Tue Jun  6 12:57:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 12:57:53 GMT
Subject: RFR: JDK-8309534 @JEP(number=430,
 title="String Templates") should use default status
In-Reply-To: <WTnnQOrtKMUK70PZM6fLkZrRJb_3YBXubD3ZF24DnSU=.32899959-47c9-48aa-8d9d-c0a8270084a1@github.com>
References: <WTnnQOrtKMUK70PZM6fLkZrRJb_3YBXubD3ZF24DnSU=.32899959-47c9-48aa-8d9d-c0a8270084a1@github.com>
Message-ID: <G8QK8wNUP-818d36lSVPDZAvvOT9Y-4IlgLitkZXDxU=.f4baac83-f0a9-48de-a8d1-0d96b0b81a22@github.com>

On Tue, 6 Jun 2023 12:39:58 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Status was incorrectly specified as 
> 
> @JEP(number=430, title="String Templates", status="First Preview") 
> 
> Should be 
> 
> @JEP(number=430, title="String Templates)

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14332#pullrequestreview-1465139430

From duke at openjdk.org  Tue Jun  6 13:02:06 2023
From: duke at openjdk.org (Rudi Horn)
Date: Tue, 6 Jun 2023 13:02:06 GMT
Subject: Integrated: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array
In-Reply-To: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
Message-ID: <wZAj1d5eWeFoy6qA3MiTmE02K_LS_VOH2YQOGXTD2PY=.49fb1d53-1d06-455c-be66-5df4f2a0303b@github.com>

On Wed, 24 May 2023 09:24:46 GMT, Rudi Horn <duke at openjdk.org> wrote:

> This change prevents the contents of the internal string array from being copied back when releasing it.

This pull request has now been integrated.

Changeset: 8f0839bc
Author:    Rudi Horn <rudi.horn at oracle.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f0839bc55036a8a663a83a02d300c60e71ceb6c
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8308748: JNU_GetStringPlatformChars may write to String's internal memory array

Reviewed-by: dholmes, rriggs, alanb

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

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

From jlaskey at openjdk.org  Tue Jun  6 13:04:00 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 6 Jun 2023 13:04:00 GMT
Subject: Integrated: JDK-8309534 @JEP(number=430,
 title="String Templates") should use default status
In-Reply-To: <WTnnQOrtKMUK70PZM6fLkZrRJb_3YBXubD3ZF24DnSU=.32899959-47c9-48aa-8d9d-c0a8270084a1@github.com>
References: <WTnnQOrtKMUK70PZM6fLkZrRJb_3YBXubD3ZF24DnSU=.32899959-47c9-48aa-8d9d-c0a8270084a1@github.com>
Message-ID: <wTKhJ9JnzJIWyibLKir29CCX0snqrJ5l1hwDQ0dp5ZY=.b4e802b2-27ec-4166-9a9d-a74231793028@github.com>

On Tue, 6 Jun 2023 12:39:58 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Status was incorrectly specified as 
> 
> @JEP(number=430, title="String Templates", status="First Preview") 
> 
> Should be 
> 
> @JEP(number=430, title="String Templates)

This pull request has now been integrated.

Changeset: ca6f07f9
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca6f07f9ab70d552061a2715342f1227287f2d94
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8309534: @JEP(number=430, title="String Templates") should use default status

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Tue Jun  6 14:20:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 14:20:53 GMT
Subject: RFR: 8301721: lookup.findSpecial fails on Object method call from
 interface
In-Reply-To: <ngx6hmVa6YcVebkWTP90YEw83sBSjzX5CEHZNLpZ1aQ=.f0365180-b052-4126-85a3-5d16028f32bc@github.com>
References: <ngx6hmVa6YcVebkWTP90YEw83sBSjzX5CEHZNLpZ1aQ=.f0365180-b052-4126-85a3-5d16028f32bc@github.com>
Message-ID: <LjqRoeP2Iy9lSiaR_RC9kDCipgMixlbruQ9b06-NJks=.306bbb96-8a7f-4d34-bde1-dddd559e96ed@github.com>

On Mon, 5 Jun 2023 19:33:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Lookup.findSpecial fails on Object method call from an interface because of a bug in the implementation calling `Class::getSuperclass` on an interface which has no superclass.   The implementation should only search the method from its superclass only if it's a class.   This patch is trivial and skip the superclass search if it's an interface.

This looks right, there's no superclass to search.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14319#pullrequestreview-1465328491

From jvernee at openjdk.org  Tue Jun  6 15:17:26 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Jun 2023 15:17:26 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v8]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <nXKomj-NnUSghCzYV7on-C0jXdamNoiCW8vv8ZNuy9Q=.33755f7f-c5e6-406f-a809-72fafb9f200f@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains this.
> 
> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
> 
> Testing:
> - local testing on Windows/x64
> - local testing on Linux/x64 using the fallback linker
> - tier1-3 + jdk-tier5
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - Improve javadoc, align implementation
 - Revert "automatically apply variadic promotions"
   
   This reverts commit 38d759d615b79b0c508bdf2231699c0aea0ad94f.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/3ec04fa6..ca56fade

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

  Stats: 202 lines in 7 files changed: 70 ins; 116 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14225/head:pull/14225

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

From jvernee at openjdk.org  Tue Jun  6 15:17:48 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Jun 2023 15:17:48 GMT
Subject: RFR: 8308031: Linkers should promote variadic arguments [v7]
In-Reply-To: <TDPUixLUZqjYbpMf9ypKU0IR4HSogqnlsnPKiXhcIwg=.a594c924-9c07-41dd-bf44-baf944a75d60@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <TDPUixLUZqjYbpMf9ypKU0IR4HSogqnlsnPKiXhcIwg=.a594c924-9c07-41dd-bf44-baf944a75d60@github.com>
Message-ID: <iE0Lg-YP-rYrBj9VYLM0Tm44QTGbQNhiz3Ai6T3-5iQ=.6bc1fb07-525c-4b6e-adbc-5fced1278d24@github.com>

On Fri, 2 Jun 2023 16:22:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains this.
>> 
>> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - local testing on Linux/x64 using the fallback linker
>> - tier1-3 + jdk-tier5
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comment

After more offline discussion we concluded that by applying argument promotions automatically we create an issue for unsigned types. We currently allow an unsigned value to be represented with the signed equivalent. For example, `JAVA_SHORT` can represent both the C `short` and `unsigned short` types. The issue is that if we were to promote `short` values to `int`, it is ambiguous whether sign extension should take place.

As a result, we decided to go back to the approach of rejecting variadic layouts representing a C type that would undergo default argument promotion. If/when we add better support for unsigned types, we can revisit.

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

PR Comment: https://git.openjdk.org/jdk/pull/14225#issuecomment-1578960268

From bpb at openjdk.org  Tue Jun  6 15:19:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 6 Jun 2023 15:19:02 GMT
Subject: Integrated: 8309216: Cast from jchar* to char* in test
 java/io/GetXSpace.java
In-Reply-To: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
References: <2150X7B6eiNJ_bCMRVfINiJcbkU1LKymWKdHz7LjjTA=.2ce227da-bcec-436c-941b-1fc1a21e7a3c@github.com>
Message-ID: <XBcVkOgw4P5-UkbcymA80sjgDKALkni2er8XhidoLHI=.37d65ce1-678e-4715-ae74-7ed046936729@github.com>

On Fri, 2 Jun 2023 00:00:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For Unix, copy the `jchar`s into an allocated `char` array.

This pull request has now been integrated.

Changeset: 91881426
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9188142698d8fdcee43c0b0519fde5c63b0010f8
Stats:     24 lines in 1 file changed: 18 ins; 0 del; 6 mod

8309216: Cast from jchar* to char* in test java/io/GetXSpace.java

Reviewed-by: rriggs, naoto

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

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

From duke at openjdk.org  Tue Jun  6 15:24:12 2023
From: duke at openjdk.org (duke)
Date: Tue, 6 Jun 2023 15:24:12 GMT
Subject: Withdrawn: 8305774: String.join(CharSequence,
 Iterable) can be optimized if Iterable is a Collection
In-Reply-To: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
References: <KnorUcG-lU874W15Zo79oORlKvW4E1Oyf5ogtWsdasY=.d3b6bc7a-573d-4663-aa66-011bc5feb30f@github.com>
Message-ID: <7X4rZP0xrnofRHe8epTrQ5hY_gQ1Hg_fQDSvT87dIpI=.113b82c7-cb07-4a38-908f-62daeb333981@github.com>

On Fri, 7 Apr 2023 08:27:18 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> In the current implementation of `String.join(CharSequence, Iterable)`, the temp array `elems` is always initialized with a length of 8. It will cause many array recreations when the `Iterable` contains more than 8 elements. Furthermore, it's very common that an `Iterable` is also a `Collection`. So if the `Iterable` is an instance of `Collection`, the initial length of the array can be `((Collection<?>)elements).size()`. It will not change the current behavior even if the `Collection` is modified asynchronously.
> 
> I don't know whether this change requires a CSR request.

This pull request has been closed without being integrated.

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

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

From jwaters at openjdk.org  Tue Jun  6 15:36:57 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Jun 2023 15:36:57 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <fSmXqAalXkTcaUM-z0su0bQU-GtFIdKjPWplUQaWfXk=.8ae45ca6-6d0f-40c0-b27a-63034f4289c3@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1578995624

From jwaters at openjdk.org  Tue Jun  6 15:37:00 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Jun 2023 15:37:00 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <lc5jVajW_m2sFNWLyspQPgPHIzmU9vgzuH9gKmpSCys=.98210314-df7b-4179-a71d-5c5aeedd0c52@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1578994674

From aturbanov at openjdk.org  Tue Jun  6 15:47:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 6 Jun 2023 15:47:54 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll()
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <VLuPocE-b60CBbAm8_gIHmG3CkjmAHS6S-gvFrwH6JE=.e45fb3d4-dc18-47aa-b6cc-e8a6a4d08ac3@github.com>

On Mon, 5 Jun 2023 18:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 408:

> 406:      * variety of processors, numbers of CPUs, and OSes.
> 407:      */
> 408:     private static final int FRONT_SPINS   = 1 << 7;

nit
Suggestion:

    private static final int FRONT_SPINS = 1 << 7;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1219891442

From never at openjdk.org  Tue Jun  6 15:57:05 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 6 Jun 2023 15:57:05 GMT
Subject: Integrated: 8309501: Remove workaround in bin/idea.sh for non standard
 JVMCI file layout
In-Reply-To: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>
References: <7xLLhe3TF96ZnkpiOiAm6Km8T3mV1sd26SPHGTPBp7I=.8b884a99-aeae-47f6-b211-b5fc4ca11a8e@github.com>
Message-ID: <jiyV1SYqcMTqnLOw_w3wL4XezCtjvUIbHTXFaSR0IxI=.d3875701-2024-4ce6-9985-9871bf5339e7@github.com>

On Mon, 5 Jun 2023 19:12:52 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This allows bin/idea.sh to properly see the JVMCI files again.

This pull request has now been integrated.

Changeset: 7edd0540
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7edd0540e06444313647acd133c230785ddaf8ee
Stats:     12 lines in 1 file changed: 0 ins; 10 del; 2 mod

8309501: Remove workaround in bin/idea.sh for non standard JVMCI file layout

Reviewed-by: dnsimon, erikj

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

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

From liach at openjdk.org  Tue Jun  6 16:00:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 16:00:11 GMT
Subject: Integrated: 8309413: Improve the performance of
 MethodTypeDesc::descriptorString
In-Reply-To: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
Message-ID: <wvc0qK9oOOa-l2bFibeWN4WkSHH9QCZPYdjiMAQQiDg=.6ffa38b8-fc0f-4317-b1ff-fd9ff7714ad4@github.com>

On Sun, 26 Mar 2023 05:23:54 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
> 
> 
> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op

This pull request has now been integrated.

Changeset: 38cef2ad
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38cef2adbd956ac1e953ea7a7e7952fe093a9872
Stats:     283 lines in 4 files changed: 198 ins; 44 del; 41 mod

8309413: Improve the performance of MethodTypeDesc::descriptorString
8304932: MethodTypeDescImpl can be mutated by argument passed to MethodTypeDesc.of

Reviewed-by: mchung

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

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

From mchung at openjdk.org  Tue Jun  6 16:23:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 6 Jun 2023 16:23:06 GMT
Subject: Integrated: 8301721: lookup.findSpecial fails on Object method call
 from interface
In-Reply-To: <ngx6hmVa6YcVebkWTP90YEw83sBSjzX5CEHZNLpZ1aQ=.f0365180-b052-4126-85a3-5d16028f32bc@github.com>
References: <ngx6hmVa6YcVebkWTP90YEw83sBSjzX5CEHZNLpZ1aQ=.f0365180-b052-4126-85a3-5d16028f32bc@github.com>
Message-ID: <l2ruU_oR573F8TCN3O6x4SjoXc6rZrWF_N7_kDGX--M=.d807270c-aa21-48e2-91af-1e1c92b0aa02@github.com>

On Mon, 5 Jun 2023 19:33:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Lookup.findSpecial fails on Object method call from an interface because of a bug in the implementation calling `Class::getSuperclass` on an interface which has no superclass.   The implementation should only search the method from its superclass only if it's a class.   This patch is trivial and skip the superclass search if it's an interface.

This pull request has now been integrated.

Changeset: 74dc50b7
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74dc50b7f0b0b9440746ff329fc3324c477ae421
Stats:     80 lines in 2 files changed: 79 ins; 0 del; 1 mod

8301721: lookup.findSpecial fails on Object method call from interface

Reviewed-by: alanb

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

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

From mcimadamore at openjdk.org  Tue Jun  6 16:27:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 Jun 2023 16:27:44 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v8]
In-Reply-To: <nXKomj-NnUSghCzYV7on-C0jXdamNoiCW8vv8ZNuy9Q=.33755f7f-c5e6-406f-a809-72fafb9f200f@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <nXKomj-NnUSghCzYV7on-C0jXdamNoiCW8vv8ZNuy9Q=.33755f7f-c5e6-406f-a809-72fafb9f200f@github.com>
Message-ID: <W37sUZeFCPzgaL0VtsJjiKMTJRrxesmV8tkIsI54cKQ=.2d0a6850-39c3-400d-8446-a88067677216@github.com>

On Tue, 6 Jun 2023 15:17:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains this.
>> 
>> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - local testing on Linux/x64 using the fallback linker
>> - tier1-3 + jdk-tier5
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve javadoc, align implementation
>  - Revert "automatically apply variadic promotions"
>    
>    This reverts commit 38d759d615b79b0c508bdf2231699c0aea0ad94f.

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14225#pullrequestreview-1465598652

From jiangli at openjdk.org  Tue Jun  6 16:28:59 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 6 Jun 2023 16:28:59 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v5]
In-Reply-To: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
Message-ID: <4U4zG-gKBcankqMtYc3p1EEuHrQ-_AvyS6J_P4Gww50=.88fd8d13-3f4f-46d6-9049-4371a3755bb1@github.com>

On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make/common/NativeCompilation.gmk
>>   
>>   Thanks you!
>>   
>>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in.
> 
> 
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
> [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed
> [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1

Thanks for running tests!!

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

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1555291522

From liach at openjdk.org  Tue Jun  6 16:32:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 16:32:47 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v6]
In-Reply-To: <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <lLcLf7p-fgSZpyEiXweXxoZF_J1S9Hu9O2FjjkzAkbc=.3fdf7c8b-abae-4b39-b707-d70209ad6530@github.com>
Message-ID: <Oc0rZci-ZKYId_Z0AaLRbh8pk9nZJcGS4f8lUiiNK5Q=.992eaba1-c810-4ba6-ba28-318730cb6c20@github.com>

On Thu, 6 Apr 2023 03:44:07 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> 
>> Benchmark                                                          Mode  Cnt      Score      Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
>> MethodHandleProxiesAsIFInstanceCreat...
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace, cleanup, rename benchmarks to be informative

@JornVernee Thanks for your review! Updated per your comments and refined the benchmark as well.

> I think the call benchmark could be fleshed out a bit more as well. It would be interesting to see these cases:
> 1. direct call to `doWork` (this would be the baseline)
> 2. call through non-constant method handle
> 3. call through non-constant interface instance created with lambda (existing `lambdaCall`)
> 4. call through non-constant interface instance created with MHP::asInterfaceInstance (existing `testCall`)
> 5. call through constant (`static final`) method handle
> 6. call through constant (`static final`) interface instance created with lambda
> 7. call through constant (`static final`) interface instance created with MHP::asInterfaceInstance

Here's the latest benchmark results: 

Benchmark                                                          Mode  Cnt      Score      Error  Units
MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.609 ?    0.290  ns/op
MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.952 ?    0.014  ns/op
MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      0.411 ?    0.005  ns/op
MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.408 ?    0.002  ns/op
MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.260 ?    0.005  ns/op
MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.259 ?    0.004  ns/op
MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.260 ?    0.007  ns/op
MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.257 ?    0.004  ns/op
MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.256 ?    0.003  ns/op
MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15  22033.536 ? 3300.920  ns/op
MethodHandleProxiesAsIFInstanceCreate.createCallLambda             avgt   15  20081.732 ? 4523.516  ns/op
MethodHandleProxiesAsIFInstanceCreate.createInterfaceInstance      avgt   15  18523.812 ? 2585.683  ns/op
MethodHandleProxiesAsIFInstanceCreate.createLambda                 avgt   15  19206.093 ? 4743.297  ns/op


1. call through constant all has similar performance as direct call
2. call through non-constant method handle is significantly slower over than others, as anticipated
3. call through non-constant interface instance created with lambda, MHP::asInterfaceInstance and anonymous class instance (Doable) have similar performance

@DasBrain Thanks for the recommendation to test with SecurityManager, added a test and found two places that needs to do privileged indeed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1498450131

From xliu at openjdk.org  Tue Jun  6 16:34:06 2023
From: xliu at openjdk.org (Xin Liu)
Date: Tue, 6 Jun 2023 16:34:06 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <ou3RCRT_KKIJhx5-7s2OWtEca-lQX_DEoFo9a_dPVTc=.16fcb2b8-b304-4d60-b596-066afe52aa30@github.com>

On Wed, 6 Apr 2022 17:47:53 GMT, Chris Hennick <duke at openjdk.org> wrote:

> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.

@Pr0methean is an employee of Amazon.

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

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1090965245

From simonis at openjdk.org  Tue Jun  6 16:34:06 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 6 Jun 2023 16:34:06 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <IxWJDOzmZIJYT95bSA78qId318wVAxk_J0GWgYUaTBc=.74fb3d08-70f6-4d8f-9dad-a25300964c5b@github.com>

On Wed, 6 Apr 2022 17:47:53 GMT, Chris Hennick <duke at openjdk.org> wrote:

> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.

@robilad, can you please verify Chris Hennick's (@Pr0methean) OCA status?
He's an Amazon employee and covered by Amazons OCA.

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

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1099080229

From liach at openjdk.org  Tue Jun  6 16:35:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 16:35:02 GMT
Subject: RFR: 8309413: Improve the performance of
 MethodTypeDesc::descriptorString [v2]
In-Reply-To: <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <xrT2u2IywBEi6VgzUMg55wQg5ft3lhhsCn-EBipdzAI=.43c4bb6b-2836-4eff-a47a-9656b56cfedf@github.com>
Message-ID: <zHVX9Qz5eJU_1dcU7LGi9TqjwpLTL3EeThVfspy6tWo=.6ba6da28-5579-4cef-b6c2-f3ba3a8e1056@github.com>

On Sun, 26 Mar 2023 20:45:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to improve the performance of MethodTypeDesc in general, as it is currently a performance bottleneck in the Classfile API. A previous revision changed the parameter storage from an array to a list; this is dropped now. Sorry for the force push.
>> 
>> 
>> Benchmark                                                             (descString)  Mode  Cnt    Score   Error  Units
>> MethodTypeDescFactories.descriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   27.778 ? 0.573  ns/op
>> MethodTypeDescFactories.descriptorString                                       ()V  avgt    6   13.343 ? 0.235  ns/op
>> MethodTypeDescFactories.descriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   40.828 ? 0.448  ns/op
>> MethodTypeDescFactories.descriptorString                     ()[Ljava/lang/String;  avgt    6   14.754 ? 0.162  ns/op
>> MethodTypeDescFactories.ofArray            (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    8.616 ? 0.132  ns/op
>> MethodTypeDescFactories.ofArray                                                ()V  avgt    6    2.146 ? 0.293  ns/op
>> MethodTypeDescFactories.ofArray           ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   14.595 ? 0.235  ns/op
>> MethodTypeDescFactories.ofArray                              ()[Ljava/lang/String;  avgt    6    2.064 ? 0.085  ns/op
>> MethodTypeDescFactories.ofDescriptor       (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6   97.077 ? 2.482  ns/op
>> MethodTypeDescFactories.ofDescriptor                                           ()V  avgt    6   13.563 ? 0.111  ns/op
>> MethodTypeDescFactories.ofDescriptor      ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6  130.543 ? 2.847  ns/op
>> MethodTypeDescFactories.ofDescriptor                         ()[Ljava/lang/String;  avgt    6   35.286 ? 0.260  ns/op
>> MethodTypeDescFactories.ofList             (Ljava/lang/Object;Ljava/lang/String;)I  avgt    6    4.156 ? 0.258  ns/op
>> MethodTypeDescFactories.ofList                                                 ()V  avgt    6    2.192 ? 0.063  ns/op
>> MethodTypeDescFactories.ofList            ([IJLjava/lang/String;Z)Ljava/util/List;  avgt    6   41.002 ? 0.235  ns/op
>> MethodTypeDescFactories.ofList                               ()[Ljava/lang/String;  avgt    6    2.200 ? 0.041  ns/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some inconsistencies in the method descriptor derivation methods

Moved this patch to another issue that focus on converting the storage from array to immutable list. The fix for mutation is now a side effect of this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1522789129

From smarks at openjdk.org  Tue Jun  6 16:49:39 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 6 Jun 2023 16:49:39 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <hzkKoDYYnU05Jre-XHcijpsfAZ52PsC_CG1AB8Pf6Ow=.9932a45c-eb9c-4ef0-ba49-54bdb88dcd92@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
 <hzkKoDYYnU05Jre-XHcijpsfAZ52PsC_CG1AB8Pf6Ow=.9932a45c-eb9c-4ef0-ba49-54bdb88dcd92@github.com>
Message-ID: <-F6HytMIA0fBCP2R4Ag3sCQEF8KVfnB18nXflbuiPYg=.14f0e965-5c53-47f3-91a6-a995d824a1f2@github.com>

On Tue, 6 Jun 2023 04:58:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.
>
> src/java.base/share/classes/java/util/AbstractMap.java line 908:
> 
>> 906:         public boolean add(E t) { throw uoe(); }
>> 907:         public boolean addAll(Collection<? extends E> c) { throw uoe(); }
>> 908:         public void clear() { view().clear(); }
> 
> Each of these methods should perhaps have the `@Override` to make it clear that these correspond to the interface this class is implementing. But I see that the `AbstractMap` class itself doesn't use `@Override` anywhere, so I think it's OK to keep it consistent in its current form in this PR.

Yeah the collections classes are inconsistent about using `@Override`. Some maintainers (Martin Buchholz, Doug Lea) prefer not to use it at all. However, some usage has crept in from time to time. Personally I tend not to use it, as I think it adds a lot of clutter and doesn't provide much value. The main value this annotation provides detecting an incorrectly declared override (e.g., declaring an equals(Foo) method instead of equals(Object) method). In practice this doesn't seem to happen. These skeletons of these internal collection classes are usually auto-generated by an IDE, which won't make this mistake. The collections are usually pretty well tested so if something isn't overridden properly it will usually be caught.

I'm considering ripping out all occurrences of `@Override` from collections and declaring the prevailing style not to use it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14267#discussion_r1219984529

From jvernee at openjdk.org  Tue Jun  6 17:01:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Jun 2023 17:01:25 GMT
Subject: RFR: 8308445: Linker should check that capture state segment is big
 enough
Message-ID: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>

Fix the bug mentioned in the JBS issue.

The implementation is updated to slice the capture state segment using the capture state layout. This checks both that the segment is big enough, and that it is properly aligned.

Additionally, I added a check for `MS::NULL` since this is also an illegal value we can catch early.

Test cases are added for all three invalid values.

Testing: `jdk_foreign` test suite.

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

Commit messages:
 - Apply checks on capture state segment

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

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

From smarks at openjdk.org  Tue Jun  6 17:05:40 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 6 Jun 2023 17:05:40 GMT
Subject: Integrated: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
Message-ID: <Z44IMs3uZib5x3v4ucGvpQwE7ROiBRS65shO_zKmyQA=.3b404338-2882-49f3-bb6e-dfda720bcd5c@github.com>

On Thu, 1 Jun 2023 16:18:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.

This pull request has now been integrated.

Changeset: 95261908
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/952619086358326c2fb3fcbada654fc2edd09f07
Stats:     113 lines in 3 files changed: 64 ins; 3 del; 46 mod

8307840: SequencedMap view method specification and implementation adjustments

Reviewed-by: darcy, alanb

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

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

From smarks at openjdk.org  Tue Jun  6 17:05:38 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 6 Jun 2023 17:05:38 GMT
Subject: RFR: 8307840: SequencedMap view method specification and
 implementation adjustments
In-Reply-To: <98fLhdNGS8lR2zjfCGVclbqpuizh5Bh2-F9_sBM_dwE=.a3ac2d37-219a-456e-8063-0c15fe460ecd@github.com>
References: <yTMYsyPtgWaLuAYja2qo2QBnp4UI3OVLMZy6sDa-V_A=.ab856126-ba71-4622-b776-a22e4a91dc97@github.com>
 <98fLhdNGS8lR2zjfCGVclbqpuizh5Bh2-F9_sBM_dwE=.a3ac2d37-219a-456e-8063-0c15fe460ecd@github.com>
Message-ID: <NqiNN5lAxotnhs6UZzcew3XH2W17vMdyCitaLkrDKeU=.586f5906-0245-4132-a338-f17dc085ae9a@github.com>

On Tue, 6 Jun 2023 04:55:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Adjust the specification of the `SequencedMap` sequenced-view methods, and adjust implementations to match.
>
> src/java.base/share/classes/java/util/SequencedMap.java line 268:
> 
>> 266:      * Its {@link SequencedSet#reversed reversed} method returns the {@link
>> 267:      * #sequencedKeySet sequencedKeySet} view of the {@link #reversed reversed} view of
>> 268:      * this map. Each of its other methods calls the corresponding method of the {@link
> 
> Hello Stuart, should this (and other similar places in this PR) instead be:
> 
> Each of its other methods call
> 
> call instead of calls?

"Each" is usually considered singular so "Each ... calls" is proper. It looks weird though since the plural "methods" is right next to "calls."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14267#discussion_r1220010473

From darcy at openjdk.org  Tue Jun  6 17:15:34 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 17:15:34 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v4]
In-Reply-To: <h23-TxkloW1vKVfOftTi6eWXd2v0QVNgYW3vwHYEOsU=.928067cd-f484-4c82-a7bb-c77813df186c@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <VFhogcP_Pc4FAVNTsb6b30yUNQSRifwO2zv9xYwJcUA=.be9d1d6b-72f8-4b43-a9ba-0be263f34c43@github.com>
 <TSnNZk500Glws9SBoIQBPOJs0AIJoxE1JNKi7WEVdDk=.2dee2277-a554-4941-8c55-f9762995e33b@github.com>
 <mYCrZ-f5CXsPCZIOUDSvBEXsDUVgaaPyAcvJfjAvxtk=.8f967e7c-7038-40ea-a80e-bf84bfd074cc@github.com>
 <MZ3-dAAGpVj_oPJ5VR5Y00kTK97PEhIHlKf2nbT60E4=.19c43172-7d04-4412-8815-b1d522ca951c@github.com>
 <erOlNd7RKExeGwKNcczF9Vg98vYcQugqrWiufwu0HTw=.5aa67c8a-b4a8-460e-aec1-13e4ef118069@github.com>
 <h23-TxkloW1vKVfOftTi6eWXd2v0QVNgYW3vwHYEOsU=.928067cd-f484-4c82-a7bb-c77813df186c@github.com>
Message-ID: <WML-yHTv9V7hhzBwYpp9FeV67MIqvhHSUMqdQI7fKaE=.b38c9518-7f8d-4c97-98a9-513b5397a1e4@github.com>

On Tue, 6 Jun 2023 08:41:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > "Latest Java class file format version recognized by the Java runtime as "MAJOR.MINOR" where MAJOR and MINOR are both formatted as decimal integers"
> 
> Okay, and linking to ClassFileFormatVersion.latest() is good.
> 
> Again, just to lobby for putting an adjective into the ClassFileFormatVersion.RELEASE_XX descriptions to make it clearer than the value is the latest version recognized rather than single version that the wording currently suggests.

Okay, for the constants for 1.2 and later, I switched to "The version introduced by...".

The 1.0.2 and 1.1 versions of the platform use the same class file format version.

Explanatory apiNote for ClassFileFormatVersion also added.

I don't think those are spec changes per se, so I didn't update the CSR to include them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14305#discussion_r1220026016

From darcy at openjdk.org  Tue Jun  6 17:15:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 17:15:32 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v4]
In-Reply-To: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
Message-ID: <L8nwf5f7YpQb5D5i6gG0Q-Zd03S8tDb6RTV853H_cUA=.9bc95d8a-e870-4f2b-a3bc-3c8369cd9072@github.com>

> Document existing behavior.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415

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:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8295071
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8295071
 - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14305/files
  - new: https://git.openjdk.org/jdk/pull/14305/files/33bb646b..018a5dc2

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

  Stats: 1867 lines in 57 files changed: 1607 ins; 39 del; 221 mod
  Patch: https://git.openjdk.org/jdk/pull/14305.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14305/head:pull/14305

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

From psandoz at openjdk.org  Tue Jun  6 17:16:36 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 6 Jun 2023 17:16:36 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v5]
In-Reply-To: <Sb-ExPhDtN54QLKJxfoNEIEfF9rn6ixQlsD_QVtF0Dk=.f4fc7b17-8f8d-4ae3-b350-bbd36a5dd695@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <Sb-ExPhDtN54QLKJxfoNEIEfF9rn6ixQlsD_QVtF0Dk=.f4fc7b17-8f8d-4ae3-b350-bbd36a5dd695@github.com>
Message-ID: <pQDSY9_dhPJb7rxhMerpFNMhXvlKuOW_2jHP55dj28c=.c17523a2-899c-4446-b05b-d281af98c3cb@github.com>

On Tue, 6 Jun 2023 07:13:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Fix typo in javadoc
>  - Merge
>  - Merge
>  - Sync up from loom repo
>  - Merge
>  - Sync with loom repo, re-work ScopedValue class description
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/2e9eff56...0f514588

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13932#pullrequestreview-1465700542

From mcimadamore at openjdk.org  Tue Jun  6 17:18:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 6 Jun 2023 17:18:44 GMT
Subject: RFR: 8308445: Linker should check that capture state segment is
 big enough
In-Reply-To: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
References: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
Message-ID: <HsH7LU8a6tyO78_-hViJ7gthVO6s9Wh0EpmTIcI_S0A=.102747ee-0162-4ada-929d-3068c66c3864@github.com>

On Tue, 6 Jun 2023 16:22:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Fix the bug mentioned in the JBS issue.
> 
> The implementation is updated to slice the capture state segment using the capture state layout. This checks both that the segment is big enough, and that it is properly aligned.
> 
> Additionally, I added a check for `MS::NULL` since this is also an illegal value we can catch early.
> 
> Test cases are added for all three invalid values.
> 
> Testing: `jdk_foreign` test suite.

Looks good

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 114:

> 112:             MH_CHECK_SYMBOL = lookup.findStatic(SharedUtils.class, "checkSymbol",
> 113:                     methodType(void.class, MemorySegment.class));
> 114:             MH_SLICE_CAPTURE_SEGMENT = lookup.findStatic(SharedUtils.class, "checkCaptureSegment",

Is the name of the field correct?

test/jdk/java/foreign/capturecallstate/TestCaptureCallState.java line 152:

> 150:             {Arena.ofAuto().allocate(1), IndexOutOfBoundsException.class, ".*Out of bound access on segment.*"},
> 151:             {MemorySegment.NULL, IllegalArgumentException.class, ".*Capture segment is NULL.*"},
> 152:             {Arena.ofAuto().allocate(Linker.Option.captureStateLayout().byteSize() + 3).asSlice(3), // misaligned

This last one is very nice!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14339#pullrequestreview-1465703809
PR Review Comment: https://git.openjdk.org/jdk/pull/14339#discussion_r1220030249
PR Review Comment: https://git.openjdk.org/jdk/pull/14339#discussion_r1220033212

From jvernee at openjdk.org  Tue Jun  6 17:18:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Jun 2023 17:18:45 GMT
Subject: RFR: 8308445: Linker should check that capture state segment is
 big enough
In-Reply-To: <HsH7LU8a6tyO78_-hViJ7gthVO6s9Wh0EpmTIcI_S0A=.102747ee-0162-4ada-929d-3068c66c3864@github.com>
References: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
 <HsH7LU8a6tyO78_-hViJ7gthVO6s9Wh0EpmTIcI_S0A=.102747ee-0162-4ada-929d-3068c66c3864@github.com>
Message-ID: <73Xv-7x2cHmxM5vnIuVkIRNr4evVgh0Xf0nzz7i1pS4=.b7f221dc-b4a7-4549-a33f-556248c27396@github.com>

On Tue, 6 Jun 2023 17:13:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Fix the bug mentioned in the JBS issue.
>> 
>> The implementation is updated to slice the capture state segment using the capture state layout. This checks both that the segment is big enough, and that it is properly aligned.
>> 
>> Additionally, I added a check for `MS::NULL` since this is also an illegal value we can catch early.
>> 
>> Test cases are added for all three invalid values.
>> 
>> Testing: `jdk_foreign` test suite.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 114:
> 
>> 112:             MH_CHECK_SYMBOL = lookup.findStatic(SharedUtils.class, "checkSymbol",
>> 113:                     methodType(void.class, MemorySegment.class));
>> 114:             MH_SLICE_CAPTURE_SEGMENT = lookup.findStatic(SharedUtils.class, "checkCaptureSegment",
> 
> Is the name of the field correct?

That's a leftover from an earlier version, will fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14339#discussion_r1220031575

From jvernee at openjdk.org  Tue Jun  6 17:24:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 6 Jun 2023 17:24:34 GMT
Subject: RFR: 8308445: Linker should check that capture state segment is
 big enough [v2]
In-Reply-To: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
References: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
Message-ID: <hASGyxtMmx-nKQeGaJ-uAokCKn-hrqifRnI-RJig9Bc=.9f3d385e-50b4-40c2-9878-e643791beda7@github.com>

> Fix the bug mentioned in the JBS issue.
> 
> The implementation is updated to slice the capture state segment using the capture state layout. This checks both that the segment is big enough, and that it is properly aligned.
> 
> Additionally, I added a check for `MS::NULL` since this is also an illegal value we can catch early.
> 
> Test cases are added for all three invalid values.
> 
> Testing: `jdk_foreign` test suite.

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

  rename MH field

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14339/files
  - new: https://git.openjdk.org/jdk/pull/14339/files/ccc35e63..9200f57f

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

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

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

From asemenov at openjdk.org  Tue Jun  6 17:35:34 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 6 Jun 2023 17:35:34 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
Message-ID: <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>

On Thu, 1 Jun 2023 15:04:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> done
>
> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.

This is rarely used in the code and is not the essence of the current changes.
If you introduce such changes, then throughout the code.
Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220056527

From weijun at openjdk.org  Tue Jun  6 17:50:00 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jun 2023 17:50:00 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
 <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
Message-ID: <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>

On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.
>
> This is rarely used in the code and is not the essence of the current changes.
> If you introduce such changes, then throughout the code.
> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225

I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220071779

From alanb at openjdk.org  Tue Jun  6 18:25:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 18:25:57 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v4]
In-Reply-To: <L8nwf5f7YpQb5D5i6gG0Q-Zd03S8tDb6RTV853H_cUA=.9bc95d8a-e870-4f2b-a3bc-3c8369cd9072@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <L8nwf5f7YpQb5D5i6gG0Q-Zd03S8tDb6RTV853H_cUA=.9bc95d8a-e870-4f2b-a3bc-3c8369cd9072@github.com>
Message-ID: <f099LenlEIfXcgTeMuZ4Z_DKBiv7ztUyeRO9iubRtUs=.dba5c496-28f4-4b10-adc5-cf09ee45c29c@github.com>

On Tue, 6 Jun 2023 17:15:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Document existing behavior.
>> 
>> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415
>
> 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:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8295071
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8295071
>  - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14305#pullrequestreview-1465816431

From rriggs at openjdk.org  Tue Jun  6 18:28:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 6 Jun 2023 18:28:57 GMT
Subject: RFR: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number [v4]
In-Reply-To: <L8nwf5f7YpQb5D5i6gG0Q-Zd03S8tDb6RTV853H_cUA=.9bc95d8a-e870-4f2b-a3bc-3c8369cd9072@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
 <L8nwf5f7YpQb5D5i6gG0Q-Zd03S8tDb6RTV853H_cUA=.9bc95d8a-e870-4f2b-a3bc-3c8369cd9072@github.com>
Message-ID: <dJO-qzmS3PnQGxk2NSYEVnhvczUVV6ilPaIedwEgHk4=.ea4926fe-fb07-4445-85ce-1302221da339@github.com>

On Tue, 6 Jun 2023 17:15:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Document existing behavior.
>> 
>> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415
>
> 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:
> 
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8295071
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8295071
>  - JDK-8309415: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number

The updated descriptions of major and minor look good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14305#pullrequestreview-1465821521

From darcy at openjdk.org  Tue Jun  6 18:37:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 6 Jun 2023 18:37:04 GMT
Subject: Integrated: JDK-8295071: Spec Clarification : ClassFileFormatVersion:
 System property java.class.version | Java class format version number
In-Reply-To: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
References: <Q_4fuoHx1kW-wIpw228W0NLdHKM3G3gPBHeQj-2tlEQ=.7b06c8fa-b9a4-4cc6-9380-f59ff3543be3@github.com>
Message-ID: <4rvM3xehe3wZ4xAOW2b1CZnZsB5a0iCf13QFCof9Re8=.5325bb0b-f7a7-4328-9c6c-a417b3d676ac@github.com>

On Mon, 5 Jun 2023 01:11:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Document existing behavior.
> 
> Please also review the CSR https://bugs.openjdk.org/browse/JDK-8309415

This pull request has now been integrated.

Changeset: d82436e4
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d82436e4e33a33b1a2ea5ad01c7370ccaf4eb2c5
Stats:     31 lines in 2 files changed: 10 ins; 0 del; 21 mod

8295071: Spec Clarification : ClassFileFormatVersion: System property java.class.version | Java class format version number

Reviewed-by: iris, alanb, rriggs

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

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

From jrose at openjdk.org  Tue Jun  6 18:51:00 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 6 Jun 2023 18:51:00 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
 <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
Message-ID: <cg-mJd32zg9bo8hVUMYAzXynunyy5MwGXkAfcMPACa0=.0879793a-078f-44c6-a279-bbec432802a8@github.com>

On Tue, 6 Jun 2023 18:45:50 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.
>> 
>> That's why I didn't use `Reference.reachabilityFence(locale)`.
>
> This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.

It appears you are assuming that some combination of bytecodes constitutes a  critical section that excludes the GC.  But the JVMS makes no guarantees about GC exclusion across bytecodes.

A thread can be pre-empted at any bytecode (even in the middle of a bytecode).  Another thread can trigger a GC.  Maybe the first thread will be rolled forward to a place convenient to the JVM, but you cannot predict what that will be, because the JVMS does not give you any contract about that matter.

For example, some JITs deoptimize (branch to the interpreter) at unpredictable points for reasons no Java programmer should ever think about (because it?s not in the JVMS contract).  Deoptimizing can allocate storage (for example, to materialize objects whose allocation was deferred by escape analysis).  Thus, it is not safe to assume that any particular bytecode is immune from GC.

Also, some JITs (like C2) inject synthetic safepoints injected as part of arbitrarily complex loop transformations.  A GC at such a safepoint might possibly appear to be tied to a bytecode which is simply a fall-through from a previous bytecode.  This can happen if the loop is rotated, and a fallthrough point begins to function as a back-branch in the IR.

The rule of thumb for non-JIT engineers is, if you find yourself trying to predict what how ?the JIT must work?, stop.

The net of this is that, if you need to preserve an object across a critical section, don?t try to read the JIT?s mind or expect it to read yours.  Put in a reachability fence that spans that critical section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220148743

From eosterlund at openjdk.org  Tue Jun  6 18:50:59 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 6 Jun 2023 18:50:59 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
Message-ID: <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>

On Tue, 6 Jun 2023 02:31:19 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> I still don't see a clear explanation of how the proposed patch fixes the problem. Also, I would appreciate the reasoning in the comments.
>
> For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.
> 
> That's why I didn't use `Reference.reachabilityFence(locale)`.

This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220145376

From psandoz at openjdk.org  Tue Jun  6 21:32:59 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 6 Jun 2023 21:32:59 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
Message-ID: <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>

On Fri, 2 Jun 2023 19:09:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > I wonder if it is possible to transition from an lazy (indirect) VH to a direct VH once initialized i.e., `checkAccessModeThenIsDirect` returns the value of `initialized`.
> 
> Sounds a good idea. Once the class is initialized, the lazy VH becomes a direct VH that may help the performance. In that case, the VarHandleGuards would need to ensure it links with the direct VH not the lazy VH.

I believe instead of changing the guards we can change the implementation of the static methods on the concrete static VHs to call `asDirect()` (lets also add `@ForceInline` on `asDirect`), since `linkToStatic` will pass the args to the static method described by the member name (since the lazy and direct VH handles share the same var form).

That has the nice effect of pushing the complexity closer to where it is needed. Its subtle but i think can be explained. Thereby we can reduce the memory footprint for subsequent access modes. Perhaps we can even "zero" out the MH cache on initialization?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1579476316

From liach at openjdk.org  Tue Jun  6 22:37:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 22:37:59 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
Message-ID: <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>

On Tue, 6 Jun 2023 21:29:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I believe instead of changing the guards we can change the implementation of the static methods on the concrete static VHs to call `asDirect()` (lets also add `@ForceInline` on `asDirect`), since `linkToStatic` will pass the args to the static method described by the member name (since the lazy and direct VH handles share the same var form).
> 
> That has the nice effect of pushing the complexity closer to where it is needed. Its subtle but i think can be explained. Thereby we can reduce the memory footprint for subsequent access modes. Perhaps we can even "zero" out the MH cache on initialization?

Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1579550628

From dnsimon at openjdk.org  Tue Jun  6 23:04:55 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 6 Jun 2023 23:04:55 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <1vHZFp-j2AKjYTX2bd_1RxQ2Ix252OCbqJ0m-AGaVTs=.b64ea885-8b22-45ad-8a76-b041a764a5de@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <1vHZFp-j2AKjYTX2bd_1RxQ2Ix252OCbqJ0m-AGaVTs=.b64ea885-8b22-45ad-8a76-b041a764a5de@github.com>
Message-ID: <A1MaJSsrtKufFXQABcH7wL9nFZ1uzhjrxhPd7pmsTMM=.014d97c8-13fd-47be-b508-5c34c7d3ad47@github.com>

On Mon, 5 Jun 2023 18:58:36 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> I don't really love the hard code parsing of the HashMap. What properties are actually required for JVMCI? It seems to me that the contents of Arguments::system_properties() should contain all the properties we want to advertise to JVMCI. That would have avoid having to decode them after they've been converted into Java objects.

I tired this but unfortunately, Graal relies on some properties that are only initialized in Java:

Caused by: java.lang.NullPointerException: Cannot invoke "String.compareTo(String)" because "this.javaSpecVersion" is null
	at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.JVMCIVersionCheck.run(JVMCIVersionCheck.java:181)
	at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.JVMCIVersionCheck.check(JVMCIVersionCheck.java:166)
	at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.initialize(HotSpotGraalCompilerFactory.java:117)
	at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.ensureInitialized(HotSpotGraalCompilerFactory.java:90)
	at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:180)
	at jdk.internal.vm.compiler/org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.createCompiler(HotSpotGraalCompilerFactory.java:53)
	at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.getCompiler(HotSpotJVMCIRuntime.java:810)
	at org.graalvm.nativeimage.pointsto/com.oracle.graal.pointsto.util.GraalAccess.<clinit>(GraalAccess.java:50)


That code is reading the "java.specification.version" property which is initialized in `java.lang.VersionProps#init`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14291#issuecomment-1579573072

From psandoz at openjdk.org  Wed Jun  7 00:13:56 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 7 Jun 2023 00:13:56 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
 <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
Message-ID: <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>

On Tue, 6 Jun 2023 22:34:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.

It aims to reduce the cost of getting to peak performance (the work that C2 has to perform) and reduce the overall memory footprint of such VHs (as long as the user does not explicitly request MHs from them). Assuming of course that the peak performance is good!

For this pattern i not sure we need to create another method returning the target that effectively does the same as `asDirect`, and instead it may come down to better naming and documentation of the concepts.

There is already a tight coupling between the `LazyInitializingVarHandle` and its target via the sharing of the var forms. Renaming `asDirect` to `target` might do it, and we refine a what a direct handle is to mean the guards just pass along the handle that is given to it, otherwise we use a (lazily created) method handle to its target. Thereby a VH implementation free to switch between indirect and direct and is further free to deal with any implementation specific indirection in its own implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1579631030

From never at openjdk.org  Wed Jun  7 00:15:57 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 7 Jun 2023 00:15:57 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <nI0EHHMJWQ0uXzzNlYWx6gguW7tnoLhVQ2o-3hcYTuM=.f9bf2f31-ba1e-440e-9347-67d544ba9271@github.com>

On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real  ...

HotSpot sets `java.vm.specification.version` which has the same value so we could change Graal to read that instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/14291#issuecomment-1579632648

From duke at openjdk.org  Wed Jun  7 01:53:04 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 7 Jun 2023 01:53:04 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v5]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <U1taCulwNbXWrtBOl0e0_vg6FRoBpVjf3j8-2oKx4nU=.161fee89-1551-4849-8f0b-e79c4e6364e2@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

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

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/75fd5951..d133a15c

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

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

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

From smarks at openjdk.org  Wed Jun  7 01:53:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 7 Jun 2023 01:53:05 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <cg-mJd32zg9bo8hVUMYAzXynunyy5MwGXkAfcMPACa0=.0879793a-078f-44c6-a279-bbec432802a8@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
 <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
 <cg-mJd32zg9bo8hVUMYAzXynunyy5MwGXkAfcMPACa0=.0879793a-078f-44c6-a279-bbec432802a8@github.com>
Message-ID: <0SrlLvQQ8ZSU8I8y89VnPDy_DbLtS-_iqYDfiO2yoSM=.06cf5806-221b-47f1-b4f3-4a44655d5e2a@github.com>

On Tue, 6 Jun 2023 18:48:35 GMT, John R Rose <jrose at openjdk.org> wrote:

>> This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.
>
> It appears you are assuming that some combination of bytecodes constitutes a  critical section that excludes the GC.  But the JVMS makes no guarantees about GC exclusion across bytecodes.
> 
> A thread can be pre-empted at any bytecode (even in the middle of a bytecode).  Another thread can trigger a GC.  Maybe the first thread will be rolled forward to a place convenient to the JVM, but you cannot predict what that will be, because the JVMS does not give you any contract about that matter.
> 
> For example, some JITs deoptimize (branch to the interpreter) at unpredictable points for reasons no Java programmer should ever think about (because it?s not in the JVMS contract).  Deoptimizing can allocate storage (for example, to materialize objects whose allocation was deferred by escape analysis).  Thus, it is not safe to assume that any particular bytecode is immune from GC.
> 
> Also, some JITs (like C2) inject synthetic safepoints injected as part of arbitrarily complex loop transformations.  A GC at such a safepoint might possibly appear to be tied to a bytecode which is simply a fall-through from a previous bytecode.  This can happen if the loop is rotated, and a fallthrough point begins to function as a back-branch in the IR.
> 
> The rule of thumb for non-JIT engineers is, if you find yourself trying to predict what how ?the JIT must work?, stop.
> 
> The net of this is that, if you need to preserve an object across a critical section, don?t try to read the JIT?s mind or expect it to read yours.  Put in a reachability fence that spans that critical section.

I don't know what the right fix for this is. If it involves reachabilityFence, then a try-finally statement should be used, with the "critical section" being within the try-clause and the reachabilityFence within the finally-clause.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220682487

From liach at openjdk.org  Wed Jun  7 02:03:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Jun 2023 02:03:41 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v9]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <D2ncFlBtuaTL6yHsU0nYBjgX4DXs1fF1vqslhx5FIFs=.24e6a664-2b26-4b43-adea-8ba5116596db@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> Benchmark                                            Mode  Cnt   Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op

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

 - Merge branch 'master' into lazy-static-varhandle
 - Significantly improve Lazy VH initial call performance
 - Rename asDirect to target
 - Merge branch 'master' into lazy-static-varhandle
 - Improve subsequent VH call performance, thanks exeboss
 - Remove lazy init of MH, for all invocation of the Lazy VH needs this MH
 - Fix withBehavior and test
 - Merge branch 'master' into lazy-static-varhandle
 - Compute base and offset right after linking, simplify code
 - Merge branch 'master' into lazy-static-varhandle
 - ... and 9 more: https://git.openjdk.org/jdk/compare/7c776661...f414e8f8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/dc3e73e9..f414e8f8

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

  Stats: 8687 lines in 195 files changed: 6695 ins; 711 del; 1281 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

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

From liach at openjdk.org  Wed Jun  7 02:03:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Jun 2023 02:03:43 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
 <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
 <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
Message-ID: <gkibxORph6fV2KQ7yBsLNqYHLCoVTfhQ7uWWNveeJXM=.c6962358-a5cf-4e29-b671-2ea744f2bc3a@github.com>

On Wed, 7 Jun 2023 00:10:59 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> I believe instead of changing the guards we can change the implementation of the static methods on the concrete static VHs to call `asDirect()` (lets also add `@ForceInline` on `asDirect`), since `linkToStatic` will pass the args to the static method described by the member name (since the lazy and direct VH handles share the same var form).
>>> 
>>> That has the nice effect of pushing the complexity closer to where it is needed. Its subtle but i think can be explained. Thereby we can reduce the memory footprint for subsequent access modes. Perhaps we can even "zero" out the MH cache on initialization?
>> 
>> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.
>
>> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.
> 
> It aims to reduce the cost of getting to peak performance (the work that C2 has to perform) and reduce the overall memory footprint of such VHs (as long as the user does not explicitly request MHs from them). Assuming of course that the peak performance is good!
> 
> For this pattern i not sure we need to create another method returning the target that effectively does the same as `asDirect`, and instead it may come down to better naming and documentation of the concepts.
> 
> There is already a tight coupling between the `LazyInitializingVarHandle` and its target via the sharing of the var forms. Renaming `asDirect` to `target` might do it, and we refine a what a direct handle is to mean the guards just pass along the handle that is given to it, otherwise we use a (lazily created) method handle to its target. Thereby a VH implementation free to switch between indirect and direct and is further free to deal with any implementation specific indirection in its own implementation.

@PaulSandoz Thank you for your suggestion! It might be harder to measure the time to get to peak performance, but at least for the initial invocation, the lazy VH is almost no different from the eager VH now. The old overhead was mostly from LambdaForm spinning, same for the lazy DMH overhead. Is this what you've envisioned?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1579742481

From darcy at openjdk.org  Wed Jun  7 02:52:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 02:52:24 GMT
Subject: RFR: JDK-8309574: Improve core reflection tests for JEP 445
Message-ID: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>

Add some basic core reflections tests for unnamed classes.

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

Commit messages:
 - JDK-8309574: Improve core reflection tests for JEP 445

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

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

From duke at openjdk.org  Wed Jun  7 03:37:26 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 7 Jun 2023 03:37:26 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v6]
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

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

  8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14211/files
  - new: https://git.openjdk.org/jdk/pull/14211/files/d133a15c..98a8bd62

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

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

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

From duke at openjdk.org  Wed Jun  7 03:37:26 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 7 Jun 2023 03:37:26 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v3]
In-Reply-To: <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <ZmS5Wed46zC-sx1Q09cOe3ILn_9_xy6iB5GHCSfxIQc=.5492c26f-bfcd-4cf4-a230-cfe04b59d82a@github.com>
 <VabAcPJk2RAkg1YdvsPKclLATUq4bl_10WuCbsGWQmw=.78d1a615-a130-4b7e-b358-38147f0e07d0@github.com>
 <lnUZP5MenVlXl4uRVNN1hJExB891xZj-4OIa0I4mCkY=.b70d902f-c2a5-481f-9581-fbfe649455b2@github.com>
 <_V0eAue8-9jim47bfCMBJj04CxR8flt1ZH33dQNswcM=.08fbe5a4-3839-4128-add8-e7649411a426@github.com>
 <tQ3XSlC3IMbhmrOl-2IcOlbMJay5l9n17HmSo_HHKIE=.f33a2d15-1444-426e-ad5d-b0d79ea51cf7@github.com>
Message-ID: <tCCaUOJwokQQ4n3V4fPyowPLOgjk5crMtUNwZtex9nY=.4c067d45-f14b-4b34-a96f-3d15cc63f223@github.com>

On Tue, 6 Jun 2023 18:45:50 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> For hotspot, when GC occurs, it causes all threads to run to the nearest safepoint and then freeze. Generally, safepoints are generated at branch jumps, method ends(ret instructions), loops instructions, and so on. Therefore, the purpose of this patch is to make the creation and use of a softReferences in the same method without branch, jumps and loops in between, that is ensure that GC will not occur in the process of the sofeReferences be created and used.
>> 
>> That's why I didn't use `Reference.reachabilityFence(locale)`.
>
> This reasoning seems invalid. There are method calls in there, and you rely on inlining heuristics for this not to break. Please use reachabilityFence instead.

Thanks @fisk @rose00 for the explanation. This patch is indeed based on the idea that small functions are inlined, cause `-Xcomp` be used, and I have seen with parameter `-XX:+PrintCompilation -XX:+PrintInlining` that functions `Key::<init>` and `getBaseLocale` are inlined. 
But as @rose00  say, it's not safe, so reachabilityFence should be used. please review again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1220780841

From jpai at openjdk.org  Wed Jun  7 06:34:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 7 Jun 2023 06:34:57 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <eniFkv7itdCMUxDq9LYC-h4uDRlew67VWu3wiB4JzJQ=.efbfc32e-a54a-4d72-bdcc-b719e679fe71@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>
 <eniFkv7itdCMUxDq9LYC-h4uDRlew67VWu3wiB4JzJQ=.efbfc32e-a54a-4d72-bdcc-b719e679fe71@github.com>
Message-ID: <RFH_sm-M9Szi2vMZ-w1jnSoPou3NFb8nAWEtt3AbRwk=.bb36db75-ade0-4bd8-a7d8-46502179c9c9@github.com>

On Wed, 31 May 2023 19:46:57 GMT, Glavo <duke at openjdk.org> wrote:

> > Hello @Glavo, I see you reopened this PR, so I'm guessing you are still interested in pursuing this further. Are you considering updating this PR to implement Alan's suggestion to do similar changes in `JImageTask.java` and `JlinkTask.java` to use `Locale.ROOT` or update this proposed change to use `Locale.ENGLISH`?
> 
> @jaikiran Hi Jaikiran, as my previous reply, I do not agree that `Locale.ENGLISH` should be used here, I think `Locale.ROOT` is more reasonable.

Sounds fine to me and as other have agreed `Locale.ROOT` would be more appropriate. Would you be willing to update this PR to update the few other occurences in some classes (`JImageTask`, `JlinkTask` and `VersionPropsPlugin`) as noted by Mandy and Alan in their comments?

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

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1579985432

From alanb at openjdk.org  Wed Jun  7 06:44:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 06:44:13 GMT
Subject: Integrated: 8306647: Implementation of Structured Concurrency
 (Preview)
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <UX_uTOBSNsqKOZEoseMLaox89_Jh9Jnn0Xn6YwKdcFU=.d6a68228-bfb7-4230-8f96-4e25362efc0e@github.com>

On Thu, 11 May 2023 13:08:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

This pull request has now been integrated.

Changeset: f1c7afcc
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1c7afcc3fe39622c33ac7bac1ebdd9f96fa333d
Stats:     9229 lines in 40 files changed: 4856 ins; 4315 del; 58 mod

8306647: Implementation of Structured Concurrency (Preview)
8306572: Implementation of Scoped Values (Preview)

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Reviewed-by: psandoz, dfuchs, mchung

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

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

From avu at openjdk.org  Wed Jun  7 07:00:59 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 7 Jun 2023 07:00:59 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v4]
In-Reply-To: <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>
Message-ID: <u9aRCuCviWT1Fo5TU683Yn535tbzFEL6glx-Z1gMZAw=.1e9071f3-18ef-440d-80a7-c53fb627ca49@github.com>

On Thu, 1 Jun 2023 15:01:37 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Marked as reviewed by avu (Committer).

The latest changes look good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1466776433
PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1580043192

From duke at openjdk.org  Wed Jun  7 08:16:19 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Wed, 7 Jun 2023 08:16:19 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:

  Refer review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/3d4aed98..840cd7dc

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

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

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

From duke at openjdk.org  Wed Jun  7 08:16:35 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Wed, 7 Jun 2023 08:16:35 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v7]
In-Reply-To: <F9xyr06DfR2e5-wXkOBRuHUCXVgyr6FUQ6gn3TsYeCA=.0cc97d27-f216-4480-885a-59c75bec3b11@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
 <F9xyr06DfR2e5-wXkOBRuHUCXVgyr6FUQ6gn3TsYeCA=.0cc97d27-f216-4480-885a-59c75bec3b11@github.com>
Message-ID: <VIzWvXM-quHMGIViNOKhsx2CI1PQhF8PepAe_ulnKS0=.1e103373-4426-4c86-90fd-2c456d59d219@github.com>

On Mon, 5 Jun 2023 18:04:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move SecurityException paragraph
>
> src/java.base/share/classes/java/io/File.java line 1821:
> 
>> 1819:      * root directories of the available filesystem roots.  It is guaranteed
>> 1820:      * that the canonical pathname of any file physically present on the local
>> 1821:      * machine will begin with one of the roots returned by this method.
> 
> @Nagata-Haruhito Per @AlanBateman 's suggestion, would you please add this sentence
> 
> ?There is no guarantee that the root directory can be accessed?
> 
> or the equivalent here after ?returned by this method? and after the sentence that begins with ?A file system ...? in the specification of `java.nio.file.FileSystem::getRootDirectories` and so update this PR?
> 
> Thanks.

Thanks for your advice. I changed description as your advice. I will publish CSR with this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1221124434

From asotona at openjdk.org  Wed Jun  7 08:20:03 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 7 Jun 2023 08:20:03 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v8]
In-Reply-To: <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>
Message-ID: <qUTIpvU9HqTJDbt_P9F7tdbOLS3Fy0Kozu06_zv5D50=.a3fdcf2b-a95f-498f-8471-8fb9c4c41e12@github.com>

On Fri, 2 Jun 2023 03:36:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Make lookup based resolver throw on illegal access eagerly
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/101bf229...9e9079fb

Globas static cache needs to be synchronised If this PR goes in before #14180 
Or a `defaultResolver()` should create a new cache instance (and document it is thread-unsafe) if it goes after #14180

src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java line 57:

> 55:      */
> 56:     static ClassHierarchyResolver defaultResolver() {
> 57:         return ClassHierarchyImpl.DEFAULT_RESOLVER;

defaultResolver() delegates to a thread-unsafe global static instance of cached resolver.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 130:

> 128:         @Override
> 129:         public ClassHierarchyInfo getClassInfo(ClassDesc classDesc) {
> 130:             var ret = resolvedCache.computeIfAbsent(classDesc, new Function<>() {

couldn't this function be cached?

test/jdk/jdk/classfile/ClassHierarchyInfoTest.java line 34:

> 32:  *          java.base/jdk.internal.classfile.impl
> 33:  *          java.base/jdk.internal.classfile.impl.verifier
> 34:  *          java.base/jdk.internal.classfile.java.lang.constant

jdk.internal.classfile.java.lang.constant package has been removed

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

Changes requested by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13082#pullrequestreview-1466930855
PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1221124185
PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1221102574
PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1221108184

From aturbanov at openjdk.org  Wed Jun  7 08:55:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 7 Jun 2023 08:55:57 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <IG5otj0aETda_DVB45ZU8sB_L8z24F6oSsA_Jhx_VVo=.44cdcd78-c769-4b0f-af6d-5b4a2c5b7aea@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 371:

> 369:             BaseLocale locale = new BaseLocale(l.getLanguage(), l.getScript(), l.getRegion(), l.getVariant(), true);
> 370:             try {
> 371:                 BaseLocale value = (new Key(locale)).getBaseLocale();

I don't understand. Why do we need to create thrown-away `new Key` here?
Can we just use locale?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1221187752

From duke at openjdk.org  Wed Jun  7 09:03:27 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 09:03:27 GMT
Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v2]
In-Reply-To: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
References: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
Message-ID: <bR-X2TzAvx-7gKOx9W7ZdvKOUPxEuktfyj38iMV2jGg=.ef5cb9cc-3f6b-46f5-940b-15a001e19e44@github.com>

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.base.
> 
> Compiling on AIX with xlc17 which contains the new clang 15 frontend
> shows the following warnings.
> 
> built by make/modules/java.base/Lib.gmk
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
> ^
> 
> 
> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> end = (void *)nddp + size;
> 
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
> #elif _ALLBSD_SOURCE
> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten.
> 
> built by make/modules/java.base/lib/CoreLibraries.gmk
> 
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
> if (ret < sizeof(psinfo_t)) {
> ProcessHandleImpl_unix.c:  Just using the proper type `size_t` instead of `int`.
> 
> 
> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> addr < p->ldinfo_textorg + p->ldinfo_textsize) {
> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk
> 
> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> void ZLIB_INTERNAL inflate_fast(strm, start)
> ^
> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> vfprintf(stderr, fmt, vl);
> ^~~
> 
> The test library libGetXSpace.c also shows a warning.
> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.

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

 - Merge branch 'master' into JDK-8309219
 - JDK-8309219

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

Changes: https://git.openjdk.org/jdk/pull/14281/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14281&range=01
  Stats: 12 lines in 6 files changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14281/head:pull/14281

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

From mdoerr at openjdk.org  Wed Jun  7 09:42:56 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Jun 2023 09:42:56 GMT
Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v2]
In-Reply-To: <bR-X2TzAvx-7gKOx9W7ZdvKOUPxEuktfyj38iMV2jGg=.ef5cb9cc-3f6b-46f5-940b-15a001e19e44@github.com>
References: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
 <bR-X2TzAvx-7gKOx9W7ZdvKOUPxEuktfyj38iMV2jGg=.ef5cb9cc-3f6b-46f5-940b-15a001e19e44@github.com>
Message-ID: <Qd8mqHFTRyhSOv-ZQG4_wrRaMZxeHjGRqI3dQDJ67b8=.bdd422d7-815a-4388-b1bb-d648bcdc37b9@github.com>

On Wed, 7 Jun 2023 09:03:27 GMT, JoKern65 <duke at openjdk.org> wrote:

>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.base.
>> 
>> Compiling on AIX with xlc17 which contains the new clang 15 frontend
>> shows the following warnings.
>> 
>> built by make/modules/java.base/Lib.gmk
>> 
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>> ^
>> 
>> 
>> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
>> end = (void *)nddp + size;
>> 
>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
>> #elif _ALLBSD_SOURCE
>> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten.
>> 
>> built by make/modules/java.base/lib/CoreLibraries.gmk
>> 
>> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
>> if (ret < sizeof(psinfo_t)) {
>> ProcessHandleImpl_unix.c:  Just using the proper type `size_t` instead of `int`.
>> 
>> 
>> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
>> addr < p->ldinfo_textorg + p->ldinfo_textsize) {
>> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk
>> 
>> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>> void ZLIB_INTERNAL inflate_fast(strm, start)
>> ^
>> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>> vfprintf(stderr, fmt, vl);
>> ^~~
>> 
>> The test library libGetXSpace.c also shows a warning.
>> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.
>
> JoKern65 has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8309219
>  - JDK-8309219

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14281#pullrequestreview-1467159943

From mcimadamore at openjdk.org  Wed Jun  7 10:21:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 7 Jun 2023 10:21:55 GMT
Subject: RFR: 8308445: Linker should check that capture state segment is
 big enough [v2]
In-Reply-To: <hASGyxtMmx-nKQeGaJ-uAokCKn-hrqifRnI-RJig9Bc=.9f3d385e-50b4-40c2-9878-e643791beda7@github.com>
References: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
 <hASGyxtMmx-nKQeGaJ-uAokCKn-hrqifRnI-RJig9Bc=.9f3d385e-50b4-40c2-9878-e643791beda7@github.com>
Message-ID: <j5ST-evuwG2UFrMuhQgHh9DqChGBsrENDlzCplyl2S4=.7b8575f1-8089-4d77-bd67-8824594e9e81@github.com>

On Tue, 6 Jun 2023 17:24:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Fix the bug mentioned in the JBS issue.
>> 
>> The implementation is updated to slice the capture state segment using the capture state layout. This checks both that the segment is big enough, and that it is properly aligned.
>> 
>> Additionally, I added a check for `MS::NULL` since this is also an illegal value we can catch early.
>> 
>> Test cases are added for all three invalid values.
>> 
>> Testing: `jdk_foreign` test suite.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename MH field

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14339#pullrequestreview-1467264730

From duke at openjdk.org  Wed Jun  7 11:00:10 2023
From: duke at openjdk.org (duke)
Date: Wed, 7 Jun 2023 11:00:10 GMT
Subject: Withdrawn: 8293806: JDK_JAVA_OPTIONS picked up twice if launcher
 re-executes itself
In-Reply-To: <OW6KaT2Vfefx_KOyDhIkVxSUOFtgiu6SCn3D8WM5PF8=.143804b1-22eb-4d9b-bf7c-1d3768a98308@github.com>
References: <OW6KaT2Vfefx_KOyDhIkVxSUOFtgiu6SCn3D8WM5PF8=.143804b1-22eb-4d9b-bf7c-1d3768a98308@github.com>
Message-ID: <p7VTFQxw8wAeRbmmEyAuhZOkvSXu2dQKQmx3hD4aRGg=.8c9cea74-6394-4033-a4c8-31f7bacbc223@github.com>

On Tue, 6 Dec 2022 14:04:44 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options from the JDK_JAVA_OPTIONS environment variable are picked up twice.
> 
> If an option cannot be accepted twice (e.g., -agentlib), the application fails to start.
> 
> The same happens on operating systems that doesn't support $RPATH/$ORIGIN and always have to set LD_LIBRARY_PATH and re-exec the launcher.
> 
> This fix takes the approach to re-launch as early as possible, as discussed here:
> 
> https://github.com/openjdk/jdk/pull/10430
> 
> This PR consists of three commits:
> 1. Cleanup of java_md.c
> 2. The implementation of early re-launch
> 3. Performance optimization
> 
> @AlanBateman, @dholmes-ora Alan, David - any comments are appreciated.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Wed Jun  7 11:23:26 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 11:23:26 GMT
Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v3]
In-Reply-To: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
References: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
Message-ID: <nPjvfPYDgz0S08dWCVaXSaS14g0-Q26fFUO68Aif_yA=.273429d9-b323-4b30-aff4-ced4229c5ce8@github.com>

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.base.
> 
> Compiling on AIX with xlc17 which contains the new clang 15 frontend
> shows the following warnings.
> 
> built by make/modules/java.base/Lib.gmk
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
> ^
> 
> 
> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> end = (void *)nddp + size;
> 
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
> #elif _ALLBSD_SOURCE
> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten.
> 
> built by make/modules/java.base/lib/CoreLibraries.gmk
> 
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
> if (ret < sizeof(psinfo_t)) {
> ProcessHandleImpl_unix.c:  Just using the proper type `size_t` instead of `int`.
> 
> 
> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> addr < p->ldinfo_textorg + p->ldinfo_textsize) {
> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk
> 
> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> void ZLIB_INTERNAL inflate_fast(strm, start)
> ^
> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> vfprintf(stderr, fmt, vl);
> ^~~
> 
> The test library libGetXSpace.c also shows a warning.
> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.

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

  Update libGetXSpace.c
  
  cast not necessary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14281/files
  - new: https://git.openjdk.org/jdk/pull/14281/files/f185fa5d..7e8f5376

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

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

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

From rgiulietti at openjdk.org  Wed Jun  7 11:27:14 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 Jun 2023 11:27:14 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern()
Message-ID: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>

The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`

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

Commit messages:
 - 8309515: Stale cached data from Matcher.namedGroups() after Matcher.usePattern()

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

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

From rgiulietti at openjdk.org  Wed Jun  7 11:27:15 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 Jun 2023 11:27:15 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern()
In-Reply-To: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
Message-ID: <JFmJJoA8x0IinNIofaQR5J3AC1eJsQys8bDcEVa2zn8=.525f634e-1700-43e4-bd95-814ff4d5c326@github.com>

On Wed, 7 Jun 2023 11:20:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`

Also added a test for this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14350#issuecomment-1580578032

From rgiulietti at openjdk.org  Wed Jun  7 11:51:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 Jun 2023 11:51:19 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern() [v2]
In-Reply-To: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
Message-ID: <Fa395t3H05o7hEJtJocoV1Gj3LcF4Z-oopvm4V_RRfs=.a8825751-0e5d-4139-8b36-e2abfe197b81@github.com>

> The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`

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

  Renamed the additional test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14350/files
  - new: https://git.openjdk.org/jdk/pull/14350/files/29d8047f..dbe40b98

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

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

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

From djelinski at openjdk.org  Wed Jun  7 11:59:57 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 7 Jun 2023 11:59:57 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <wxh0x-vY5XEoXaoWGDLZ30xC_1Wp9LJogCKeCOMfIwQ=.38291318-759a-4746-b7c7-8a09265a8c5d@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

In its current form the `BaseLocale.Cache.createObject` function can return `null`; the object returned by `BaseLocale.Key.normalizeKey(key)` holds a soft reference to locale, and by the time `getBaseLocale` is called, the reference may be cleared.

`Key` only uses `SoftReferences` because it must not hold a reference to the object returned by `createObject`. We could refactor `createObject` to return a clone of the `BaseLocale` referenced by `Key`, and then `Key` would not need to use `SoftReference`s.

That being said, the number of long-lived `BaseLocale` objects is very limited; we only keep them in Locale, LocaleKey, and Locale.CONSTANT_LOCALES. Unless I'm missing something, we could solve this problem by removing `BaseLocale` caching, and improve performance at the same time.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1580652895

From alanb at openjdk.org  Wed Jun  7 12:11:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 12:11:57 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
Message-ID: <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>

On Wed, 7 Jun 2023 08:16:19 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refer review comment

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

> 1820:      * that the canonical pathname of any file physically present on the local
> 1821:      * machine will begin with one of the roots returned by this method.
> 1822:      * There is no guarantee that the root directory can be accessed.

The current patch looks okay, just need to change "the root directory" to "a root directory", here and also in FileSystem::getRootDirectories.

I see a CSR has been created. If you don't mind, I will edit it to make it clearer what this is about.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1221472561

From jvernee at openjdk.org  Wed Jun  7 12:18:04 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 7 Jun 2023 12:18:04 GMT
Subject: Integrated: 8308031: Linkers should reject unpromoted variadic
 parameters
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <0PKueH81WPdbGKLm79f0gJCJX1YiXeHZ_xJkdjt4AoM=.0842851a-c89d-4c99-8942-7ad8927c7795@github.com>

On Tue, 30 May 2023 17:25:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch adds the automatic argument promotion for variadic arguments, to align the implementation with the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains this.
> 
> TestVarArgs needed to be updated in order to account for the difference in the promoted `float` values.
> 
> Testing:
> - local testing on Windows/x64
> - local testing on Linux/x64 using the fallback linker
> - tier1-3 + jdk-tier5
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

This pull request has now been integrated.

Changeset: fa791119
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa791119f0b73cd1e110d6a62d3bed58fee5740a
Stats:     144 lines in 11 files changed: 120 ins; 6 del; 18 mod

8308031: Linkers should reject unpromoted variadic parameters

Reviewed-by: mcimadamore

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

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

From jvernee at openjdk.org  Wed Jun  7 12:28:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 7 Jun 2023 12:28:06 GMT
Subject: Integrated: 8308445: Linker should check that capture state segment is
 big enough
In-Reply-To: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
References: <zfzXbqJyHqiecOQEaPx-5Q2c87iqOIKq5PqBgIMnUv8=.f32ce645-06ba-4806-b87f-7085689ed375@github.com>
Message-ID: <qTWJ1uZkjtapFEUM9o2tp8xq-IyCd0b8ApLt4OuuHfI=.d623f45b-5733-43d9-802a-7048d3314d52@github.com>

On Tue, 6 Jun 2023 16:22:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Fix the bug mentioned in the JBS issue.
> 
> The implementation is updated to slice the capture state segment using the capture state layout. This checks both that the segment is big enough, and that it is properly aligned.
> 
> Additionally, I added a check for `MS::NULL` since this is also an illegal value we can catch early.
> 
> Test cases are added for all three invalid values.
> 
> Testing: `jdk_foreign` test suite.

This pull request has now been integrated.

Changeset: c49129f5
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c49129f54580b431881ffdb97b5478aff6097154
Stats:     48 lines in 4 files changed: 46 ins; 1 del; 1 mod

8308445: Linker should check that capture state segment is big enough

Reviewed-by: mcimadamore

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

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

From alanb at openjdk.org  Wed Jun  7 12:46:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 12:46:07 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <fM7TFfAz0PmVC43LpifuiiTUbyrZYXWxtNSuYZwuI_E=.508e494b-8b30-4953-b5e8-154388a7ae6b@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

src/java.base/share/classes/sun/util/locale/LocaleObjectCache.java line 63:

> 61:             if (newVal == null) {
> 62:                 // subclass must return non-null key/value object
> 63:                 throw new NullPointerException();

Is this caught somewhere, it seem strange to throw NPE here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14211#discussion_r1221526553

From alanb at openjdk.org  Wed Jun  7 12:51:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 12:51:01 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v6]
In-Reply-To: <wxh0x-vY5XEoXaoWGDLZ30xC_1Wp9LJogCKeCOMfIwQ=.38291318-759a-4746-b7c7-8a09265a8c5d@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
 <wxh0x-vY5XEoXaoWGDLZ30xC_1Wp9LJogCKeCOMfIwQ=.38291318-759a-4746-b7c7-8a09265a8c5d@github.com>
Message-ID: <e9KmF_NHL2J4e_a8T8N0KrVNctXCdnJRcS9HNw7o0JM=.42119706-8f71-4d51-a624-88e161dd58d9@github.com>

On Wed, 7 Jun 2023 11:55:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> That being said, the number of long-lived `BaseLocale` objects is very limited; we only keep them in Locale, LocaleKey, and Locale.CONSTANT_LOCALES. Unless I'm missing something, we could solve this problem by removing `BaseLocale` caching, and improve performance at the same time.

The motivation seems to be startup ([JDK-8196869](https://bugs.openjdk.org/browse/JDK-8196869)). It looks like it needs to be re-evaluated and if we continue with caching in this area then I think we'll need some stress tests to go with it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1580746429

From mdoerr at openjdk.org  Wed Jun  7 12:52:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Jun 2023 12:52:57 GMT
Subject: RFR: JDK-8309219: Fix xlc17 clang 15 warnings in java.base [v3]
In-Reply-To: <nPjvfPYDgz0S08dWCVaXSaS14g0-Q26fFUO68Aif_yA=.273429d9-b323-4b30-aff4-ced4229c5ce8@github.com>
References: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
 <nPjvfPYDgz0S08dWCVaXSaS14g0-Q26fFUO68Aif_yA=.273429d9-b323-4b30-aff4-ced4229c5ce8@github.com>
Message-ID: <fd6a9ID1Bv0cW7ZhRkJ1Jogg9v4Idjsl0JzU0D5paa4=.65ffffb8-3a6f-4222-b697-1748807bba76@github.com>

On Wed, 7 Jun 2023 11:23:26 GMT, JoKern65 <duke at openjdk.org> wrote:

>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.base.
>> 
>> Compiling on AIX with xlc17 which contains the new clang 15 frontend
>> shows the following warnings.
>> 
>> built by make/modules/java.base/Lib.gmk
>> 
>> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
>> ^
>> 
>> 
>> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
>> end = (void *)nddp + size;
>> 
>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
>> #elif _ALLBSD_SOURCE
>> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten.
>> 
>> built by make/modules/java.base/lib/CoreLibraries.gmk
>> 
>> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
>> if (ret < sizeof(psinfo_t)) {
>> ProcessHandleImpl_unix.c:  Just using the proper type `size_t` instead of `int`.
>> 
>> 
>> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
>> addr < p->ldinfo_textorg + p->ldinfo_textsize) {
>> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk
>> 
>> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
>> void ZLIB_INTERNAL inflate_fast(strm, start)
>> ^
>> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>> vfprintf(stderr, fmt, vl);
>> ^~~
>> 
>> The test library libGetXSpace.c also shows a warning.
>> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update libGetXSpace.c
>   
>   cast not necessary

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14281#pullrequestreview-1467571356

From duke at openjdk.org  Wed Jun  7 13:45:02 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 13:45:02 GMT
Subject: Integrated: JDK-8309219: Fix xlc17 clang 15 warnings in java.base
In-Reply-To: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
References: <Cl6a16WTQRvR8-Gsn1qcdkNeFIGVHP0Q9Sl28n0-BAs=.c0654420-9dac-4705-97a5-07ffc1d46a3c@github.com>
Message-ID: <CyiBOfI5NNM3H_kQzj21V3CAjpeE8S1FHyeZEufEJNg=.a46467cc-a581-46a4-8b28-fa0d4c06bb1c@github.com>

On Fri, 2 Jun 2023 10:08:09 GMT, JoKern65 <duke at openjdk.org> wrote:

> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared code https://github.com/openjdk/jdk/pull/14146
> It handles the part in java.base.
> 
> Compiling on AIX with xlc17 which contains the new clang 15 frontend
> shows the following warnings.
> 
> built by make/modules/java.base/Lib.gmk
> 
> src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
> ^
> 
> 
> src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> end = (void *)nddp + size;
> 
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
> #elif _ALLBSD_SOURCE
> The whole file checks whether _ALLBSD_SOURCE is defined, only where #elif is used the call to defined() was forgotten.
> 
> built by make/modules/java.base/lib/CoreLibraries.gmk
> 
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
> if (ret < sizeof(psinfo_t)) {
> ProcessHandleImpl_unix.c:  Just using the proper type `size_t` instead of `int`.
> 
> 
> src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
> addr < p->ldinfo_textorg + p->ldinfo_textsize) {
> we can fix this with temporary casting the `void*` pointer to `char*` or by disabling the warning in CoreLibraries.gmk
> 
> src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
> void ZLIB_INTERNAL inflate_fast(strm, start)
> ^
> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
> vfprintf(stderr, fmt, vl);
> ^~~
> 
> The test library libGetXSpace.c also shows a warning.
> In addition, the cast in that lib is wrong, we opened "[JDK-8309216](https://bugs.openjdk.org/browse/JDK-8309216) cast from jchar* to char* in test GetXSpace.java" for that.

This pull request has now been integrated.

Changeset: 6eddbe26
Author:    JoKern65 <128386669+JoKern65 at users.noreply.github.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6eddbe26dd0b9afb83fc029d77e18212e63f98f4
Stats:     12 lines in 6 files changed: 3 ins; 0 del; 9 mod

8309219: Fix xlc17 clang 15 warnings in java.base

Reviewed-by: goetz, mdoerr

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

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

From liach at openjdk.org  Wed Jun  7 14:15:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Jun 2023 14:15:10 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Review changes, fixed tests
 - Merge branch 'master' into hierarchy-resolve
 - 1. Moved the default resolver to a static method, in anticipation of future changes
   2. Removed SecurityManager related content
   3. Changed ClassHierarchyInfo into an interface
   4. Moved caching method from static to instance method
 - Merge branch 'master' into hierarchy-resolve
 - rename to ofClassLoading/ofResourceParsing
   convert the default class provider to bypass security manager restrictions
 - Merge branch 'master' into hierarchy-resolve
 - Merge branch 'master' into hierarchy-resolve
 - Test both cached and uncached resolvers
 - Update the class hierarchy resolver api as per mailing list last week
 - Merge branch 'master' into hierarchy-resolve
 - ... and 4 more: https://git.openjdk.org/jdk/compare/a1ab377d...90645b6f

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

Changes: https://git.openjdk.org/jdk/pull/13082/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13082&range=08
  Stats: 401 lines in 10 files changed: 304 ins; 29 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/13082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082

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

From liach at openjdk.org  Wed Jun  7 14:15:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Jun 2023 14:15:13 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v8]
In-Reply-To: <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <py85zSFhVXSnenuJenlhmOvHX4CV3T4LiXzqGjNuh1k=.5100917f-12ea-4641-b92e-ef66f83d6e2a@github.com>
Message-ID: <sSEUcChKxtlikZt4k2IA_pLTNmwa17NGZGT_ImPdN5E=.77459976-f9a0-416d-aa38-d10fea37a11e@github.com>

On Fri, 2 Jun 2023 03:36:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Make lookup based resolver throw on illegal access eagerly
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/101bf229...9e9079fb

Done. I've synchronized the global static cache for now, and thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/13082#issuecomment-1580904371

From prappo at openjdk.org  Wed Jun  7 14:26:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 14:26:36 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
Message-ID: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>

Please review this long-awaited change to documentation inheritance.

This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:

?{@inheritDoc S}

Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

Commit messages:
 - Disable problematic check
 - Counterbalance changes to method comments algorithm
 - Improve diagnostics
 - Update method comments algorithm
 - Implement directed documentation inheritance

Changes: https://git.openjdk.org/jdk/pull/14357/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285368
  Stats: 1827 lines in 32 files changed: 1693 ins; 29 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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

From jjg at openjdk.org  Wed Jun  7 15:29:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 15:29:55 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1325:

> 1323:                         //
> 1324:                         //     m.at(pos).newInheritDocTree(ref)
> 1325:                         //

Although the scary warning is not wrong, I think it would have been enough to say something more concise, like "_use the original legacy method if no ref is given_"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1221797159

From duke at openjdk.org  Wed Jun  7 15:39:58 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 7 Jun 2023 15:39:58 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll()
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <bs4VBku6dv6HukXmFnWiddxqrztE_Tb3ifiGz5FBmU4=.55a9700c-9dec-4432-b10b-6ae6c7d839f7@github.com>

On Mon, 5 Jun 2023 18:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

@DougLea @AlanBateman I had a look as well, didn't find anything to comment on. ?

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

PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-1581078316

From prappo at openjdk.org  Wed Jun  7 15:45:01 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 15:45:01 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <6gQPb_srubW1AqMpi9WmzMRYJDAZXit3-c4xi_T6oVM=.aa70485e-bb3c-4d29-bc0e-868a51051c33@github.com>
Message-ID: <kMJ-UdMOezmkIu04LMPaFN1E8h0Mzu8jmDJgT7Y55QU=.02c110be-c7fd-4cc4-a71a-305db60003be@github.com>

On Wed, 7 Jun 2023 15:27:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1325:
> 
>> 1323:                         //
>> 1324:                         //     m.at(pos).newInheritDocTree(ref)
>> 1325:                         //
> 
> Although the scary warning is not wrong, I think it would have been enough to say something more concise, like "_use the original legacy method if no ref is given_"

I'll tone it down; thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1221821265

From prappo at openjdk.org  Wed Jun  7 15:51:56 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 15:51:56 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <wosayDaqqnU3b182aUqyDLiG57Iw-hMnXfwIKVaT_uo=.9ad4e309-a3a8-4fe5-849c-1392c39fcaab@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

For details on changes to "methods comment algorithm", see the associated CSR: https://bugs.openjdk.org/browse/JDK-8287152

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1581099793

From prappo at openjdk.org  Wed Jun  7 16:02:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 16:02:40 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: make warning less scary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/a56253b3..c0fc69c2

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

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

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

From mchung at openjdk.org  Wed Jun  7 16:14:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 16:14:11 GMT
Subject: RFR: 8309532: java/lang/Class/getDeclaredField/FieldSetAccessibleTest
 should filter modules that depend on JVMCI
Message-ID: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>

`FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

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

Commit messages:
 - 8309532: java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter upgradeable modules

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

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

From mchung at openjdk.org  Wed Jun  7 16:20:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 16:20:56 GMT
Subject: RFR: JDK-8309574: Improve core reflection tests for JEP 445
In-Reply-To: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>
References: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>
Message-ID: <kc5hmXda95VTHp_YDQRYjSfokMqIDY50Bq0IN2AfaQQ=.2e958522-4a5c-4768-9599-828a595fc3e7@github.com>

On Wed, 7 Jun 2023 02:45:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add some basic core reflections tests for unnamed classes.

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14345#pullrequestreview-1468111408

From naoto at openjdk.org  Wed Jun  7 16:25:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 7 Jun 2023 16:25:57 GMT
Subject: RFR: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared [v6]
In-Reply-To: <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <LBDwbTg0XxseTZSygapxhG2d77aEj3qZ6kInhg322GM=.0c8d376e-05ca-4702-a2c4-a44af8edb22a@github.com>
Message-ID: <BI0NLGYtNhME9B5RqakCgqtewbY4oQY2lpBdbErw-u4=.1cb6ebe6-5ea3-4b01-98f7-706823d47696@github.com>

On Wed, 7 Jun 2023 03:37:26 GMT, SUN Guoyun <duke at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> SUN Guoyun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289220: Locale.forLanguageTag throws NPE due to soft ref used in locale cache being cleared

Good point Daniel. I created an issue for re-examining the cache mechanism in `BaseLocale`: https://bugs.openjdk.org/browse/JDK-8309622

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1581155416

From alanb at openjdk.org  Wed Jun  7 17:01:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 17:01:55 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI
In-Reply-To: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
Message-ID: <U9tpvhCE8cegdoBgz2dZijjR8YbMH-oA10C2D5AXwT0=.85ee8f9d-d0de-4995-a981-9e95430e5750@github.com>

On Wed, 7 Jun 2023 16:06:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 314:

> 312:             });
> 313: 
> 314:             Set<String> deployModules = Set.of("javafx.deploy", "jdk.deploy", "jdk.plugin", "jdk.javaws");

Can deployModules be dropped?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14362#discussion_r1221919712

From alanb at openjdk.org  Wed Jun  7 17:33:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 17:33:57 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI
In-Reply-To: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
Message-ID: <e3_YyBTGE4T7tCezdM1-SjQbc5fxk1AekqBU4LGT8qQ=.a33a56e4-8b29-47b8-8a1f-06935f15f9be@github.com>

On Wed, 7 Jun 2023 16:06:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14362#pullrequestreview-1468226263

From alanb at openjdk.org  Wed Jun  7 17:34:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 17:34:22 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
 <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>
Message-ID: <1B_vjAxLnuMVEPMuz9EyMWRRwFomFGSpyaACzD1732k=.e76b095a-fd90-4350-a3b4-e3751ca5bc87@github.com>

On Wed, 7 Jun 2023 12:09:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refer review comment
>
> src/java.base/share/classes/java/io/File.java line 1822:
> 
>> 1820:      * that the canonical pathname of any file physically present on the local
>> 1821:      * machine will begin with one of the roots returned by this method.
>> 1822:      * There is no guarantee that the root directory can be accessed.
> 
> The current patch looks okay, just need to change "the root directory" to "a root directory", here and also in FileSystem::getRootDirectories.
> 
> I see a CSR has been created. If you don't mind, I will edit it to make it clearer what this is about.

The CSR is updated so it's focused on the two parts of the updated docs. So I think you can finalize.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1221944247

From prappo at openjdk.org  Wed Jun  7 17:34:22 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 17:34:22 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <Mf4lFV-lds3s3_tH5fBxTU31hdmdtmsQvpzacfwgb7U=.a6cdc2d2-aefc-4765-a992-1e82b8a86e09@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

Full disclosure. Here are all the files that are different before (1) and after (2) the change:

 - https://cr.openjdk.org/~prappo/8285368/1/api
 - https://cr.openjdk.org/~prappo/8285368/2/api

As you can see, the vast majority of differences are in "See Also" sections, which come from `@see` tags. Sadly, `@see` tags are inheritable "by omission". That said, `@see` is also underspecified, somewhat broken, and I believe is not as important as those parts of a doc comment that allow `{@inheritDoc}`.

I suggest that we integrate this PR and take care of `@see` in 22. But if the corrections are really required, I can try to introduce explicit `@see` tags, so there are no changes whatsoever.

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

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1581226538

From mchung at openjdk.org  Wed Jun  7 17:34:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 17:34:12 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI
In-Reply-To: <U9tpvhCE8cegdoBgz2dZijjR8YbMH-oA10C2D5AXwT0=.85ee8f9d-d0de-4995-a981-9e95430e5750@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
 <U9tpvhCE8cegdoBgz2dZijjR8YbMH-oA10C2D5AXwT0=.85ee8f9d-d0de-4995-a981-9e95430e5750@github.com>
Message-ID: <WRqoAqvYSVrlGnUr-MI5HKfxCOnhaMHt-Sxb5U6dqOE=.15c96354-d14e-428c-9d50-5efe944b6b81@github.com>

On Wed, 7 Jun 2023 16:59:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.
>
> test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 314:
> 
>> 312:             });
>> 313: 
>> 314:             Set<String> deployModules = Set.of("javafx.deploy", "jdk.deploy", "jdk.plugin", "jdk.javaws");
> 
> Can deployModules be dropped?

There are two other tests that should be updated.  I updated this one in this PR.  Will create another PR to drop those.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14362#discussion_r1221937427

From alanb at openjdk.org  Wed Jun  7 17:34:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 17:34:12 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI
In-Reply-To: <WRqoAqvYSVrlGnUr-MI5HKfxCOnhaMHt-Sxb5U6dqOE=.15c96354-d14e-428c-9d50-5efe944b6b81@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
 <U9tpvhCE8cegdoBgz2dZijjR8YbMH-oA10C2D5AXwT0=.85ee8f9d-d0de-4995-a981-9e95430e5750@github.com>
 <WRqoAqvYSVrlGnUr-MI5HKfxCOnhaMHt-Sxb5U6dqOE=.15c96354-d14e-428c-9d50-5efe944b6b81@github.com>
Message-ID: <sZjdj_sGh7DElJREVDd3YOdc7a7rbIGn0A0w-FHKVOU=.75fcf36a-4c62-4315-bc8f-009454093d65@github.com>

On Wed, 7 Jun 2023 17:16:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 314:
>> 
>>> 312:             });
>>> 313: 
>>> 314:             Set<String> deployModules = Set.of("javafx.deploy", "jdk.deploy", "jdk.plugin", "jdk.javaws");
>> 
>> Can deployModules be dropped?
>
> There are two other tests that should be updated.  I updated this one in this PR.  Will create another PR to drop those.

Okay, that's fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14362#discussion_r1221945307

From dfuchs at openjdk.org  Wed Jun  7 17:47:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 7 Jun 2023 17:47:08 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI
In-Reply-To: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
Message-ID: <4ouOK0W_v-KOj2BGE77UDySO7SCaaO6M5h7XeKKmsCE=.8df7b99e-fc2f-4122-8eb1-cdc9852210fd@github.com>

On Wed, 7 Jun 2023 16:06:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

LGTM. I have suggested adding a comment to explain what's going on in the code added.

test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 323:

> 321:                                                 mods.stream()
> 322:                                                     .flatMap(mn -> findDeps(mn, inverseDeps).stream()))
> 323:                                         .collect(Collectors.toSet());

Suggestion:

            // Build a list of modules that should be filtered out. These are the deploy modules,
            // plus all modules that directly or indirectly require jdk.internal.vm.compiler and
            // jdk.internal.vm.compiler.management, as these are upgradeable and also provide
            // APIs to add qualified exports dynamically.
            Set<String> filters = Stream.concat(deployModules.stream(),
                                                mods.stream()
                                                    .flatMap(mn -> findDeps(mn, inverseDeps).stream()))
                                        .collect(Collectors.toSet());

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14362#pullrequestreview-1468243596
PR Review Comment: https://git.openjdk.org/jdk/pull/14362#discussion_r1221957008

From bpb at openjdk.org  Wed Jun  7 17:50:25 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Jun 2023 17:50:25 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <1B_vjAxLnuMVEPMuz9EyMWRRwFomFGSpyaACzD1732k=.e76b095a-fd90-4350-a3b4-e3751ca5bc87@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
 <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>
 <1B_vjAxLnuMVEPMuz9EyMWRRwFomFGSpyaACzD1732k=.e76b095a-fd90-4350-a3b4-e3751ca5bc87@github.com>
Message-ID: <OwIoMoOeVpJ_uCr9Vl80NwebjCS9A3Hoxdvw_MZISX4=.8e8bf00c-2f3f-4ef0-8483-0a80d8e83c07@github.com>

On Wed, 7 Jun 2023 17:24:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think you can finalize.

@Nagata-Haruhito I took the liberty of finalizing the CSR. If you would make the requested changes (change "the root directory" to "a root directory") in the two classes, then we can approve it and hopefully get this integrated before the JDK 21 fork.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1221969128

From rriggs at openjdk.org  Wed Jun  7 17:54:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Jun 2023 17:54:46 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern() [v2]
In-Reply-To: <Fa395t3H05o7hEJtJocoV1Gj3LcF4Z-oopvm4V_RRfs=.a8825751-0e5d-4139-8b36-e2abfe197b81@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
 <Fa395t3H05o7hEJtJocoV1Gj3LcF4Z-oopvm4V_RRfs=.a8825751-0e5d-4139-8b36-e2abfe197b81@github.com>
Message-ID: <JEa1v8zBQ8-VjkQSmVmO7I9_xq04eXntRn4g3RoBdRI=.c4c5ca28-1bd9-44ab-9a48-8242db55d566@github.com>

On Wed, 7 Jun 2023 11:51:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed the additional test.

test/jdk/java/util/regex/NamedGroupsTests.java line 367:

> 365:         }
> 366:         if (!m.group("a").equals("bar")) {
> 367:             throw new RuntimeException();

Failures will be easier to resolve if there is some description of the failure. Having to go back to the stack trace adds extra overhead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14350#discussion_r1221972763

From mchung at openjdk.org  Wed Jun  7 18:08:30 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 18:08:30 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI [v2]
In-Reply-To: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
Message-ID: <sHC1iqzpdNjJtgmprdt3KFhSeIO8PcT2enNYtY3Dacs=.9c33721a-c86a-463f-9488-aebbee4ad055@github.com>

> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

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

  no need to keep filtering deploy module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14362/files
  - new: https://git.openjdk.org/jdk/pull/14362/files/dc435ae0..36c1507d

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

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

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

From darcy at openjdk.org  Wed Jun  7 18:10:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 18:10:23 GMT
Subject: RFR: JDK-8309574: Improve core reflection tests for JEP 445 [v2]
In-Reply-To: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>
References: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>
Message-ID: <LCi8rpHiWfaDxTAV0aresyeisIWIJl7HBgqrBV8IfhM=.4cafa905-a402-4768-84ad-a7b45db0299f@github.com>

> Add some basic core reflections tests for unnamed classes.

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

 - Added end of file newline.
 - Merge branch 'master' into JDK-8309574
 - JDK-8309574: Improve core reflection tests for JEP 445

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14345/files
  - new: https://git.openjdk.org/jdk/pull/14345/files/bcf92b02..8a3f4666

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

  Stats: 25550 lines in 211 files changed: 20977 ins; 4370 del; 203 mod
  Patch: https://git.openjdk.org/jdk/pull/14345.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14345/head:pull/14345

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

From darcy at openjdk.org  Wed Jun  7 18:14:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 7 Jun 2023 18:14:45 GMT
Subject: Integrated: JDK-8309574: Improve core reflection tests for JEP 445
In-Reply-To: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>
References: <wVnh1TKO80O6k4dGodPS_fubb3PqI5p6qxV_VZ_nZV4=.0c4ec2ad-958f-4634-a178-d9ab95f405f7@github.com>
Message-ID: <aoJdPE3U1eaxBt2LfurpQ5wbKstTUfUCYluzJPWGXog=.75c4fa8d-29dc-4579-b958-4106445d79b0@github.com>

On Wed, 7 Jun 2023 02:45:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add some basic core reflections tests for unnamed classes.

This pull request has now been integrated.

Changeset: 4ffc8cc2
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ffc8cc2169c6b34ce5d9cf0ce98125520c4495a
Stats:     99 lines in 2 files changed: 95 ins; 0 del; 4 mod

8309574: Improve core reflection tests for JEP 445

Reviewed-by: mchung

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

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

From mchung at openjdk.org  Wed Jun  7 18:44:02 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 18:44:02 GMT
Subject: RFR: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI [v3]
In-Reply-To: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
Message-ID: <h4yFQMJhM-w1dqlMhbifSjZP2UFGZwKsBzn19sNP1sY=.acf2b80f-8abc-4f55-b444-d4772d2028ef@github.com>

> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

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

 - clean up
 - review feedback
 - add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14362/files
  - new: https://git.openjdk.org/jdk/pull/14362/files/36c1507d..1bed308c

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

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

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

From mchung at openjdk.org  Wed Jun  7 18:47:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 18:47:55 GMT
Subject: Integrated: 8309532:
 java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules
 that depend on JVMCI
In-Reply-To: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
References: <KUPE31ZXw2lMGBrcVksEJrKtEM7nTC0B586k-alzmEQ=.870c27cd-5c70-40eb-8db3-637274700f20@github.com>
Message-ID: <LGK78Mua4lAlkX8vm1aVsmGNkKY2z_EMhyFfk7ti7Hk=.1f2d9f0d-2c38-4952-8111-dc0d1fb52550@github.com>

On Wed, 7 Jun 2023 16:06:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `FieldSetAccessibleTest` attempts to load all JDK classes and test `setAccessible` on their public fields to work properly.   It should filter the modules that directly and indirectly depend on `jdk.internal.vm.compiler` and  `jdk.internal.vm.compiler.management` as they are upgradeable and also provide APIs to add qualifed exports dynamically.

This pull request has now been integrated.

Changeset: 02bce0b1
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02bce0b1452b804f3a7883ca8bf29a524b73672e
Stats:     65 lines in 1 file changed: 51 ins; 1 del; 13 mod

8309532: java/lang/Class/getDeclaredField/FieldSetAccessibleTest should filter modules that depend on JVMCI

Reviewed-by: alanb, dfuchs

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

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

From rgiulietti at openjdk.org  Wed Jun  7 18:54:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 Jun 2023 18:54:49 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern() [v2]
In-Reply-To: <JEa1v8zBQ8-VjkQSmVmO7I9_xq04eXntRn4g3RoBdRI=.c4c5ca28-1bd9-44ab-9a48-8242db55d566@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
 <Fa395t3H05o7hEJtJocoV1Gj3LcF4Z-oopvm4V_RRfs=.a8825751-0e5d-4139-8b36-e2abfe197b81@github.com>
 <JEa1v8zBQ8-VjkQSmVmO7I9_xq04eXntRn4g3RoBdRI=.c4c5ca28-1bd9-44ab-9a48-8242db55d566@github.com>
Message-ID: <VCIAcJWf9W6iz6vvuZnxJ4uipqGsgliPgBs8m_2nfxU=.a32580d2-ec54-49bd-8123-cf7983762ca2@github.com>

On Wed, 7 Jun 2023 17:51:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renamed the additional test.
>
> test/jdk/java/util/regex/NamedGroupsTests.java line 367:
> 
>> 365:         }
>> 366:         if (!m.group("a").equals("bar")) {
>> 367:             throw new RuntimeException();
> 
> Failures will be easier to resolve if there is some description of the failure. Having to go back to the stack trace adds extra overhead.

I agree.
On the one hand, I would prefer to rewrite these tests (the .java file) JUnit tests, but this would require more review work.
On the other hand, adding descriptions just for this specific, additional test is a bit at odd with the other tests in the file.
What's the preferred course of action? I have no problems with either way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14350#discussion_r1222031599

From rriggs at openjdk.org  Wed Jun  7 19:00:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Jun 2023 19:00:52 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern() [v2]
In-Reply-To: <VCIAcJWf9W6iz6vvuZnxJ4uipqGsgliPgBs8m_2nfxU=.a32580d2-ec54-49bd-8123-cf7983762ca2@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
 <Fa395t3H05o7hEJtJocoV1Gj3LcF4Z-oopvm4V_RRfs=.a8825751-0e5d-4139-8b36-e2abfe197b81@github.com>
 <JEa1v8zBQ8-VjkQSmVmO7I9_xq04eXntRn4g3RoBdRI=.c4c5ca28-1bd9-44ab-9a48-8242db55d566@github.com>
 <VCIAcJWf9W6iz6vvuZnxJ4uipqGsgliPgBs8m_2nfxU=.a32580d2-ec54-49bd-8123-cf7983762ca2@github.com>
Message-ID: <vLPUWH4C_zSdPnq2wz5G72sWNSDGpbMIQsnrDXRLldc=.24dd816c-881b-48bb-85d7-ab1c481eb3c4@github.com>

On Wed, 7 Jun 2023 18:51:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> test/jdk/java/util/regex/NamedGroupsTests.java line 367:
>> 
>>> 365:         }
>>> 366:         if (!m.group("a").equals("bar")) {
>>> 367:             throw new RuntimeException();
>> 
>> Failures will be easier to resolve if there is some description of the failure. Having to go back to the stack trace adds extra overhead.
>
> I agree.
> On the one hand, I would prefer to rewrite these tests (the .java file) JUnit tests, but this would require more review work.
> On the other hand, adding descriptions just for this specific, additional test is a bit at odd with the other tests in the file.
> What's the preferred course of action? I have no problems with either way.

I'd add string descriptions to the new exceptions and file an issue to update the test later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14350#discussion_r1222038064

From jjg at openjdk.org  Wed Jun  7 19:00:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:00:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 94:

> 92:             if (supertype == null) {
> 93:                 messages.error(inheritDocPath, "doclet.inheritDocBadSupertype");
> 94:                 return replacement;

`replacement` may be empty.
Consider using `HtmlDocletWriter.invalidTagOutput`.

(Later, we might want to provide a utility message to wrap `messages.error` and `invalidTagOutput`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:

> 108:             for (Element e : methods) {
> 109:                 ExecutableElement m = (ExecutableElement) e;
> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {

Suggestion for eventual future cleanup (not this PR): reduce need for chained fields like`config.utils.elementUtils`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:

> 108:             for (Element e : methods) {
> 109:                 ExecutableElement m = (ExecutableElement) e;
> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {

Note that `configuration.utils` is available as `utils`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 120:

> 118:                 // that this method overrides
> 119:                 messages.error(inheritDocPath, "doclet.inheritDocBadSupertype");
> 120:                 return replacement;

Another case for `invalidTagOutput` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222037366
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222032679
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222035009
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222037884

From mchung at openjdk.org  Wed Jun  7 19:10:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 19:10:10 GMT
Subject: RFR: 8309630: Clean up tests that reference deploy modules
Message-ID: <tdJz3AeK-m0L0Nl3spOYEravTvFbNF8H6m75WAiK8-A=.00a3413b-7b26-4784-a8f7-072cd5ef35b9@github.com>

Trivial fix.   The deploy modules no longer exist.   The tests are updated not to reference them.

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

Commit messages:
 - 8309630: Clean up tests that reference deploy modules

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

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

From jjg at openjdk.org  Wed Jun  7 19:10:55 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:10:55 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <n-oEDHNS-V_hrhyTbtNAGUJLhOPuN7-8fgks4CrRM9Q=.73a0158d-1614-48b0-bff8-df89f2c46b69@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritableTaglet.java line 53:

> 51:      *
> 52:      * In the future, this could be reworked using some other mechanism,
> 53:      * such as throwing an exception.

Should `ThrowsTaglet.Failure` (eventually?) be declared here in `InheritableTaglet`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222046447

From rgiulietti at openjdk.org  Wed Jun  7 19:14:36 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 Jun 2023 19:14:36 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern() [v3]
In-Reply-To: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
Message-ID: <KbyM2xoOVEdcIuMLMitSAyj61oMH2yhWvs053D8q7n0=.aea72baf-4123-4d6c-84ad-29df59d5f678@github.com>

> The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`

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

  Added descriptions to the RuntimeExceptions in the test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14350/files
  - new: https://git.openjdk.org/jdk/pull/14350/files/dbe40b98..b505b42f

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

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

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

From jjg at openjdk.org  Wed Jun  7 19:16:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:16:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFinder.java line 54:

> 52: 
> 53:     @SuppressWarnings("serial")
> 54:     public static final class NoOverriddenMethodFound extends Exception {

General comment, for future work:
Maybe we can combine/merge/unify this exception with `ThrowsTaglet.Failure`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 671:

> 669: //                .anyMatch(t -> Objects.equals(typeUtils.asElement(t), typeUtils.asElement(t2)));
> 670: 
> 671:         return true; /* disabled for causing issues in JDK API Documentation build */

Please describe the issues and/or provide a JBS issue, so that we can decide when to revert the code to the commented-out form.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222051685
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222053011

From jjg at openjdk.org  Wed Jun  7 19:19:51 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 19:19:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2847:

> 2845:                     break;
> 2846:                 }
> 2847:                 if (isPlainInterface(peek) && !isPublic(peek) && !isLinkable(peek)) {

What is the significance of the `isPublic` check?
I'm developing a knee-jerk reaction to such checks, in the face of access-related command-line options.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222055578

From rriggs at openjdk.org  Wed Jun  7 19:47:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 7 Jun 2023 19:47:48 GMT
Subject: RFR: 8309515: Stale cached data from Matcher.namedGroups() after
 Matcher.usePattern() [v3]
In-Reply-To: <KbyM2xoOVEdcIuMLMitSAyj61oMH2yhWvs053D8q7n0=.aea72baf-4123-4d6c-84ad-29df59d5f678@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
 <KbyM2xoOVEdcIuMLMitSAyj61oMH2yhWvs053D8q7n0=.aea72baf-4123-4d6c-84ad-29df59d5f678@github.com>
Message-ID: <sZ5M15Kgnis4hpn3xXwyxNg5IytvvA71No42BAi8AGg=.05c273ce-d5b7-49fc-bb3c-488a1ca2c17a@github.com>

On Wed, 7 Jun 2023 19:14:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added descriptions to the RuntimeExceptions in the test.

LGTM, Thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14350#pullrequestreview-1468436579

From psandoz at openjdk.org  Wed Jun  7 20:29:53 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 7 Jun 2023 20:29:53 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
 <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
 <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
Message-ID: <S56-SZEG4QCJWEuSsJs16F57nyKDqIlfq2shfhW1G88=.e066640a-ed16-4919-8bfa-fab338fd204a@github.com>

On Wed, 7 Jun 2023 00:10:59 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> I believe instead of changing the guards we can change the implementation of the static methods on the concrete static VHs to call `asDirect()` (lets also add `@ForceInline` on `asDirect`), since `linkToStatic` will pass the args to the static method described by the member name (since the lazy and direct VH handles share the same var form).
>>> 
>>> That has the nice effect of pushing the complexity closer to where it is needed. Its subtle but i think can be explained. Thereby we can reduce the memory footprint for subsequent access modes. Perhaps we can even "zero" out the MH cache on initialization?
>> 
>> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.
>
>> Is this aimed at decreasing long-term invocation cost or the initial invocation cost? FYI long-term invocation is already efficient enough; if this is for initial invocation, which can potentially bypass costly MH construction, I recommend creating an alternative method to `asDirect` for the purpose to be called and casted by X-VarHandle implementations.
> 
> It aims to reduce the cost of getting to peak performance (the work that C2 has to perform) and reduce the overall memory footprint of such VHs (as long as the user does not explicitly request MHs from them). Assuming of course that the peak performance is good!
> 
> For this pattern i not sure we need to create another method returning the target that effectively does the same as `asDirect`, and instead it may come down to better naming and documentation of the concepts.
> 
> There is already a tight coupling between the `LazyInitializingVarHandle` and its target via the sharing of the var forms. Renaming `asDirect` to `target` might do it, and we refine a what a direct handle is to mean the guards just pass along the handle that is given to it, otherwise we use a (lazily created) method handle to its target. Thereby a VH implementation free to switch between indirect and direct and is further free to deal with any implementation specific indirection in its own implementation.

> @PaulSandoz Thank you for your suggestion! It might be harder to measure the time to get to peak performance, but at least for the initial invocation, the lazy VH is almost no different from the eager VH now. The old overhead was mostly from LambdaForm spinning, same for the lazy DMH overhead. 

Ok, i did not mean to suggest measuring time to peak performance, it's hard as you say. I was more thinking of an intuitive understanding of the cost (work performed by C2 and runtime memory footprint).

> Is this what you've envisioned?

Close, I was suggesting the following:
- `LazyInitializingVarHandle::target` just returns `target` and does not call `ensureInitialized`.
- Override `checkAccessModeThenIsDirect` as you did before, but returns `initialized`.
- Change only the static field var handle implementations to call `target()`, since it is unnecessary on the others.

However, i think your approach is better as it avoids any implicit MH creation. Suggest refining as follows:
- Change only the static field var handle implementations to call `target()`, since it is unnecessary on the others.
- Split `ensureInitialized` in two:

    @ForceInline
    private void ensureInitialized() {
        if (this.initialized)
            return;
        
        initialize();
    }

    private void initialize() {
        UNSAFE.ensureClassInitialized(refc);
        this.initialized = true;
        ...
    }


I am wondering if the simplest approach in `initialize` is to set the `methodHandleTable` to null?

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1581461851

From jjg at openjdk.org  Wed Jun  7 20:41:57 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 20:41:57 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 75:

> 73:         // code is OK, it likely isn't (after all, there's an unknown tag).
> 74:         setAutomaticCheckNoStacktrace(true);
> 75:         { // DocLint is on

"on" -> "explicit"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 85:

> 83:             }
> 84:         }
> 85:         // DocLint is off

"off" -> "default"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:

> 287: 
> 288:     /*
> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.

possible typo: do you mean "indirect"

test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:

> 671:      *
> 672:      * For now a warning is issued if a doc comment inherits from
> 673:      * an indirect supertype.

Not sure I agree with this. Can we discuss?

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 61:

> 59: import toolbox.ToolBox;
> 60: 
> 61: /*

Great description! :-)

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 111:

> 109:  *    built.
> 110:  */
> 111: public class TestMethodCommentsAlgorithm extends JavadocTester {

General comment for entire class:  great/clever test!

test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 273:

> 271:             }
> 272:         }
> 273:         System.err.println("Test suite root: " + p);

You might want to use `JavadocTester.out` instead of `System.err`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222117577
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222117867
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222119420
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222122630
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222124323
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222130052
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222126057

From prappo at openjdk.org  Wed Jun  7 20:51:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 20:51:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>

On Wed, 7 Jun 2023 20:29:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:
> 
>> 671:      *
>> 672:      * For now a warning is issued if a doc comment inherits from
>> 673:      * an indirect supertype.
> 
> Not sure I agree with this. Can we discuss?

Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222141331

From prappo at openjdk.org  Wed Jun  7 20:54:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 20:54:52 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <KagEZPKjNcxwtM3AHa87UQ13b8_XTWmulhVLtbnSnDk=.d297a76a-85f9-481d-8826-397eb9b768c0@github.com>
Message-ID: <k8rm3qEl5OMewrQO0KAUt7AJzBff-ERTGxvPk9gFz1s=.78a400ef-5a51-47eb-b303-1a9306bb51cd@github.com>

On Wed, 7 Jun 2023 19:13:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 671:
> 
>> 669: //                .anyMatch(t -> Objects.equals(typeUtils.asElement(t), typeUtils.asElement(t2)));
>> 670: 
>> 671:         return true; /* disabled for causing issues in JDK API Documentation build */
> 
> Please describe the issues and/or provide a JBS issue, so that we can decide when to revert the code to the commented-out form.

I mentioned it in the test, here: TestDirectedInheritance.testNotDirectSupertype. I reckon referring to code from a test is okay, but not the other way around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222148500

From prappo at openjdk.org  Wed Jun  7 21:04:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 7 Jun 2023 21:04:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <Eh-7SWOJK8iHaNnmZ_KqhiE5ZKPmNdp5SmYAZC1usOI=.a9adac42-7e06-4d02-b865-73899e52e005@github.com>
Message-ID: <jm474v09yfBS07FBRhAsNybvEs-uG3O1FCilzCRAi80=.cdf90791-5449-4bb7-b9a5-5b0e29bcef54@github.com>

On Wed, 7 Jun 2023 19:16:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2847:
> 
>> 2845:                     break;
>> 2846:                 }
>> 2847:                 if (isPlainInterface(peek) && !isPublic(peek) && !isLinkable(peek)) {
> 
> What is the significance of the `isPublic` check?
> I'm developing a knee-jerk reaction to such checks, in the face of access-related command-line options.

That directly mimics the current behaviour at addSuperInterfaces(Utils.java:802), which in turn is used at ImplementedMethods(VisibleMemberTable.java:1064) to collect overridden methods in superinterfaces. If you look around, it's quite an idiom and predates this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222173441

From mchung at openjdk.org  Wed Jun  7 21:37:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 21:37:04 GMT
Subject: RFR: 8305104: Remove old core reflection implementation
Message-ID: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>

JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.

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

Commit messages:
 - clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - 8305104: Remove the old core reflection implementation

Changes: https://git.openjdk.org/jdk/pull/14371/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305104
  Stats: 6319 lines in 78 files changed: 13 ins; 6238 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/14371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14371/head:pull/14371

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

From rgiulietti at openjdk.org  Wed Jun  7 21:42:54 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 7 Jun 2023 21:42:54 GMT
Subject: Integrated: 8309515: Stale cached data from Matcher.namedGroups()
 after Matcher.usePattern()
In-Reply-To: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
References: <bSAVygiFPtEQGhiP2zAASTAmJvD4pLvIN9Fc5BKtnAM=.8e0eeb37-d20b-41fc-a94c-465d153c296b@github.com>
Message-ID: <FJ4YQ_pyOqjwHeUXi0Swvxt1v3ZU2r2mYqA9VFjGX5U=.2cfff16d-22bb-4268-988c-7f0acba40233@github.com>

On Wed, 7 Jun 2023 11:20:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The cached `namedGroup` field must be invalidated during an invocation of `Matcher.usePattern()`

This pull request has now been integrated.

Changeset: 90027ff2
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90027ff204fcf441db6bd0076e253474631757c8
Stats:     24 lines in 2 files changed: 23 ins; 0 del; 1 mod

8309515: Stale cached data from Matcher.namedGroups() after Matcher.usePattern()

Reviewed-by: rriggs

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

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

From jjg at openjdk.org  Wed Jun  7 21:43:50 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
Message-ID: <fWqllQItWFIRLwYdEjiJEqQWJDJnjc-Pyg7o-4KkS1A=.7385e24a-3930-4132-8920-c531aa1d806c@github.com>

On Wed, 7 Jun 2023 16:02:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: make warning less scary

Great work in a difficult area overflowing with Technical Debt.

I've made various (optional) suggestions, I'll approve for now, but will look again if you want to make ore changes.

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

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1468628610

From jjg at openjdk.org  Wed Jun  7 21:43:53 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
Message-ID: <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>

On Wed, 7 Jun 2023 20:48:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 673:
>> 
>>> 671:      *
>>> 672:      * For now a warning is issued if a doc comment inherits from
>>> 673:      * an indirect supertype.
>> 
>> Not sure I agree with this. Can we discuss?
>
> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011

The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?

For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.

That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222202085

From jjg at openjdk.org  Wed Jun  7 21:43:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 7 Jun 2023 21:43:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
 <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
Message-ID: <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>

On Wed, 7 Jun 2023 21:37:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011
>
> The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?
> 
> For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.
> 
> That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.

> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: [#14357 (comment)](https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011)

Thanks for tying these together; I had not realized they were related.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222203243

From mchung at openjdk.org  Wed Jun  7 22:02:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 7 Jun 2023 22:02:57 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
Message-ID: <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>

> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.

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

  fix merge issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14371/files
  - new: https://git.openjdk.org/jdk/pull/14371/files/73340aa9..d161a384

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

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

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

From liach at openjdk.org  Wed Jun  7 22:44:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Jun 2023 22:44:55 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v10]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <i6QYl9diQrKofbplXetUv_OdLw4e1JQua_mrLtm76L8=.fbda24a2-b6b9-4d1f-9f2c-f05f87cc8272@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> Benchmark                                            Mode  Cnt   Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op

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

  Split ensureInitialized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/f414e8f8..acca36fe

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

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

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

From liach at openjdk.org  Wed Jun  7 22:44:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 7 Jun 2023 22:44:57 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <S56-SZEG4QCJWEuSsJs16F57nyKDqIlfq2shfhW1G88=.e066640a-ed16-4919-8bfa-fab338fd204a@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
 <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
 <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
 <S56-SZEG4QCJWEuSsJs16F57nyKDqIlfq2shfhW1G88=.e066640a-ed16-4919-8bfa-fab338fd204a@github.com>
Message-ID: <W0RyQjyVAvl4Zl-k1Sek_owVO1fW6FDunNZP92kxyTI=.af4934b9-0dbd-4430-8ef3-68a5f697d6ba@github.com>

On Wed, 7 Jun 2023 20:26:47 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Change only the static field var handle implementations to call `target()`, since it is unnecessary on the others.

Unfortunately, I don't think there is a convenient way for VH implementations to easily unwrap the correct VH; a `target()` call is more convenient than an extra instanceof check and cast and get.

> I am wondering if the simplest approach in `initialize` is to set the `methodHandleTable` to null?

I update the entries in the table because they are already created and potentially live on the heap or stack. Those entries should benefit from the post-initialization performance benefits as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1581603143

From dnsimon at openjdk.org  Wed Jun  7 22:56:23 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Jun 2023 22:56:23 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v2]
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <RKg92IA8q1w2rS0wZkn4PI6bdV9BxKXKfgojtZ0E7Mg=.c855a47e-5d7f-465b-b5b4-3b893aab2f29@github.com>

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real  ...

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - [skip ci] snapshot Arguments::system_properties() in JVMCI instead of System.savedProps
 - more efficient copying of system properties into libjvmci

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

Changes: https://git.openjdk.org/jdk/pull/14291/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=01
  Stats: 277 lines in 17 files changed: 103 ins; 89 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/14291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14291/head:pull/14291

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

From dnsimon at openjdk.org  Wed Jun  7 22:56:23 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Jun 2023 22:56:23 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <jI7pi5CA0yiTEDJBM9R8tPw3pRT6jvNm38rHCReSjCg=.51e0735a-8625-4254-859f-0246fa3425e2@github.com>

On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real  ...

Ok, I've pushed a change with your suggestion Tom and it seems to work. It assumes `Arguments::system_properties()` is fully initialized and effectively read-only by the time `JVMCIEnv::init_saved_properties` is called.

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

PR Comment: https://git.openjdk.org/jdk/pull/14291#issuecomment-1581611494

From dnsimon at openjdk.org  Wed Jun  7 22:56:23 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 7 Jun 2023 22:56:23 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v2]
In-Reply-To: <RKg92IA8q1w2rS0wZkn4PI6bdV9BxKXKfgojtZ0E7Mg=.c855a47e-5d7f-465b-b5b4-3b893aab2f29@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <RKg92IA8q1w2rS0wZkn4PI6bdV9BxKXKfgojtZ0E7Mg=.c855a47e-5d7f-465b-b5b4-3b893aab2f29@github.com>
Message-ID: <3jeOthuzzSjWn2lHwJmkJGK3gzuK7JutCyQDoo4xrKQ=.577bc443-26fc-4da1-9143-1a00bc4c5d91@github.com>

On Wed, 7 Jun 2023 22:51:48 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
>> 
>> ## Times
>> 
>> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
>> 
>> 
>> public class Nop {
>>     public static void main(String[] args) {}
>> }
>> 
>> 
>> (1) Baseline (no options):
>> 
>>> for i in (seq 10); java Nop; end
>>         0.05 real         0.04 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.00 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>> 
>> 
>> (2) Eagerly initialize libgraal (with PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.06 real         0.04 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>> 
>> 
>> (3) Eagerly initialize libgraal (without PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.11 real         0.08 user         0.02 sys
>>         0.08 real         0.06 user         0.01 sys
>>         0.08 real         0.07 user         0.01 sys
>>         0.10 real         0.07 user         0.01 sys
>>         0.08 real         0.06 user         0.01 sys
>>         0.10 real         0.07 user         0.01 sys
>>         0.08 real         0.07 user         0.01 sys
>>         0.08 real     ...
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - [skip ci] snapshot Arguments::system_properties() in JVMCI instead of System.savedProps
>  - more efficient copying of system properties into libjvmci

src/hotspot/share/jvmci/jvmciJavaClasses.hpp line 60:

> 58:                          jvmci_constructor) \
> 59:   start_class(Services, jdk_vm_ci_services_Services)                                                          \
> 60:     jvmci_method(CallStaticVoidMethod, GetStaticMethodID, call_static, void, Services, initializeSavedProperties, byte_array_void_signature, (JVMCIObject serializedProperties)) \

The final arg for the `jvmci_method` macro is never used so I removed it everywhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14291#discussion_r1222257086

From bchristi at openjdk.org  Thu Jun  8 00:03:47 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 8 Jun 2023 00:03:47 GMT
Subject: RFR: 8309630: Clean up tests that reference deploy modules
In-Reply-To: <tdJz3AeK-m0L0Nl3spOYEravTvFbNF8H6m75WAiK8-A=.00a3413b-7b26-4784-a8f7-072cd5ef35b9@github.com>
References: <tdJz3AeK-m0L0Nl3spOYEravTvFbNF8H6m75WAiK8-A=.00a3413b-7b26-4784-a8f7-072cd5ef35b9@github.com>
Message-ID: <6gIwqDW8XyZwsxxDdsB-7E9sAuS2TOeiLPAdzm4bglY=.9fb94e17-2c6c-4845-9c16-b980c1ed1e3a@github.com>

On Wed, 7 Jun 2023 19:03:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.   The deploy modules no longer exist.   The tests are updated not to reference them.

Looks fine.

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

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14367#pullrequestreview-1468750248

From psandoz at openjdk.org  Thu Jun  8 00:15:51 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 8 Jun 2023 00:15:51 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <W0RyQjyVAvl4Zl-k1Sek_owVO1fW6FDunNZP92kxyTI=.af4934b9-0dbd-4430-8ef3-68a5f697d6ba@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
 <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
 <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
 <S56-SZEG4QCJWEuSsJs16F57nyKDqIlfq2shfhW1G88=.e066640a-ed16-4919-8bfa-fab338fd204a@github.com>
 <W0RyQjyVAvl4Zl-k1Sek_owVO1fW6FDunNZP92kxyTI=.af4934b9-0dbd-4430-8ef3-68a5f697d6ba@github.com>
Message-ID: <GxrDeUu1DgHfkViqMUjd_YK_Av9sQqQfWAErXcI-CxY=.c881bbc9-4584-4ec3-be93-064941e51fe9@github.com>

On Wed, 7 Jun 2023 22:38:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> > Change only the static field var handle implementations to call `target()`, since it is unnecessary on the others.
> 
> Unfortunately, I don't think there is a convenient way for VH implementations to easily unwrap the correct VH; a `target()` call is more convenient than an extra instanceof check and cast and get.
> 

We don't need to update *all* VH implementations to call target. We only need to update the static field VH implementations which we know may be passed an instance of `LazyInitializingVarHandle` or its concrete instance.


> > I am wondering if the simplest approach in `initialize` is to set the `methodHandleTable` to null?
> 
> I update the entries in the table because they are already created and potentially live on the heap or stack. Those entries should benefit from the post-initialization performance benefits as well.

Ok, yes, it's less likely now but possible a MH has been explicitly obtained before the defining class has been intialized. In this case I still think we can clear the table out after processing any existing entries, since subsequent requests for MHs after initialization will defer to the target's method handle table.

We will need some tests covering this edge case.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1581684274

From jiangli at openjdk.org  Thu Jun  8 00:29:14 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 8 Jun 2023 00:29:14 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v6]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <mbFWQnL7BoZSoUD2-3H0VnkR4wj1fLtMVQGgaOxFBUc=.fda0de0b-32df-4eab-8028-610a26e32418@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - Clean up.
 - In clude $MACHINE_FLAG in partial linking flag.
 - Use '-m32' instead of '-m elf_i386'.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/90027ff2...1c2f75dc

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

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=05
  Stats: 223 lines in 10 files changed: 172 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

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

From darcy at openjdk.org  Thu Jun  8 00:37:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Jun 2023 00:37:07 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>

> Time to get JDK 22 underway...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Update wording to be consistent with JDK-8295071.
 - Merge branch 'master' into JDK-8306584
 - Update wording of new constant to be consistent with JDK-8309554.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

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

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=05
  Stats: 5954 lines in 69 files changed: 5902 ins; 0 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

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

From duke at openjdk.org  Thu Jun  8 00:54:28 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 8 Jun 2023 00:54:28 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v9]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:

  Follow CSR description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/840cd7dc..5b230746

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

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

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

From bpb at openjdk.org  Thu Jun  8 00:57:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jun 2023 00:57:50 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v9]
In-Reply-To: <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
Message-ID: <XPINcZ0qfj_iRWM-IE42l_c64qQkITRfPj3QRaGVKf8=.c425553c-8ff6-4ae9-aa8a-66499c7e0e90@github.com>

On Thu, 8 Jun 2023 00:54:28 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Follow CSR description

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13526#pullrequestreview-1468800804

From duke at openjdk.org  Thu Jun  8 00:57:52 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 8 Jun 2023 00:57:52 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <OwIoMoOeVpJ_uCr9Vl80NwebjCS9A3Hoxdvw_MZISX4=.8e8bf00c-2f3f-4ef0-8483-0a80d8e83c07@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
 <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>
 <1B_vjAxLnuMVEPMuz9EyMWRRwFomFGSpyaACzD1732k=.e76b095a-fd90-4350-a3b4-e3751ca5bc87@github.com>
 <OwIoMoOeVpJ_uCr9Vl80NwebjCS9A3Hoxdvw_MZISX4=.8e8bf00c-2f3f-4ef0-8483-0a80d8e83c07@github.com>
Message-ID: <1EiHHSxfgjzJXb6rw0fFd4TTaju4SBv4XzCAm9dAPc8=.f48fd6f8-b0e2-4475-83fd-df30a44d1f35@github.com>

On Wed, 7 Jun 2023 17:47:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The CSR is updated so it's focused on the two parts of the updated docs. So I think you can finalize.
>
>> I think you can finalize.
> 
> @Nagata-Haruhito I took the liberty of finalizing the CSR. If you would make the requested changes (change "the root directory" to "a root directory") in the two classes, then we can approve it and hopefully get this integrated before the JDK 21 fork.

Thank you very match. I changed as follow the CSR description.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1222326058

From bpb at openjdk.org  Thu Jun  8 00:57:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jun 2023 00:57:53 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <1EiHHSxfgjzJXb6rw0fFd4TTaju4SBv4XzCAm9dAPc8=.f48fd6f8-b0e2-4475-83fd-df30a44d1f35@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
 <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>
 <1B_vjAxLnuMVEPMuz9EyMWRRwFomFGSpyaACzD1732k=.e76b095a-fd90-4350-a3b4-e3751ca5bc87@github.com>
 <OwIoMoOeVpJ_uCr9Vl80NwebjCS9A3Hoxdvw_MZISX4=.8e8bf00c-2f3f-4ef0-8483-0a80d8e83c07@github.com>
 <1EiHHSxfgjzJXb6rw0fFd4TTaju4SBv4XzCAm9dAPc8=.f48fd6f8-b0e2-4475-83fd-df30a44d1f35@github.com>
Message-ID: <mMJE3VXPUraPO68HFu4PSO-C5So33iITgR9XR6sZ_C0=.cfd01bba-7ac9-44e4-b3f1-8160aa267ca6@github.com>

On Thu, 8 Jun 2023 00:53:18 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

> Thank you very match. I changed as follow the CSR description.

Thank you. I have approved the PR so I think you can integrate now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1222327170

From mchung at openjdk.org  Thu Jun  8 01:04:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 01:04:06 GMT
Subject: Integrated: 8309630: Clean up tests that reference deploy modules
In-Reply-To: <tdJz3AeK-m0L0Nl3spOYEravTvFbNF8H6m75WAiK8-A=.00a3413b-7b26-4784-a8f7-072cd5ef35b9@github.com>
References: <tdJz3AeK-m0L0Nl3spOYEravTvFbNF8H6m75WAiK8-A=.00a3413b-7b26-4784-a8f7-072cd5ef35b9@github.com>
Message-ID: <-ImTUClnge94C3vSfxTHQz1gnKYWfe928eFSZFJdAjw=.28d526c7-73f5-4698-827b-29c020910787@github.com>

On Wed, 7 Jun 2023 19:03:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Trivial fix.   The deploy modules no longer exist.   The tests are updated not to reference them.

This pull request has now been integrated.

Changeset: e8a59843
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8a59843f21e347ba1494290c393ef7b344e3b70
Stats:     20 lines in 2 files changed: 0 ins; 15 del; 5 mod

8309630: Clean up tests that reference deploy modules

Reviewed-by: bchristi

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

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

From liach at openjdk.org  Thu Jun  8 01:32:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 01:32:20 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v5]
In-Reply-To: <GxrDeUu1DgHfkViqMUjd_YK_Av9sQqQfWAErXcI-CxY=.c881bbc9-4584-4ec3-be93-064941e51fe9@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <RCJiP6MwuSZngej-XpOqC4Yc8nO4aSjCien6sjC3ujQ=.ce464a75-60bf-4920-a116-d8755e6ef525@github.com>
 <6lpkAjfDuU46l1k6iDWwuNhFgaxkLICRQNv5Sxh3U-Q=.957d4c50-5ee9-468c-b092-248dfbd56153@github.com>
 <X5Bu7TvNHfi_I8DiaVqxVD7b3Z5HQXeoivoadDxhRog=.79257727-9ae7-40ac-a2af-75613196392c@github.com>
 <gIp9xn1ojELcqe9JO17e7tStIMu_160pKNL3vu8xl5Q=.0e98ce9e-2050-491c-b17f-f2c3c0aab063@github.com>
 <T09m-miEm-LvOdz3k8rN9serLPFsBJiN73gQHfV4nwc=.0cf1e7cf-ae6f-44ef-acc5-396436f3c096@github.com>
 <-kOBGesTZAI0Gq7kG8AlOYlyilTDv03nIAi9mpuDv7s=.258247ca-a044-4407-b2df-e86fae1b22b4@github.com>
 <S56-SZEG4QCJWEuSsJs16F57nyKDqIlfq2shfhW1G88=.e066640a-ed16-4919-8bfa-fab338fd204a@github.com>
 <W0RyQjyVAvl4Zl-k1Sek_owVO1fW6FDunNZP92kxyTI=.af4934b9-0dbd-4430-8ef3-68a5f697d6ba@github.com>
 <GxrDeUu1DgHfkViqMUjd_YK_Av9sQqQfWAErXcI-CxY=.c881bbc9-4584-4ec3-be93-064941e51fe9@github.com>
Message-ID: <dGYHOHtsJiV1sGPamJvAMmS0QkSuzAmfJ65Kq9eIVK8=.1caca4b7-d7fe-4f27-abd8-65d8eae90fcf@github.com>

On Thu, 8 Jun 2023 00:12:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Ok, yes, it's less likely now but possible a MH has been explicitly obtained before the defining class has been intialized. In this case I still think we can clear the table out after processing any existing entries, since subsequent requests for MHs after initialization will defer to the target's method handle table.

I think I can just replace the lazy VH's MH table with that of the target, as whatever this table's cache has the target table does as well (due to our getMethodHandleUncached delegation). This is effectively GCing the old table as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1581752314

From liach at openjdk.org  Thu Jun  8 01:32:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 01:32:20 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v11]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> Benchmark                                            Mode  Cnt   Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op

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

  Remove meaningless target calls and clear outdated cache as needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/acca36fe..6a7a41ae

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

  Stats: 126 lines in 4 files changed: 1 ins; 1 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

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

From liach at openjdk.org  Thu Jun  8 01:39:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 01:39:50 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
Message-ID: <OvhuNp0K7qeTpuBujW0ayqA5hlw6q6XXYdbldXKSp0I=.56787c71-7f4a-4e9b-99c5-c04f6a2ebb9c@github.com>

On Wed, 7 Jun 2023 22:02:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge issue

test/jdk/java/lang/reflect/Field/NegativeTest.java line 27:

> 25:  * @test
> 26:  * @bug 8277451
> 27:  * @run testng/othervm NegativeTest

Does this still need othervm if it doesn't set system properties?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1222350708

From dholmes at openjdk.org  Thu Jun  8 01:53:52 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jun 2023 01:53:52 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
Message-ID: <99mbKbiEdzbFp3PyMA-I8UX3LPWriM6PZFX3itSTObw=.c3238b5d-1552-4455-8ebb-923ccd60480d@github.com>

On Wed, 7 Jun 2023 22:02:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge issue

Hotspot code and test changes look fine. Thanks.

src/hotspot/share/classfile/verifier.cpp line 298:

> 296:     // NOTE: this is called too early in the bootstrapping process to be
> 297:     // guarded by Universe::is_gte_jdk14x_version().
> 298:     // Also for lambda generated code, gte jdk8

While you are here could you delete these version comments please - they are meaningless these days. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14371#pullrequestreview-1468854747
PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1222355124

From bpb at openjdk.org  Thu Jun  8 02:50:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jun 2023 02:50:49 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v8]
In-Reply-To: <mMJE3VXPUraPO68HFu4PSO-C5So33iITgR9XR6sZ_C0=.cfd01bba-7ac9-44e4-b3f1-8160aa267ca6@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <DBPr-pTGJsTsS_TNceYV92CDG7oakIZYXkf9JVgPwio=.67fa6823-9c28-48e5-b39a-2eab94b73b5c@github.com>
 <eysIyhVYftRHZoqGjQnmvcJXsq2L4sFYlScgCeh6zL0=.a06ae956-fce9-45ee-81d7-971276d993ab@github.com>
 <1B_vjAxLnuMVEPMuz9EyMWRRwFomFGSpyaACzD1732k=.e76b095a-fd90-4350-a3b4-e3751ca5bc87@github.com>
 <OwIoMoOeVpJ_uCr9Vl80NwebjCS9A3Hoxdvw_MZISX4=.8e8bf00c-2f3f-4ef0-8483-0a80d8e83c07@github.com>
 <1EiHHSxfgjzJXb6rw0fFd4TTaju4SBv4XzCAm9dAPc8=.f48fd6f8-b0e2-4475-83fd-df30a44d1f35@github.com>
 <mMJE3VXPUraPO68HFu4PSO-C5So33iITgR9XR6sZ_C0=.cfd01bba-7ac9-44e4-b3f1-8160aa267ca6@github.com>
Message-ID: <i6LwNxev2umDCJ2RSNTwvFUy8TDb7KgCYQpPXVcgE-A=.eca27595-3b02-458e-b521-c0aee2a6aaaf@github.com>

On Thu, 8 Jun 2023 00:54:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Thank you. I have approved the PR so I think you can `/integrate` now.

It needs to be `/integrate`d before I can `/sponsor` it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1222383959

From duke at openjdk.org  Thu Jun  8 04:00:34 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 8 Jun 2023 04:00:34 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v9]
In-Reply-To: <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
Message-ID: <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>

On Thu, 8 Jun 2023 00:54:28 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Follow CSR description

Thank you for your many help. I try to sync fork to solve GHA failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1581850037

From duke at openjdk.org  Thu Jun  8 04:00:31 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 8 Jun 2023 04:00:31 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v10]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

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

 - Merge branch 'openjdk:master' into File_javadoc
 - Follow CSR description
 - Refer review comment
 - Move SecurityException paragraph
 - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
 - Merge branch 'openjdk:master' into File_javadoc
 - Merge branch 'openjdk:master' into File_javadoc
 - Drop exist to available
 - Merge branch 'master' into File_javadoc
 - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
 - ... and 1 more: https://git.openjdk.org/jdk/compare/2a65ba10...fe3d1573

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/5b230746..fe3d1573

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

  Stats: 113072 lines in 2134 files changed: 83044 ins; 17253 del; 12775 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

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

From bpb at openjdk.org  Thu Jun  8 04:49:52 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jun 2023 04:49:52 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v9]
In-Reply-To: <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
 <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>
Message-ID: <ldNTCfE-Qi4X8QgNxZTz59TPyk-4zLHwwNx9uul5dxU=.a9e3143b-6ecc-40fd-8831-ed5c30aa0a3a@github.com>

On Thu, 8 Jun 2023 03:53:06 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Follow CSR description
>
> Thank you for your many help. I try to sync fork to solve GHA failure.

@Nagata-Haruhito Thank you very much for your contribution!

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1581884641

From bpb at openjdk.org  Thu Jun  8 04:52:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jun 2023 04:52:50 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v9]
In-Reply-To: <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
 <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>
Message-ID: <aWPi78Sn9ex1WHxX1dcbvz1VmYtEfjOZ5N2_2OSFmrE=.766f39ce-0626-4f67-9636-62366b06b17d@github.com>

On Thu, 8 Jun 2023 03:53:06 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Follow CSR description
>
> Thank you for your many help. I try to sync fork to solve GHA failure.

@Nagata-Haruhito Per the message you need to re-`/integrate`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1581886285

From bpb at openjdk.org  Thu Jun  8 04:57:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Jun 2023 04:57:50 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v9]
In-Reply-To: <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <lrjYkVH8W8A3URqteJTZehUdgvwvgFrSsrx4H04u4rw=.f1d6402a-768c-430c-a5ad-8938cc824be5@github.com>
 <ZRVigRrGdOBYeLmnQy0fgXIkWTKq6NaB9JWQkl3yq6E=.e350058a-a888-412d-90cf-4a87ce6d2983@github.com>
Message-ID: <v0xtw6KVNz_hhwjoSeJt4mXmC_XaJlbLKBTAl_oMUYU=.0188dc7d-0b57-4c70-9c0d-5d0317759ed8@github.com>

On Thu, 8 Jun 2023 03:53:06 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Follow CSR description
>
> Thank you for your many help. I try to sync fork to solve GHA failure.

> @Nagata-Haruhito Per the message you need to re-`/integrate`.

I pulled the fork and the docs, jdk, and images targets all build without problems.

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1581888754

From alanb at openjdk.org  Thu Jun  8 05:03:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 05:03:53 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v10]
In-Reply-To: <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>
Message-ID: <1bqGdfWMl5zUcHJ4nXjbBRYBAFmrr0CY7Ba4KmXZuqc=.68f1c45f-1b32-4ee8-83ce-dcc546a0dd97@github.com>

On Thu, 8 Jun 2023 04:00:31 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Follow CSR description
>  - Refer review comment
>  - Move SecurityException paragraph
>  - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Drop exist to available
>  - Merge branch 'master' into File_javadoc
>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8c70fa45...fe3d1573

You pushed a sync up of your branch and the bots removed the "sponsor" label, you need to "/integrate" again.

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1581893687

From alanb at openjdk.org  Thu Jun  8 05:55:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 05:55:56 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v10]
In-Reply-To: <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>
Message-ID: <eaXQ8hpXzuNZhud5-xdaNNFOxpi2Pmp-Dpc2zvUwLmU=.af9f08b1-91ee-4c38-9bbe-b65f422093ba@github.com>

On Thu, 8 Jun 2023 04:00:31 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Follow CSR description
>  - Refer review comment
>  - Move SecurityException paragraph
>  - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Drop exist to available
>  - Merge branch 'master' into File_javadoc
>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/25da80f6...fe3d1573

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13526#pullrequestreview-1469052090

From duke at openjdk.org  Thu Jun  8 07:00:55 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 8 Jun 2023 07:00:55 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v10]
In-Reply-To: <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <O_zQ39RXWUduJDoSCo02gqQyOpb2yshlbl9vjVwZHnQ=.5166e933-d148-4dff-94df-354d7ef1dfe2@github.com>
Message-ID: <jWJ7EpR02OKdbkLqZdQhnRRhiTYJJfayxn40Gnx9QTc=.f1772285-b4c2-435a-b37c-f59cb829bfce@github.com>

On Thu, 8 Jun 2023 04:00:31 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Follow CSR description
>  - Refer review comment
>  - Move SecurityException paragraph
>  - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - Drop exist to available
>  - Merge branch 'master' into File_javadoc
>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/cc32891e...fe3d1573

Sorry. I retyped `/integrate`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1581993322

From duke at openjdk.org  Thu Jun  8 07:06:58 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Thu, 8 Jun 2023 07:06:58 GMT
Subject: Integrated: 8306431: File.listRoots method description should be
 re-examined
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <oo9TJeSkCglCfcRRstTHd1w-YLn5aCRjEt9o4C2jMn0=.34d4d26c-1b4e-4531-9396-194e0757b3c2@github.com>

On Wed, 19 Apr 2023 07:34:30 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

This pull request has now been integrated.

Changeset: 9d64a9d2
Author:    Nagata-Haruhito <84066412+Nagata-Haruhito at users.noreply.github.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d64a9d22034602d2d195463093268102a583f9f
Stats:     28 lines in 2 files changed: 15 ins; 11 del; 2 mod

8306431: File.listRoots method description should be re-examined

Reviewed-by: bpb, alanb

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

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

From asotona at openjdk.org  Thu Jun  8 07:23:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 07:23:56 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
Message-ID: <LE0IcfAzIUdOrK4OrpQoyIicrvRzvfzSY-0tDrTgHuQ=.cc726fb0-a761-44f0-a2ea-a16a38da264d@github.com>

On Wed, 7 Jun 2023 14:15:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Review changes, fixed tests
>  - Merge branch 'master' into hierarchy-resolve
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/a1ab377d...90645b6f

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13082#pullrequestreview-1469177981

From liach at openjdk.org  Thu Jun  8 07:29:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 07:29:52 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
Message-ID: <4SP2a5mkMsrparZMalgkb9BIltgk0dTfropxCzjKgrw=.a62b6d06-fd3c-4497-ad74-98f11e723013@github.com>

On Wed, 7 Jun 2023 14:15:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Review changes, fixed tests
>  - Merge branch 'master' into hierarchy-resolve
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/a1ab377d...90645b6f

Integrating this before #14180. The test failure appears to be unrelated from ScopedValues, which is not related to this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13082#issuecomment-1582042622

From liach at openjdk.org  Thu Jun  8 07:32:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 07:32:57 GMT
Subject: Integrated: 8304425: ClassHierarchyResolver from Reflection
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: <7ASxsfkPoKmQwecb-rCSa4tTp6AGCBocwGQHuD9Wb0Q=.5e7e0487-b962-4d8f-8c54-1bc6ab2a6d5c@github.com>

On Fri, 17 Mar 2023 18:18:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

This pull request has now been integrated.

Changeset: ac3ce2bf
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac3ce2bf759735042480b846f3c1cf37a0843b8d
Stats:     401 lines in 10 files changed: 304 ins; 29 del; 68 mod

8304425: ClassHierarchyResolver from Reflection

Reviewed-by: asotona

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

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

From jwaters at openjdk.org  Thu Jun  8 07:45:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 07:45:53 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <6x5TNtFwNDmFEx3WL4_uB-PLyFGgi9T0s4rMKEC-iVI=.120ae51e-3d33-46cd-97ce-6cb6b7bde452@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Anyone?

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1582065715

From jwaters at openjdk.org  Thu Jun  8 07:45:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 07:45:53 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <uMc6HjzFQDaaJKL5x2nU2Fa3cxfJzXPzTrAvYlEmDCc=.3beabc5d-eb39-4e5f-8100-7dc797a23a86@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Anyone?

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

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1582066068

From prappo at openjdk.org  Thu Jun  8 08:18:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:18:11 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v3]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <dMVI5gkY6g1Rua907np654TLzSOFYYSVuFUmj3OxI_Y=.eeb25216-e583-40f0-9f7f-5a2d095039ce@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

 - Merge branch 'master' into 8285368
 - feedback: make warning less scary
 - Disable problematic check
   
   This check is well-intended but problematic for JDK API Documentation
   build, which errors on warnings.
 - Counterbalance changes to method comments algorithm
   
   The changes are in the JDK API Documentation.
 - Improve diagnostics
 - Update method comments algorithm
 - Implement directed documentation inheritance

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/c0fc69c2..011d7982

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

  Stats: 17117 lines in 199 files changed: 16677 ins; 145 del; 295 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

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

From prappo at openjdk.org  Thu Jun  8 08:43:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:43:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v4]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <YCoswj2IrhNiZsAIFLp0fYU3rZiMj7nlywtP_JanSRw=.274888fc-181c-42a6-886e-416bc89d505d@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: use utils directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/011d7982..d579a83c

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

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

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

From prappo at openjdk.org  Thu Jun  8 08:43:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 08:43:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <vbjeNBm9q-RAtXNUM4Ely_r2OsXFUtz5Xe-QRrFiZPw=.551424dd-0bd1-47f6-b379-c56f23d3d46b@github.com>
Message-ID: <0nAoH6Na1dRqIGEGYd2-DpPBZb7AfdjApu40jdUkmzM=.37205779-ae2f-4577-86a8-8e8d592e7576@github.com>

On Wed, 7 Jun 2023 18:55:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/InheritDocTaglet.java line 110:
> 
>> 108:             for (Element e : methods) {
>> 109:                 ExecutableElement m = (ExecutableElement) e;
>> 110:                 if (configuration.utils.elementUtils.overrides(method, m, (TypeElement) method.getEnclosingElement())) {
> 
> Note that `configuration.utils` is available as `utils`

Done in d579a83cc4a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222652470

From alanb at openjdk.org  Thu Jun  8 08:45:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 08:45:50 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
Message-ID: <Jz1wwHnNhx_Uhu7FHJSxaBCVdR99zIW0drCe5Vk1PHE=.48129341-8f01-44bc-83ad-fd5450432307@github.com>

On Wed, 7 Jun 2023 22:02:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge issue

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 578:

> 576:     // then switch to the bytecode-based implementations.
> 577: 
> 578:     private static final Config DEFAULT_CONFIG = new Config(false, // useNativeAccessorOnly

The block comment just before this will need updating.  There's another one in Config.config where it uses the default/native implementation in early startup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1222659670

From alanb at openjdk.org  Thu Jun  8 08:50:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 08:50:48 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
Message-ID: <aT1WJuulwlYuhseqqJb7IDIGVH98moEZCepkIjsdaZU=.bab0c32c-4ecc-434b-92b2-b63aaf50ae0b@github.com>

On Wed, 7 Jun 2023 22:02:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge issue

The  old + new implementations have been in four releases, which is good for shaking out any regressions/issues. Removing the old implementation in JDK 22 is good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14371#pullrequestreview-1469340126

From asotona at openjdk.org  Thu Jun  8 09:26:10 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 09:26:10 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> 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 29 commits:

 - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
   introduction of ClassHierarchyResolver::ofSystem factory method
   ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
 - Merge branch 'master' into JDK-8308899-context
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
   #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
   #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
   #	test/jdk/jdk/classfile/VerifierSelfTest.java
 - Merge branch 'master' into JDK-8308899-context
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
   #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
   #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
   #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - added missing javadoc
 - simplified options names
 - fixed copyright header
 - Merge branch 'master' into JDK-8308899-context
 - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
 - Merge branch 'master' into JDK-8308899-context
 - fixed benchmarks
 - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842

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

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=07
  Stats: 1651 lines in 109 files changed: 501 ins; 244 del; 906 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

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

From prappo at openjdk.org  Thu Jun  8 09:26:17 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:26:17 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>

On Wed, 7 Jun 2023 20:23:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 75:
> 
>> 73:         // code is OK, it likely isn't (after all, there's an unknown tag).
>> 74:         setAutomaticCheckNoStacktrace(true);
>> 75:         { // DocLint is on
> 
> "on" -> "explicit"

Done in 93adde63ed0.

> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 85:
> 
>> 83:             }
>> 84:         }
>> 85:         // DocLint is off
> 
> "off" -> "default"

Done in 93adde63ed0.

> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:
> 
>> 287: 
>> 288:     /*
>> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.
> 
> possible typo: do you mean "indirect"

I'm neither a grammarian nor a native English speaker, but my hunch is that _indirect_ would be wrong here. But again, I'm open to corrections.

I believe "directed inhertiance" came from an analogy with the graph theory, where a graph can be directed and undirected. The former has pointy arrows, the latter does not.

By that analogy, documentation inheritance can be directed `{@inheritDoc <FQN>}` (I choose), or undirected `{@inheritDoc}` (JavaDoc chooses / I'm Feeling Lucky). In addition to that, documentation inheritance can be implicit (i.e. by omission), which works the same way as undirected but without extra keystrokes.

While those concepts are lacking better names, can I suggest we use the following almost-made-up adverbs: _directedly_ and _undirectedly_? As a side note, we badly need a JavaDoc vocabulary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222703693
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222703773
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222700845

From prappo at openjdk.org  Thu Jun  8 09:26:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:26:16 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v5]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: DocLint terminology

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/d579a83c..93adde63

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

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

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

From alanb at openjdk.org  Thu Jun  8 09:27:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 09:27:54 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
Message-ID: <XMUO9juJRbeMiMQXX-5eAGeLVs2T8FbD8cmt0l4YMR8=.71b77e07-cd8a-4ba8-9a62-5c09de82ed76@github.com>

On Thu, 8 Jun 2023 00:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Update wording to be consistent with JDK-8295071.
>  - Merge branch 'master' into JDK-8306584
>  - Update wording of new constant to be consistent with JDK-8309554.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

Ready to go :-)

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

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1469406598

From alanb at openjdk.org  Thu Jun  8 09:27:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 09:27:56 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly resets
 interrupt status
Message-ID: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>

Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.

This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.

Testing: tier1-5

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

Commit messages:
 - Merge
 - Initial commit

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

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

From prappo at openjdk.org  Thu Jun  8 09:31:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:31:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v6]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <eBdzCAsFsRLgFpL57dGSEb6JSNCFN97DG66FfGhcIc0=.a1c66346-3faf-4e61-99cb-ea346c546dcd@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  suggestion: vocabulary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/93adde63..3da4f473

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

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

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

From prappo at openjdk.org  Thu Jun  8 09:31:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:31:11 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <Qhqev-aIAx8R4MLjC447r5JJ4l1N6rxJG_loDZL5Hso=.b9b27c67-6adb-4046-812e-1813e2f0cedb@github.com>
Message-ID: <dW06V3UKubxH8ow0uco0U7JqH-03Yos7o2nVtR17biY=.558d5dca-e1cf-4a06-8f0c-5be1ba6b89cf@github.com>

On Thu, 8 Jun 2023 09:18:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> test/langtools/jdk/javadoc/doclet/testDirectedInheritance/TestDirectedInheritance.java line 289:
>> 
>>> 287: 
>>> 288:     /*
>>> 289:      * C1.m inherits documentation from B1.m explicitly and undirect.
>> 
>> possible typo: do you mean "indirect"
>
> I'm neither a grammarian nor a native English speaker, but my hunch is that _indirect_ would be wrong here. But again, I'm open to corrections.
> 
> I believe "directed inhertiance" came from an analogy with the graph theory, where a graph can be directed and undirected. The former has pointy arrows, the latter does not.
> 
> By that analogy, documentation inheritance can be directed `{@inheritDoc <FQN>}` (I choose), or undirected `{@inheritDoc}` (JavaDoc chooses / I'm Feeling Lucky). In addition to that, documentation inheritance can be implicit (i.e. by omission), which works the same way as undirected but without extra keystrokes.
> 
> While those concepts are lacking better names, can I suggest we use the following almost-made-up adverbs: _directedly_ and _undirectedly_? As a side note, we badly need a JavaDoc vocabulary.

Have a look at this commit: 3da4f473a7c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222709203

From dfuchs at openjdk.org  Thu Jun  8 09:36:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Jun 2023 09:36:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v5]
In-Reply-To: <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <bzy-mOnpcNQGfDeJiKXWPWNdQUbwA5Gr9UEA1wBbQvc=.c733051a-cd1e-482b-b248-e06610c2f7da@github.com>
Message-ID: <PLCf0TKvR88eBAkckrd1Er8kTIju2SRe3KrpF937NRY=.aa620b43-011b-4c94-baf5-31d72fe881e3@github.com>

On Thu, 8 Jun 2023 09:26:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: DocLint terminology

I will only comment on the changes to the `java.base` classes.

I had a look at the changes to these and they looked right to me. Though I?m not an expert on collections it seemed that you picked the right ?semantically closer parent? to inherit from.
Probably @stuart-marks  could give a more authoritative opinion.

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

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1469424115

From dholmes at openjdk.org  Thu Jun  8 09:41:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jun 2023 09:41:49 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
Message-ID: <GZXj55PI5Ly58RmlW-Jn1fZiUpXNFRZv0DosDAcrjgw=.8ed39919-fbf8-4a63-8cbe-5bb03e955104@github.com>

On Wed, 7 Jun 2023 15:12:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.
> 
> This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.
> 
> Testing: tier1-5

src/java.base/share/classes/java/lang/VirtualThread.java line 879:

> 877:         boolean oldValue = interrupted;
> 878:         if (oldValue) {
> 879:             synchronized (interruptLock) {

Don't you still need to read under the lock to synchronize with the interrupt method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14361#discussion_r1222725444

From prappo at openjdk.org  Thu Jun  8 09:55:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:55:27 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

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

  feedback: remove unduly restrictive warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/3da4f473..dea776e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=05-06

  Stats: 126 lines in 5 files changed: 0 ins; 126 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

PR: https://git.openjdk.org/jdk/pull/14357

From prappo at openjdk.org  Thu Jun  8 09:55:27 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 09:55:27 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
 <zRNksz7nNEc3hZ_kDEAjBHIMCuCDjUcdYUtaNUM-ZOE=.66c77f82-8b19-4a79-a0cc-48f37931bb25@github.com>
 <dKUe62zWW_oKqJ9ntipz6u7aaG-m1NbCLlme2gRQseQ=.c86e3006-8e1e-4c8b-b990-123741b422f9@github.com>
 <dDWnDozy5_hHsv1tYrdxHdz5K-3K-tJUbMvz2laM-Bc=.4555e482-b333-4e2a-b251-82d02ab38c61@github.com>
Message-ID: <5_hHiDRF_JOTG6DcmG_2ONSv9ZMcLJyYafTs5q7VNj4=.5149617c-4015-4f9b-b518-7d316a1e92eb@github.com>

On Wed, 7 Jun 2023 21:39:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> The general criticism here is whether we should restrict in any way the set of super types from which one can inherit documentation, and/or what should the set of checks be?
>> 
>> For example, if a method in C inherits a method in B that has no comment but which inherits a method with a comment in A, then it seems unduly restrictive to stop the method in C explicitly referencing the method in A, as compared to only allowing a reference to B, which implicitly gets its comment from A.
>> 
>> That being said, there is merit in starting off with restrictions and loosening them in the face of experience, rather than trying to increase the stylistic restrictions later.
>
>> Sure we can; this relates to an earlier comment of yours on Utils.isDirectSupertype here: [#14357 (comment)](https://github.com/openjdk/jdk/pull/14357#discussion_r1222053011)
> 
> Thanks for tying these together; I had not realized they were related.

As agreed out of band, I removed that check and the test for now in dea776e285b.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222737390

From alanb at openjdk.org  Thu Jun  8 10:23:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:23:51 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <GZXj55PI5Ly58RmlW-Jn1fZiUpXNFRZv0DosDAcrjgw=.8ed39919-fbf8-4a63-8cbe-5bb03e955104@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
 <GZXj55PI5Ly58RmlW-Jn1fZiUpXNFRZv0DosDAcrjgw=.8ed39919-fbf8-4a63-8cbe-5bb03e955104@github.com>
Message-ID: <j9Q9qJ170OzAVwgZARjYEFIyyMwPNsT416812ELhsNw=.a5730671-642e-4740-ad5f-22a54ad4eea8@github.com>

On Thu, 8 Jun 2023 09:38:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.
>> 
>> This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.
>> 
>> Testing: tier1-5
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 879:
> 
>> 877:         boolean oldValue = interrupted;
>> 878:         if (oldValue) {
>> 879:             synchronized (interruptLock) {
> 
> Don't you still need to read under the lock to synchronize with the interrupt method?

The override of interrupt for virtual threads always sets the interrupt status as the first step. So if Thread.interrupted reads the interrupt status as true then it will synchronize. It's not too different to platform threads, I think you added a comment to Thread.interrupted about this when move the interrupted flag into Java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14361#discussion_r1222820022

From alanb at openjdk.org  Thu Jun  8 10:36:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:36:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

src/java.base/share/classes/java/util/TreeMap.java line 1199:

> 1197:      * {@code add} or {@code addAll} operations.
> 1198:      *
> 1199:      * @return {@inheritDoc SortedMap}

An alternative here might be  add `{@return ...}` to the first sentence of the method description so that the return description exactly matches.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222847956

From alanb at openjdk.org  Thu Jun  8 10:50:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 10:50:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <r_kzWNFCCjU2vL3e8WUtgR9dRPSLzg2HWRArVA8fTIk=.f2a36710-a531-4714-8ac6-e825b97ee1c3@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:

> 633:      * @return {@inheritDoc BlockingDeque}
> 634:      */
> 635:     public boolean offer(E e) {

Does this work for @param tags too? Just curious.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222860792

From briangoetz at openjdk.org  Thu Jun  8 11:11:52 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 8 Jun 2023 11:11:52 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
Message-ID: <pzg4x9XGLRC73o4OFTiP7eU3mkZnSNpnnHoPrPVsesQ=.61e1783b-c1ba-47c7-8b3f-574043f0c7c6@github.com>

On Thu, 8 Jun 2023 09:26:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> 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 29 commits:
> 
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
>    #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
>    #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
>    #	test/jdk/jdk/classfile/VerifierSelfTest.java
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>    #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
>    #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
>    #	test/jdk/jdk/classfile/StackMapsTest.java
>  - added missing javadoc
>  - simplified options names
>  - fixed copyright header
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed benchmarks
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842

Agreed.? The need for sync came from the shared static cache.

On 6/8/2023 7:07 AM, liach wrote:
>
> ***@***.**** commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java 
> <https://github.com/openjdk/jdk/pull/14180#discussion_r1222886769>:
>
> >       */
> -    static ClassHierarchyResolver defaultResolver() {
> -        return ClassHierarchyImpl.DEFAULT_RESOLVER;
> +    static ClassHierarchyResolver ofSystem() {
> +        var sysLoader = ClassLoader.getSystemClassLoader();
> +        return ClassHierarchyResolver
> +            .ofResourceParsing(sysLoader)
> +            .orElse(ClassHierarchyResolver.ofClassLoading(sysLoader))
> +            .cached(new Supplier<>() {
> +                @Override
> +                public Map<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo> get() {
> +                    return new ConcurrentHashMap<>();
>
> Don't think we need to synchronize the cache if we have dedicated CHRs.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/14180#pullrequestreview-1469667725>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4REUYN64IMQFDM5XPO3XKGW7JANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582385327

From liach at openjdk.org  Thu Jun  8 11:11:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 Jun 2023 11:11:54 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
Message-ID: <n-8npYheFCO9G3t4SEjIzMJgueklY-kPfYJNBal1T_Y=.5cb92ce8-1ccd-430c-b130-802efd92b08a@github.com>

On Thu, 8 Jun 2023 09:26:10 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> 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 29 commits:
> 
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
>    #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
>    #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
>    #	test/jdk/jdk/classfile/VerifierSelfTest.java
>  - Merge branch 'master' into JDK-8308899-context
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>    #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
>    #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
>    #	test/jdk/jdk/classfile/StackMapsTest.java
>  - added missing javadoc
>  - simplified options names
>  - fixed copyright header
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
>  - Merge branch 'master' into JDK-8308899-context
>  - fixed benchmarks
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842

src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java line 66:

> 64:                 @Override
> 65:                 public Map<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo> get() {
> 66:                     return new ConcurrentHashMap<>();

Don't think we need to synchronize the cache if we have dedicated CHRs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1222886769

From aivanov at openjdk.org  Thu Jun  8 11:22:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 11:22:52 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

I'll take a look? hopefully next week.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1582402901

From asotona at openjdk.org  Thu Jun  8 11:26:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 11:26:39 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassHierarchyResolver::ofSystem is now thread-unsafe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/aa691842..f3099cd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=07-08

  Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Thu Jun  8 11:26:43 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 11:26:43 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v8]
In-Reply-To: <n-8npYheFCO9G3t4SEjIzMJgueklY-kPfYJNBal1T_Y=.5cb92ce8-1ccd-430c-b130-802efd92b08a@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <P1WGR9fsZZ-VZLAhy8CLN6V_RXoKLl9lk_1zhDkSNoQ=.c9a60330-1dc1-47fb-b291-977b980a40f8@github.com>
 <n-8npYheFCO9G3t4SEjIzMJgueklY-kPfYJNBal1T_Y=.5cb92ce8-1ccd-430c-b130-802efd92b08a@github.com>
Message-ID: <K48k_NhTJaYNJ8ZdIufM5tvaMlkM7C2adLXbCKRNIFI=.ad78e05c-063c-4275-855d-e06bb235aacb@github.com>

On Thu, 8 Jun 2023 11:07:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>>    introduction of ClassHierarchyResolver::ofSystem factory method
>>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>>  - Merge branch 'master' into JDK-8308899-context
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Options.java
>>    #	src/java.base/share/classes/jdk/internal/classfile/snippet-files/PackageSnippets.java
>>    #	test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
>>    #	test/jdk/jdk/classfile/VerifierSelfTest.java
>>  - Merge branch 'master' into JDK-8308899-context
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/Classfile.java
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>>    #	test/jdk/jdk/classfile/FilterDeadLabelsTest.java
>>    #	test/jdk/jdk/classfile/ShortJumpsFixTest.java
>>    #	test/jdk/jdk/classfile/StackMapsTest.java
>>  - added missing javadoc
>>  - simplified options names
>>  - fixed copyright header
>>  - Merge branch 'master' into JDK-8308899-context
>>  - fixed StackMapGenerator::generatorError and removed obsolete SplitConstantPool clone constructor
>>  - Merge branch 'master' into JDK-8308899-context
>>  - fixed benchmarks
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/ac3ce2bf...aa691842
>
> src/java.base/share/classes/jdk/internal/classfile/ClassHierarchyResolver.java line 66:
> 
>> 64:                 @Override
>> 65:                 public Map<ClassDesc, ClassHierarchyResolver.ClassHierarchyInfo> get() {
>> 66:                     return new ConcurrentHashMap<>();
> 
> Don't think we need to synchronize the cache if we have dedicated CHRs.

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1222902932

From prappo at openjdk.org  Thu Jun  8 11:34:52 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 11:34:52 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
Message-ID: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>

On Thu, 8 Jun 2023 10:33:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: remove unduly restrictive warning
>
> src/java.base/share/classes/java/util/TreeMap.java line 1199:
> 
>> 1197:      * {@code add} or {@code addAll} operations.
>> 1198:      *
>> 1199:      * @return {@inheritDoc SortedMap}
> 
> An alternative here might be  add `{@return ...}` to the first sentence of the method description so that the return description exactly matches.

If we were to (re-)structure doc comments in the way you propose, I'd suggest we do it in a separate, non-jdk.javadoc  PR. I was simply trying to keep JDK API documentation unchanged.

One thing with the `@return` documentation inherited from SortedMap is that compared to the first sentence of TreeMap, it provides one extra bit of information: a set view of the mappings contained in this map, **sorted in ascending key order**. In order to keep that bit, the suggested inline `{@return ...}` should include more than just the first sentence.

> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:
> 
>> 633:      * @return {@inheritDoc BlockingDeque}
>> 634:      */
>> 635:     public boolean offer(E e) {
> 
> Does this work for @param tags too? Just curious.

The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:

    @param e {@inheritDoc BlockingDeque}

then the answer is that it's not necessary for keeping the API documentation unchanged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222908801
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1222910706

From prappo at openjdk.org  Thu Jun  8 11:41:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 11:41:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <zmbCcrz9xOw4-kohog4kdkGWwUqpjjRoDxgG7QvADo4=.8b3ecb99-46a5-40a2-b27d-83983bdf4f4d@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

@Martin-Buchholz, could you please have a look at changes to collections and, in particular, those in java.util.concurrent.*?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1582426421

From dholmes at openjdk.org  Thu Jun  8 12:09:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jun 2023 12:09:49 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <j9Q9qJ170OzAVwgZARjYEFIyyMwPNsT416812ELhsNw=.a5730671-642e-4740-ad5f-22a54ad4eea8@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
 <GZXj55PI5Ly58RmlW-Jn1fZiUpXNFRZv0DosDAcrjgw=.8ed39919-fbf8-4a63-8cbe-5bb03e955104@github.com>
 <j9Q9qJ170OzAVwgZARjYEFIyyMwPNsT416812ELhsNw=.a5730671-642e-4740-ad5f-22a54ad4eea8@github.com>
Message-ID: <iHoipZ66ynIgNmPvXU9psTTtCQ5rc5wRPT8GHbKorvs=.3c1b5ef0-af70-4250-83ab-71e84e798063@github.com>

On Thu, 8 Jun 2023 10:21:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 879:
>> 
>>> 877:         boolean oldValue = interrupted;
>>> 878:         if (oldValue) {
>>> 879:             synchronized (interruptLock) {
>> 
>> Don't you still need to read under the lock to synchronize with the interrupt method?
>
> The override of interrupt for virtual threads always sets the interrupt status as the first step. So if Thread.interrupted reads the interrupt status as true then it will synchronize. It's not too different to platform threads, I think you added a comment to Thread.interrupted about this when move the interrupted flag into Java.

Changing the synchronization means there is a lot more to think about for what was otherwise a fairly trivial change. But I think you are right, if we don't see interrupted==true then we do nothing; if we do see it then we synchronize.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14361#discussion_r1222948182

From prappo at openjdk.org  Thu Jun  8 12:17:57 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 12:17:57 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
Message-ID: <ZNWvGneK5nZuriiAOR-2z51cMWFWZATiyFpoSX9EnZc=.62c29530-bfb4-4b34-80c1-16ac1747b5b6@github.com>

On Thu, 8 Jun 2023 09:55:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: remove unduly restrictive warning

Note that the change to "method comments algorithm" uncovers and fixes some bugs to Object- or Object-like- methods. 

Using the provided [before][] and [after][] outputs, compare documentation for:

 * toString() in java.time.chrono.{Hijrah,Japanese,Minguo,ThaiBuddhist}Date
 * hashCode() in Hashtable, ConcurrentHashMap.KeySetView, java.util.jar.Attributes, com.sun.net.httpserver.Headers, com.sun.management.GcInfo
 * equals() in ConcurrentHashMap.KeySetView, com.sun.net.httpserver.Headers, com.sun.management.GcInfo
 * clone() in javax.management.ImmutableDescriptor, javax.management.modelmbean.DescriptorSupport, javax.naming.directory.BasicAttribute, javax.naming.directory.BasicAttributes
 
Perhaps some of those could be further refined using directed documentation inheritance. For example, ConcurrentHashMap.KeySetView is first and foremost a set and only then a collection. That suggests that the documentation for Object-like methods could be inherited from (some) set rather than a "generic" collection.

Also, the javax.management.ImmutableDescriptor and javax.management.modelmbean.DescriptorSupport clone methods require some attention from area experts. It's likely that those methods' doc comments need to fully inherit documentation from Descriptor.clone(), not just its `@return` tag.

[before]: https://cr.openjdk.org/~prappo/8285368/1/api
[after]: https://cr.openjdk.org/~prappo/8285368/2/api

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1582477351

From alanb at openjdk.org  Thu Jun  8 12:21:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 12:21:12 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames [v2]
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <pINzzpYSWQbDwzSExourmx0J3t7DTPBT0OET-WElK84=.b0b8dbdd-55cc-4454-953a-f6d24ca876b6@github.com>

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14257/files
  - new: https://git.openjdk.org/jdk/pull/14257/files/36138f34..e44c3c49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14257&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14257&range=00-01

  Stats: 48558 lines in 577 files changed: 40570 ins; 5940 del; 2048 mod
  Patch: https://git.openjdk.org/jdk/pull/14257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14257/head:pull/14257

PR: https://git.openjdk.org/jdk/pull/14257

From alanb at openjdk.org  Thu Jun  8 12:28:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 12:28:55 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
Message-ID: <aoEfQ88fCCEDBQ--yCtg_LL4ow5bf8zwa-zKAbSecpQ=.c52378ad-9ef2-41d0-9032-924b4de868af@github.com>

On Thu, 8 Jun 2023 00:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Update wording to be consistent with JDK-8295071.
>  - Merge branch 'master' into JDK-8306584
>  - Update wording of new constant to be consistent with JDK-8309554.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1469794796

From asotona at openjdk.org  Thu Jun  8 13:26:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 13:26:55 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
Message-ID: <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>

On Thu, 8 Jun 2023 11:26:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassHierarchyResolver::ofSystem is now thread-unsafe

Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare.
I can fix our Corpus tests and hope the race condition won't raise also somewhere else later.
However how to explain this limitation to users?

I suggest to make it always thread-safe (as the context is primary expected to be shared in multi-threaded environment) and users may make it faster in specific cases by providing non-synchronized map.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582576426

From asotona at openjdk.org  Thu Jun  8 13:37:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 13:37:33 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
  
  This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/f3099cd5..41fdb2fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=08-09

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From alanb at openjdk.org  Thu Jun  8 13:37:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 13:37:51 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
Message-ID: <wxje5E9he5rhzViprJqwj4Q6fC8Kwd9am_ZxVfje9dU=.96fc348e-d257-4fc1-840b-4961c1e83720@github.com>

On Thu, 8 Jun 2023 11:27:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> If we were to (re-)structure doc comments in the way you propose, I'd suggest we do it in a separate, non-jdk.javadoc PR. I was simply trying to keep JDK API documentation unchanged.

Understood, it was just a passing comment that TreeMap::entrySet overrides the description so it's specifying what it returns and using inherited text for the @return description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223053378

From rpressler at openjdk.org  Thu Jun  8 13:44:48 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Thu, 8 Jun 2023 13:44:48 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
Message-ID: <7xcDy6aT6D41OiGzaX7I9tSynAV1-dKUzQlxmgfBoE4=.34770cea-e8da-4f9c-a708-8c14b4bc1964@github.com>

On Wed, 7 Jun 2023 15:12:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.
> 
> This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.
> 
> Testing: tier1-5

Marked as reviewed by rpressler (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14361#pullrequestreview-1469948813

From briangoetz at openjdk.org  Thu Jun  8 14:09:58 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 8 Jun 2023 14:09:58 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
Message-ID: <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>

On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>   
>   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.

Most entities in the system are immutable and therefore freely sharable 
without additional coordination.? Some have lazily-inflated single-field 
caches that conform to the "benign race" (there is only one possible 
non-default value) criteria.

The main hole is the CHA resolution cache.? There are two ways to 
address this: protect the cache, or don't share the context.

Unfortunately now that ClassModel refers back to the context, there's a 
risk of unexpected context sharing.? Here are a few options:

 ?- Make the CHA cache thread-safe using, say, CHM;
 ?- Make the CHA cache unshared, by using a ThreadLocal (this brings the 
context back to being immutable)
 ?- Detect when implicit use of a context happens on a thread other than 
the creating thread (currently the only vector for this is 
Classfile::transform), and inflate a new context with empty cache in 
that case;
 ?- Always create a fresh context with an empty cache in 
Classfile::transform





On 6/8/2023 9:24 AM, Adam Sotona wrote:
>
> Unfortunately thread-unsafe context makes sharing of it in tests 
> executed in parallel a nightmare.
> I can fix our Corpus tests and hope the race condition won't raise 
> also somewhere else later.
> However how to explain this limitation to users?
>
> I suggest to make it always thread-safe (as the context is primary 
> expected to be shared in multi-threaded environment) and users may 
> make it faster in specific cases by providing non-synchronized map.
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/14180#issuecomment-1582576426>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4RHSMWR5Q3ANYK3RPSLXKHG7RANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582643016

From tholenstein at openjdk.org  Thu Jun  8 14:29:56 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Thu, 8 Jun 2023 14:29:56 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v3]
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <NO73XPWGpMzXMWueLQ0Y5NTiX6c-MGORhiSoVmGR7aM=.31edcafc-7b4d-4767-bc77-5109ce3bdde1@github.com>

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileCommand=compileonly` with possibility to take lists as ...

Tobias Holenstein has updated the pull request incrementally with 11 additional commits since the last revision:

 - Update TestStableUShort.java
 - Update TestStableUByte.java
 - Update TestStableShort.java
 - Update TestStableObject.java
 - Update TestStableLong.java
 - Update TestStableInt.java
 - Update TestStableFloat.java
 - Update TestStableDouble.java
 - Update TestStableChar.java
 - Update TestStableByte.java
 - ... and 1 more: https://git.openjdk.org/jdk/compare/40b17296...e320a9de

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13802/files
  - new: https://git.openjdk.org/jdk/pull/13802/files/40b17296..e320a9de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=01-02

  Stats: 44 lines in 11 files changed: 0 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/13802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13802/head:pull/13802

PR: https://git.openjdk.org/jdk/pull/13802

From iris at openjdk.org  Thu Jun  8 14:41:53 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 8 Jun 2023 14:41:53 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v6]
In-Reply-To: <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <GbdAzX6xrTE_pcieRIPSydOpwKHo2e4eQL4DHmBSBnU=.3b99fc16-64c7-4ad3-99df-ae87ad668143@github.com>
Message-ID: <zy4pghHpgCqMi8Ltg8yGUvKeDBbpMubFemqlB8hO9UQ=.cf82ba01-ff19-4c2e-8dd8-9bd346a67c99@github.com>

On Thu, 8 Jun 2023 00:37:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Update wording to be consistent with JDK-8295071.
>  - Merge branch 'master' into JDK-8306584
>  - Update wording of new constant to be consistent with JDK-8309554.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/4ffc8cc2...a03bcd40

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1470093232

From prappo at openjdk.org  Thu Jun  8 14:47:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 14:47:13 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v8]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  feedback: use JavadocTester.out
  
  Also, trivially fixes grammar (word order) in a comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/dea776e2..cccffa66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=06-07

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

PR: https://git.openjdk.org/jdk/pull/14357

From prappo at openjdk.org  Thu Jun  8 14:47:16 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 14:47:16 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v2]
In-Reply-To: <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <FjDvaV_KhBtw1WrLyVI0uRP77NUQ1Wg81EK4GxErfug=.33283cc5-6d68-40b2-a15a-3a07a23af3ec@github.com>
 <kdBESB19ITjRJfvas4tQ1ILesUKHIpMsjarHFns4e0s=.2e57bf24-328b-4fe8-a050-dc366067422a@github.com>
Message-ID: <82i8za9caZsJgAkr0hX9cR-ItoN94SJdcsHW0EfTswc=.8477eb23-93a7-4ac5-a558-384f9d956371@github.com>

On Wed, 7 Jun 2023 20:33:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback: make warning less scary
>
> test/langtools/jdk/javadoc/doclet/testMethodCommentAlgorithm/TestMethodCommentsAlgorithm.java line 273:
> 
>> 271:             }
>> 272:         }
>> 273:         System.err.println("Test suite root: " + p);
> 
> You might want to use `JavadocTester.out` instead of `System.err`

Fixed in cccffa660a8.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223144388

From adam.sotona at oracle.com  Thu Jun  8 15:00:00 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Thu, 8 Jun 2023 15:00:00 +0000
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
 <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
Message-ID: <CY4PR1001MB21509683FB0276CE208A58D28C50A@CY4PR1001MB2150.namprd10.prod.outlook.com>



From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Brian Goetz <briangoetz at openjdk.org>

Most entities in the system are immutable and therefore freely sharable
without additional coordination.  Some have lazily-inflated single-field
caches that conform to the "benign race" (there is only one possible
non-default value) criteria.

The main hole is the CHA resolution cache.  There are two ways to
address this: protect the cache, or don't share the context.

Unfortunately now that ClassModel refers back to the context, there's a
risk of unexpected context sharing.  Here are a few options:

  - Make the CHA cache thread-safe using, say, CHM;
This is current solution for the default system CH cache. We may also remove ClassHierarchyResolver::cached() method to force user think about it and always call ClassHierarchyResolver::cached(Supplier<Map<ClassDesc, ClassHierarchyInfo>> cacheFactory) for all non-default cases.
Or we may also use a bit less strict custom semi-synchronization (just enough to be thread safe) instead of fully-synchronized CHM::computeIfAbsent, for example CHM:get ? <compute if absent without lock> ... CHM::put.

  - Make the CHA cache unshared, by using a ThreadLocal (this brings the
context back to being immutable)
This is interesting option for small number of threads, however it makes big footprint for heavy-parallel systems.

  - Detect when implicit use of a context happens on a thread other than
the creating thread (currently the only vector for this is
Classfile::transform), and inflate a new context with empty cache in
that case;
This would degrade the caching completely by triggering a new context for each transformed method in case there are two threads working synchronously.

  - Always create a fresh context with an empty cache in
Classfile::transform
This would destroy the caching. Such cache would work only in scope of one method.






On 6/8/2023 9:24 AM, Adam Sotona wrote:
>
> Unfortunately thread-unsafe context makes sharing of it in tests
> executed in parallel a nightmare.
> I can fix our Corpus tests and hope the race condition won't raise
> also somewhere else later.
> However how to explain this limitation to users?
>
> I suggest to make it always thread-safe (as the context is primary
> expected to be shared in multi-threaded environment) and users may
> make it faster in specific cases by providing non-synchronized map.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/14180#issuecomment-1582576426>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABJ4RHSMWR5Q3ANYK3RPSLXKHG7RANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID:
> ***@***.***>
>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582643016
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230608/6a5f965b/attachment.htm>

From redestad at openjdk.org  Thu Jun  8 15:15:19 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 8 Jun 2023 15:15:19 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods
Message-ID: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>

https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

-------------

Commit messages:
 - Merge branch 'master' into 8309665
 - 8309665: Simplify Array.copyOf/-Range methods

Changes: https://git.openjdk.org/jdk/pull/14380/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14380&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309665
  Stats: 105 lines in 1 file changed: 25 ins; 62 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14380/head:pull/14380

PR: https://git.openjdk.org/jdk/pull/14380

From aivanov at openjdk.org  Thu Jun  8 15:18:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 8 Jun 2023 15:18:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
Message-ID: <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>

On Thu, 8 Jun 2023 11:29:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java line 635:
>> 
>>> 633:      * @return {@inheritDoc BlockingDeque}
>>> 634:      */
>>> 635:     public boolean offer(E e) {
>> 
>> Does this work for @param tags too? Just curious.
>
> The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:
> 
>     @param e {@inheritDoc BlockingDeque}
> 
> then the answer is that it's not necessary for keeping the API documentation unchanged.

I admit I can't parse this sentence:

> then the answer is that it's not necessary for keeping the API documentation unchanged.

Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?

You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.

So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223197961

From jlaskey at openjdk.org  Thu Jun  8 15:26:48 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 8 Jun 2023 15:26:48 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods
In-Reply-To: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
Message-ID: <1IDGcPYYmhADL2TIeC63_NOqma34MBkepFeuZfHrm7U=.ede1ce39-73d2-4f16-8aef-c82f8cce0f53@github.com>

On Thu, 8 Jun 2023 15:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

LGTM

-------------

Marked as reviewed by jlaskey (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14380#pullrequestreview-1470207769

From rriggs at openjdk.org  Thu Jun  8 15:26:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 8 Jun 2023 15:26:49 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods
In-Reply-To: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
Message-ID: <rF9v_aZZ5RAnVfESszn4-dyU-qbPr7iWFhlet4P45Qo=.77c21b30-9919-44a3-9666-4c2160075175@github.com>

On Thu, 8 Jun 2023 15:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14380#pullrequestreview-1470208761

From redestad at openjdk.org  Thu Jun  8 15:29:48 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 8 Jun 2023 15:29:48 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods
In-Reply-To: <1IDGcPYYmhADL2TIeC63_NOqma34MBkepFeuZfHrm7U=.ede1ce39-73d2-4f16-8aef-c82f8cce0f53@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
 <1IDGcPYYmhADL2TIeC63_NOqma34MBkepFeuZfHrm7U=.ede1ce39-73d2-4f16-8aef-c82f8cce0f53@github.com>
Message-ID: <oy0UB6kZp1hhSAAZwd01UoUOoOl2Rkby1mydS6oOI_E=.9486aef4-c9b0-486c-b9cf-5c9dcfe2724c@github.com>

On Thu, 8 Jun 2023 15:24:00 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.
>
> LGTM

@JimLaskey @RogerRiggs thanks for the quick reviews! I'll wait for and double-check test results before pushing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14380#issuecomment-1582821757

From prappo at openjdk.org  Thu Jun  8 15:49:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 15:49:53 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
Message-ID: <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>

On Thu, 8 Jun 2023 15:16:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The directed `{@inheritDoc <FQN>}` works for the main description, `@throws`, `@param` and `@return` tags. If your question is about why that particular doc comment does not use this:
>> 
>>     @param e {@inheritDoc BlockingDeque}
>> 
>> then the answer is that it's not necessary for keeping the API documentation unchanged.
>
> I admit I can't parse this sentence:
> 
>> then the answer is that it's not necessary for keeping the API documentation unchanged.
> 
> Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?
> 
> You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.
> 
> So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?

Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:

    @param e the element to add

If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.

Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.

Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:

 - javax.imageio.stream.ImageInputStream#flushBefore
    ```
     * @param pos a {@code long} containing the length of the
     * stream prefix that may be flushed.
    ```

 - javax.imageio.stream.ImageOutputStream#flushBefore:
    ```
     * @param pos a {@code long} containing the length of the
     * stream prefix that may be flushed to the destination.
    ```
Hence, the correction. Does it clarify the matter?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223236596

From prappo at openjdk.org  Thu Jun  8 15:53:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 8 Jun 2023 15:53:58 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
 <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
Message-ID: <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>

On Thu, 8 Jun 2023 15:47:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I admit I can't parse this sentence:
>> 
>>> then the answer is that it's not necessary for keeping the API documentation unchanged.
>> 
>> Do you mean that you didn't add `@param e {@inheritDoc BlockingDeque}` here to keep the documentation unchanged?
>> 
>> You added `@inheritDoc` for `@param` tags in [FileCacheImageOutputStream.java](https://github.com/openjdk/jdk/pull/14357/files#diff-bc1e47b4c5c405826e7a062cabea04349ef72d5823b67e8616a680dcfcb5d4be) and others but not here.
>> 
>> So, do we need to add `@param` tags if the entire javadoc is inherited with `@inheritDoc`?
>
> Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:
> 
>     @param e the element to add
> 
> If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.
> 
> Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.
> 
> Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:
> 
>  - javax.imageio.stream.ImageInputStream#flushBefore
>     ```
>      * @param pos a {@code long} containing the length of the
>      * stream prefix that may be flushed.
>     ```
> 
>  - javax.imageio.stream.ImageOutputStream#flushBefore:
>     ```
>      * @param pos a {@code long} containing the length of the
>      * stream prefix that may be flushed to the destination.
>     ```
> Hence, the correction. Does it clarify the matter?

Also, for better or worse, a lone `{@inheritDoc}` never inherits "everything" from a supertype:

/** {@inheritDoc} */

It merely inherits the main description of a method. Other elements such as parameter, exception or return information are inherited individually.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1223241132

From roger.riggs at oracle.com  Thu Jun  8 16:02:45 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 8 Jun 2023 12:02:45 -0400
Subject: Leap second handling in Windows timestamps
In-Reply-To: <71d99c8c-f188-a09c-fc38-f428cc8ff6c0@oracle.com>
References: <1790d01d985ca$e03cf6c0$a0b6e440$@flueckiger.ch>
 <71d99c8c-f188-a09c-fc38-f428cc8ff6c0@oracle.com>
Message-ID: <5fe1ed9e-b914-1ad9-6726-ddd25df3412e@oracle.com>

Hi,

I looked into this issue and added comments to the issue tracker.
8308302 <https://bugs.openjdk.org/browse/JDK-8308302> Leap second 
handling in Windows timestamps

I don't see an issue with the implementation for past leap-seconds and
there is significant discussion about whether if or when there will be 
another one.

Until another leap-second is declared, I don't see any immediate followup.

Regards, Roger

On 5/17/23 1:19 PM, Roger Riggs wrote:
> Hi,
>
> Thanks for the report, I created a Jira issue to track the investigation.
> https://bugs.openjdk.org/browse/JDK-8308302
>
> Regards, Roger
>
> On 5/13/23 2:43 PM, andreas at flueckiger.ch wrote:
>> Subject:
>> Leap second handling in Windows timestamps
>> From:
>> <andreas at flueckiger.ch>
>> Date:
>> 5/13/23, 2:43 PM
>>
>> To:
>> <core-libs-dev at openjdk.org>
>>
>>
>> Hello,
>>
>> This is my first post to this mailing list. I've been exploring a problem concerning leap seconds that emerged with the Windows 10 October 2018 Update. The current implementation of InstantSource and other classes that interact with FILETIME structures seem to be affected. This problem extends beyond just leap second days and will occur on any future day where the UTC-TAI offset deviates from 37 seconds.
>>
>> The Java code snippet below, which uses JNA to convert a Windows FILETIME to an Instant, represents my initial attempt to address this issue. This approach makes the assumption that no more than one leap second is added or removed in a day, which should hold true until at least 2035, and likely a few years beyond.
>>
>> I'm not sure how this will impact performance, and I'm not certain about the exact performance requirements. Also, I'm not sure if my current level of experience and permissions allow me to contribute directly to the JDK codebase. Still, I hope this code can provide some direction towards refining the handling of Windows timestamps.
>>
>> Kind regards,
>> Andreas
>>
>> private static Instant fileTimeToInstant(long fileTime) {
>>    if (fileTime < 0L) {
>>      throw new DateTimeException("file time must not be negative");
>>    }
>>
>>    // Calculate nano adjustment and round down fileTime to the nearest second
>>    int nanoAdjustment = (int) (fileTime % 10000000L);
>>    fileTime -= nanoAdjustment;
>>    nanoAdjustment *= 100;
>>
>>    // Populate FILETIME structure
>>    FILETIME fileTimeStruct = new FILETIME();
>>    fileTimeStruct.dwHighDateTime = (int) (fileTime >>> 32);
>>    fileTimeStruct.dwLowDateTime = (int) (fileTime & 0xffffffffL);
>>
>>    // Convert FILETIME structure to a SYSTEMTIME structure
>>    SYSTEMTIME systemTime = new SYSTEMTIME();
>>    if (!Kernel32.INSTANCE.FileTimeToSystemTime(fileTimeStruct, systemTime)) {
>>      throw new LastErrorException(Native.getLastError());
>>    }
>>
>>    // Calculate epoch day and second of day
>>    long epochDay = LocalDate.of(systemTime.wYear, systemTime.wMonth, systemTime.wDay).toEpochDay();
>>    int secondOfDay = systemTime.wHour * 3600 + systemTime.wMinute * 60 + systemTime.wSecond;
>>
>>    // Calculate UTC-SLS slew if necessary and only for dates before December 31,
>>    // 30827 (epochDay < 10540167). SystemTimeToFileTime does not support dates
>>    // after the year 30827.
>>    if (secondOfDay >= 85399 && epochDay < 10540167) {
>>      // If the actual second of the day is 86400 (leap second) and the process is in
>>      // "compatible mode", increment the secondOfDay variable. In compatible mode,
>>      // the clock slows down to half speed for two seconds at the '59' second mark,
>>      // and systemTime.wMilliseconds reaches 500 at the beginning of the leap second.
>>      // This ensures that the leap second is properly accounted for without depending
>>      // on the ProcessLeapSecondInfo option. Rounding down fileTime to the nearest
>>      // second ensures that this check works as intended.
>>      if (secondOfDay == 86399 && systemTime.wMilliseconds == 500) {
>>        secondOfDay++;
>>      }
>>
>>      // Calculate leap adjustment
>>      int leapAdjustment;
>>      if (secondOfDay == 86400) {
>>        // In case of a leap second, set leap adjustment to 1
>>        // to avoid unnecessary further calculations
>>        leapAdjustment = 1;
>>      } else {
>>        // If it's not a leap second, calculate leap adjustment by
>>        // determining the difference to the beginning of the next day
>>        LocalDate nextDay = LocalDate.ofEpochDay(epochDay + 1);
>>        systemTime.wYear = (short) nextDay.getYear();
>>        systemTime.wMonth = (short) nextDay.getMonthValue();
>>        systemTime.wDay = (short) nextDay.getDayOfMonth();
>>        systemTime.wHour = 0;
>>        systemTime.wMinute = 0;
>>        systemTime.wSecond = 0;
>>        systemTime.wMilliseconds = 0;
>>        if (!Kernel32.INSTANCE.SystemTimeToFileTime(systemTime, fileTimeStruct)) {
>>          throw new LastErrorException(Native.getLastError());
>>        }
>>        long nextDayFileTime = (((long) fileTimeStruct.dwHighDateTime) << 32) | (fileTimeStruct.dwLowDateTime & 0xffffffffL);
>>
>>        leapAdjustment = (int) ((nextDayFileTime - fileTime) / 10000000L + secondOfDay - 86400L);
>>      }
>>
>>      // Adjust nanoseconds based on leap adjustment
>>      if (leapAdjustment != 0 && secondOfDay - leapAdjustment >= 85400) {
>>        nanoAdjustment -= ((secondOfDay - leapAdjustment - 85400) * 1000000000L + nanoAdjustment) * leapAdjustment / 1000L;
>>      }
>>    }
>>
>>    return Instant.ofEpochSecond(epochDay * 86400L + secondOfDay, nanoAdjustment);
>> }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230608/cbf9bbe7/attachment-0001.htm>

From darcy at openjdk.org  Thu Jun  8 16:04:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 8 Jun 2023 16:04:58 GMT
Subject: Integrated: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <E8OuMbiyCEH97OOx2HtX8BtCwKUzQ9J5-E22tezqZqk=.0a4cf8e5-7d9a-4703-8607-48a1845c06d0@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

This pull request has now been integrated.

Changeset: 5a706fb4
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a706fb403df0768ecef5b0ce14a3ca389a51efd
Stats:     5954 lines in 69 files changed: 5902 ins; 0 del; 52 mod

8306584: Start of release updates for JDK 22
8306585: Add SourceVersion.RELEASE_22
8306586: Add source 22 and target 22 to javac

Reviewed-by: erikj, iris, dholmes, jlahoda, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13567

From asotona at openjdk.org  Thu Jun  8 16:11:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 16:11:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
 <X1ybJVyQ4JuLCJ0qQtd_TfHlkzbWEHhTCidbmqsi6R0=.396abaa2-b2e1-466f-b617-c04eedbeaac0@github.com>
Message-ID: <hwyMC0TxWo_6aLxzM6bxorHhCLQsMrUxKfMjV_VLrq8=.233f074a-de21-4cee-b844-2d2a08a58339@github.com>

On Thu, 8 Jun 2023 14:07:24 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>  Here are a few options: 
?- Make the CHA cache thread-safe using, say, CHM; 

This is current solution for the default system CH cache. 

We may also use a bit less strict custom semi-synchronization (just enough to be thread safe) instead of fully-synchronized `CHM::computeIfAbsent`, for example `CHM:get ? (compute if absent without lock) ... CHM::put`.
CHM does not lock on get, so the only penalty would be synchronous put call. 

>?- Make the CHA cache unshared, by using a ThreadLocal (this brings the context back to being immutable)

This is interesting option for small number of threads, however it makes big footprint for heavy-parallel systems.

>?- Detect when implicit use of a context happens on a thread other than the creating thread (currently the only vector for this is Classfile::transform), and inflate a new context with empty cache in that case;

This would degrade the caching completely by triggering a new context for each transformed method in case there are two threads working synchronously.

>?- Always create a fresh context with an empty cache in Classfile::transform

This would destroy the caching. Such cache would work only in scope of one method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1582943385

From duke at openjdk.org  Thu Jun  8 16:17:49 2023
From: duke at openjdk.org (Brett Okken)
Date: Thu, 8 Jun 2023 16:17:49 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods
In-Reply-To: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
Message-ID: <jpZ5A4DeZOuOP7YKf15CRktnxNu2u0L4YlIHDQPVF0Q=.3be78670-c2fc-4b90-851b-3b9db00338e3@github.com>

On Thu, 8 Jun 2023 15:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

src/java.base/share/classes/java/util/Arrays.java line 3845:

> 3843:      */
> 3844:     public static byte[] copyOfRange(byte[] original, int from, int to) {
> 3845:         // Tickle the JIT to fold special cases optimally

this comment has been inconsistently left vs removed in the various methods (even though the other changes appear the same). was this intentional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14380#discussion_r1223276847

From asotona at openjdk.org  Thu Jun  8 16:37:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 8 Jun 2023 16:37:22 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - proposed semi-synchronized caching, where the map is not locked during delegate call
 - used Factory.INSTANCE for system ClassHierarchyResolver cache

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/41fdb2fc..ae287751

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=09-10

  Stats: 28 lines in 2 files changed: 13 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From briangoetz at openjdk.org  Thu Jun  8 16:37:45 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 8 Jun 2023 16:37:45 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
Message-ID: <QU1ZsVotsQTwtlp6E42zqsDWiB4stkj4lJbO1yZQz5c=.a5030342-8858-4bb2-9bdf-992ccfd44dda@github.com>

On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>   
>   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.

On 6/8/2023 12:09 PM, Adam Sotona wrote:
>
>     Here are a few options:
>     ?- Make the CHA cache thread-safe using, say, CHM;
>
> This is current solution for the default system CH cache.
>
> We may also use a bit less strict custom semi-synchronization (just 
> enough to be thread safe) instead of fully-synchronized 
> |CHM::computeIfAbsent|, for example |CHM:get ? (compute if absent 
> without lock) ... CHM::put|.
> CHM does not lock on get, so the only penalty would be synchronous put 
> call.
>
>     ?- Make the CHA cache unshared, by using a ThreadLocal (this
>     brings the context back to being immutable)
>
> This is interesting option for small number of threads, however it 
> makes big footprint for heavy-parallel systems.
>

I have a hard time imagining heavy parallel use here; concurrency 
against the same cache would most likely come from accidental sharing.? 
So this is not necessarily a problem.? Are you imagining differnet use 
cases?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1583003584

From alanb at openjdk.org  Thu Jun  8 16:46:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 16:46:20 GMT
Subject: RFR: 8309196: Remove Thread.countStackFrames [v3]
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <bkP2RPhV3SAg6qghkI6eEvk-q-m_2Lf1lqnsrfq-oNo=.ea9daafc-bd85-42b6-96b4-29d83d32058a@github.com>

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14257/files
  - new: https://git.openjdk.org/jdk/pull/14257/files/e44c3c49..b784ff83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14257&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14257&range=01-02

  Stats: 6494 lines in 82 files changed: 6315 ins; 50 del; 129 mod
  Patch: https://git.openjdk.org/jdk/pull/14257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14257/head:pull/14257

PR: https://git.openjdk.org/jdk/pull/14257

From mchung at openjdk.org  Thu Jun  8 16:46:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 16:46:55 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v3]
In-Reply-To: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
Message-ID: <q4dAvY29BadEcunZeqSSBqpwf5minhl7n6w7fhZggd8=.f693b939-b66d-4431-a5b2-5cbf8bb65d58@github.com>

> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14371/files
  - new: https://git.openjdk.org/jdk/pull/14371/files/d161a384..fc164c71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14371&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14371&range=01-02

  Stats: 49 lines in 4 files changed: 15 ins; 28 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14371/head:pull/14371

PR: https://git.openjdk.org/jdk/pull/14371

From mchung at openjdk.org  Thu Jun  8 16:46:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 16:46:57 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <99mbKbiEdzbFp3PyMA-I8UX3LPWriM6PZFX3itSTObw=.c3238b5d-1552-4455-8ebb-923ccd60480d@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
 <99mbKbiEdzbFp3PyMA-I8UX3LPWriM6PZFX3itSTObw=.c3238b5d-1552-4455-8ebb-923ccd60480d@github.com>
Message-ID: <mrCQLHieRC95AGxXidh_7XIRiBXp8t191O6y7mVGvqk=.665c84c2-47d1-4294-af4d-eccdf81936b1@github.com>

On Thu, 8 Jun 2023 01:46:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix merge issue
>
> src/hotspot/share/classfile/verifier.cpp line 298:
> 
>> 296:     // NOTE: this is called too early in the bootstrapping process to be
>> 297:     // guarded by Universe::is_gte_jdk14x_version().
>> 298:     // Also for lambda generated code, gte jdk8
> 
> While you are here could you delete these version comments please - they are meaningless these days. Thanks.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1223305314

From mchung at openjdk.org  Thu Jun  8 16:47:00 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 16:47:00 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <Jz1wwHnNhx_Uhu7FHJSxaBCVdR99zIW0drCe5Vk1PHE=.48129341-8f01-44bc-83ad-fd5450432307@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
 <Jz1wwHnNhx_Uhu7FHJSxaBCVdR99zIW0drCe5Vk1PHE=.48129341-8f01-44bc-83ad-fd5450432307@github.com>
Message-ID: <6kpeFY6P4c-vULMHVmKx1moS_087FvmsMDlsWBeSC6o=.88b3c7a7-803b-466f-8223-dd459a9eb98c@github.com>

On Thu, 8 Jun 2023 08:42:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix merge issue
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 578:
> 
>> 576:     // then switch to the bytecode-based implementations.
>> 577: 
>> 578:     private static final Config DEFAULT_CONFIG = new Config(false, // useNativeAccessorOnly
> 
> The block comment just before this will need updating.  There's another one in Config.config where it uses the default/native implementation in early startup.

Thanks for pointing this out.  Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1223305554

From mchung at openjdk.org  Thu Jun  8 16:47:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 16:47:03 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v2]
In-Reply-To: <OvhuNp0K7qeTpuBujW0ayqA5hlw6q6XXYdbldXKSp0I=.56787c71-7f4a-4e9b-99c5-c04f6a2ebb9c@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <R4jM6o088ylO156nw3X5YBPHS_gSDEDEEU_Oe_5nPhE=.d15a38b4-7ee4-4d70-945b-f03492a2e086@github.com>
 <OvhuNp0K7qeTpuBujW0ayqA5hlw6q6XXYdbldXKSp0I=.56787c71-7f4a-4e9b-99c5-c04f6a2ebb9c@github.com>
Message-ID: <RKMPjf9_eZsze1NQ0rFRBIG2GdWMU_75zd9p3ZSh-Nw=.710a49ed-edc3-4472-8bd6-8f37e8b1292d@github.com>

On Thu, 8 Jun 2023 01:36:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix merge issue
>
> test/jdk/java/lang/reflect/Field/NegativeTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8277451
>> 27:  * @run testng/othervm NegativeTest
> 
> Does this still need othervm if it doesn't set system properties?

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1223305257

From alanb at openjdk.org  Thu Jun  8 17:32:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 17:32:18 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v3]
In-Reply-To: <q4dAvY29BadEcunZeqSSBqpwf5minhl7n6w7fhZggd8=.f693b939-b66d-4431-a5b2-5cbf8bb65d58@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <q4dAvY29BadEcunZeqSSBqpwf5minhl7n6w7fhZggd8=.f693b939-b66d-4431-a5b2-5cbf8bb65d58@github.com>
Message-ID: <1U7a_JyO7dEQz3VP5nxeNyEVXn5zVT4p0CO3iLgAa1w=.bbfda9c7-39d9-4127-8b4a-98bf4a15bc76@github.com>

On Thu, 8 Jun 2023 16:46:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14371#pullrequestreview-1470455536

From alanb at openjdk.org  Thu Jun  8 17:32:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 17:32:39 GMT
Subject: Integrated: 8309196: Remove Thread.countStackFrames
In-Reply-To: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
References: <7p3wapZUnzfzFKMyOVexaMVGeh00epZs3ipgw-LpvDM=.86006e6e-060a-4d9b-a883-4983381cdba7@github.com>
Message-ID: <yTOFEoD9_bcm5nHiYyfFE-gG7U2bnPUiik2AdrE49ec=.9c1696b4-b748-4288-971e-fed4f297868e@github.com>

On Thu, 1 Jun 2023 06:40:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.countStackFrames is/was an ill-defined method that dates from JDK 1.0 for counting the stack frames of a suspended Thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded to throw UOE unconditionally in Java 14.  Java 22 would be a fine time to finally remove this method.
> 
> Code that wants to count stack frames should be directed to use j.l.StackWalker, or if a tool, then it can use JVM TI and other tool APIs.
> 
> A corpus analysis of 30M classes in 131k artifacts from Maven Central found only 1 usages to this method. The 1 usage appears to be a class that just wraps all methods, it doesn't actually make use of it.

This pull request has now been integrated.

Changeset: b2a5271e
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2a5271e7451a7546a8293fc4bc4ccfaa1ffb0d7
Stats:     20 lines in 2 files changed: 0 ins; 17 del; 3 mod

8309196: Remove Thread.countStackFrames

Reviewed-by: rriggs, mchung, dholmes, jpai, iris

-------------

PR: https://git.openjdk.org/jdk/pull/14257

From mchung at openjdk.org  Thu Jun  8 19:03:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 19:03:15 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
Message-ID: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>

The `RuntimeArguments` test verifies the VM arguments returned by `jdk.internal.misc.VM::getRuntimeArguments` as expected.    This test fails when running with GraalVM as it was created with `jlink --add-options` and the application will always be launched with that additional set of VM options.  This PR updates the test to read if 'jdk/internal/vm/options` is present and includle those options in the expected list.

-------------

Commit messages:
 - 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores jdk/internal/vm/options

Changes: https://git.openjdk.org/jdk/pull/14383/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14383&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309303
  Stats: 37 lines in 1 file changed: 33 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14383.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14383/head:pull/14383

PR: https://git.openjdk.org/jdk/pull/14383

From dnsimon at openjdk.org  Thu Jun  8 19:03:53 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Jun 2023 19:03:53 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
In-Reply-To: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
References: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
Message-ID: <Uj4DC9SkymmOxcH8LvRHVGNjTgSdzgTtLcH7uM-qK3A=.67b6272d-cc2f-41de-b488-8aae82c8bdf4@github.com>

On Thu, 8 Jun 2023 18:56:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The `RuntimeArguments` test verifies the VM arguments returned by `jdk.internal.misc.VM::getRuntimeArguments` as expected.    This test fails when running with GraalVM as it was created with `jlink --add-options` and the application will always be launched with that additional set of VM options.  This PR updates the test to read if 'jdk/internal/vm/options` is present and includle those options in the expected list.

I can confirm the change works on GraalVM but it would make sense to also test it directly in the JDK by creating a test JDK image with jlink that includes VM options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14383#issuecomment-1583176634

From dnsimon at openjdk.org  Thu Jun  8 19:23:43 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Jun 2023 19:23:43 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
In-Reply-To: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
References: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
Message-ID: <MZaGgr0tRWNv3lW8SB1ikr1tLEFRP4gEdtU0ZBFpztE=.082524dc-cd60-4c78-9dc5-ffe614611738@github.com>

On Thu, 8 Jun 2023 18:56:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The `RuntimeArguments` test verifies the VM arguments returned by `jdk.internal.misc.VM::getRuntimeArguments` as expected.    This test fails when running with GraalVM as it was created with `jlink --add-options` and the application will always be launched with that additional set of VM options.  This PR updates the test to read if 'jdk/internal/vm/options` is present and includle those options in the expected list.

Marked as reviewed by dnsimon (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14383#pullrequestreview-1470614093

From mchung at openjdk.org  Thu Jun  8 19:23:45 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 8 Jun 2023 19:23:45 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
In-Reply-To: <Uj4DC9SkymmOxcH8LvRHVGNjTgSdzgTtLcH7uM-qK3A=.67b6272d-cc2f-41de-b488-8aae82c8bdf4@github.com>
References: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
 <Uj4DC9SkymmOxcH8LvRHVGNjTgSdzgTtLcH7uM-qK3A=.67b6272d-cc2f-41de-b488-8aae82c8bdf4@github.com>
Message-ID: <01lUf_vOyLmvJZY6M54GRxYYYYvfAH1ltMKPg_kDyGE=.2a5ecc60-1d03-468d-a48f-705d63a6f87e@github.com>

On Thu, 8 Jun 2023 19:01:37 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> I can confirm the change works on GraalVM but it would make sense to also test it directly in the JDK by creating a test JDK image with jlink that includes VM options.

Already exists.  `test/jdk/tools/jlink/plugins/AddOptionsPluginTest.java`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14383#issuecomment-1583201049

From duke at openjdk.org  Thu Jun  8 19:40:56 2023
From: duke at openjdk.org (iaroslavski)
Date: Thu, 8 Jun 2023 19:40:56 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v19]
In-Reply-To: <ptbz4GUKNgTgItey6ipARJZDOM-rim2EMakqRvxVNVo=.aaa9c0f0-5f12-4804-8027-ba88ab34e9e4@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <ptbz4GUKNgTgItey6ipARJZDOM-rim2EMakqRvxVNVo=.aaa9c0f0-5f12-4804-8027-ba88ab34e9e4@github.com>
Message-ID: <7CWEKASGpYF08hhgxhrks2VLffdpZzSnfpqsVUau0io=.9eff371b-0b6d-42e6-be60-658a83268e5f@github.com>

On Sun, 12 Mar 2023 21:28:59 GMT, iaroslavski <duke at openjdk.org> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Use uninitialized array for buffers

Keeping alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3938#issuecomment-1583223092

From duke at openjdk.org  Thu Jun  8 19:51:54 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 8 Jun 2023 19:51:54 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
Message-ID: <kSjN4LeH7dwrRLPfDk6SQyXlw43quf8u3IwGnZuMGG8=.5e52debb-92e6-4b47-a267-447e4173a79a@github.com>

On Wed, 7 Jun 2023 14:15:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Review changes, fixed tests
>  - Merge branch 'master' into hierarchy-resolve
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/a1ab377d...90645b6f

src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 123:

> 121: 
> 122:     public static final class CachedClassHierarchyResolver implements ClassHierarchyResolver {
> 123:         //this instance should leak out, appears only in cache in order to utilize Map.computeIfAbsent

Missing??not?:
Suggestion:

        // this instance should not leak out, appears only in cache in order to utilize Map.computeIfAbsent

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1223479164

From brian.goetz at oracle.com  Thu Jun  8 19:57:54 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 8 Jun 2023 15:57:54 -0400
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
 <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>
Message-ID: <2cff101c-d1cb-e557-ff16-cf8240c6f799@oracle.com>

I still don't understand this point.? Why are separate tests sharing a 
context at all?

On 6/8/2023 9:26 AM, Adam Sotona wrote:
> Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare.
> I can fix our Corpus tests and hope the race condition won't raise also somewhere else later.
> However how to explain this limitation to users?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230608/affe7e76/attachment.htm>

From jvernee at openjdk.org  Thu Jun  8 20:24:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 8 Jun 2023 20:24:54 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
Message-ID: <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>

On Thu, 1 Jun 2023 20:06:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong link in layout well-formedness doc
>
> test/jdk/java/foreign/TestLayoutPaths.java line 125:
> 
>> 123:     }
>> 124: 
>> 125:     public void testByteOffsetHandleRange() {
> 
> Missing `@Test`?

FWIW, it looks like this needs `@Test(expectedExceptions = IllegalArgumentException.class)` since range elements are not allowed for `byteOffsetHandle`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1223511154

From jiangli at openjdk.org  Thu Jun  8 20:34:15 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 8 Jun 2023 20:34:15 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou 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 branch 'master' into JDK-8307858
 - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - Clean up.
 - ... and 9 more: https://git.openjdk.org/jdk/compare/c4e65425...c664c601

-------------

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=06
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From jjg at openjdk.org  Thu Jun  8 21:43:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Jun 2023 21:43:15 GMT
Subject: RFR: JDK-8309686: inconsistent URL for
 https://www.unicode.org/reports/tr35
Message-ID: <REcBL46mnOB7lxrqBVJfEl5go9audLpZSDtqEvkaZEA=.164107c3-956a-4213-b9c8-e9a88a149664@github.com>

Please review a trivial docs change to fix a URL in a `@spec` tag consistent with equivalent URLs in other tags.
(Consistency will be required when the External Specifications page is enabled.)

-------------

Commit messages:
 - JDK-8309686: inconsistent URL for https://www.unicode.org/reports/tr35

Changes: https://git.openjdk.org/jdk/pull/14384/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14384&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309686
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14384/head:pull/14384

PR: https://git.openjdk.org/jdk/pull/14384

From naoto at openjdk.org  Thu Jun  8 21:53:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 Jun 2023 21:53:40 GMT
Subject: RFR: JDK-8309686: inconsistent URL for
 https://www.unicode.org/reports/tr35
In-Reply-To: <REcBL46mnOB7lxrqBVJfEl5go9audLpZSDtqEvkaZEA=.164107c3-956a-4213-b9c8-e9a88a149664@github.com>
References: <REcBL46mnOB7lxrqBVJfEl5go9audLpZSDtqEvkaZEA=.164107c3-956a-4213-b9c8-e9a88a149664@github.com>
Message-ID: <00xtVJu6Nrk8wvGr7TzK8xJCp0qc7-QG349WnCXixwI=.0f8b7962-7f68-45e6-91fc-efc18a40ec2d@github.com>

On Thu, 8 Jun 2023 21:36:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial docs change to fix a URL in a `@spec` tag consistent with equivalent URLs in other tags.
> (Consistency will be required when the External Specifications page is enabled.)

My bad. Thanks for fixing the URL.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14384#pullrequestreview-1470819371

From manc at openjdk.org  Thu Jun  8 22:13:12 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Jun 2023 22:13:12 GMT
Subject: RFR: 8309688: Data race on java.io.ClassCache$CacheRef.strongReferent
Message-ID: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>

Hi all,

Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

-------------

Commit messages:
 - 8309688: Data race on java.io.ClassCache.strongReferent

Changes: https://git.openjdk.org/jdk/pull/14386/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309688
  Stats: 11 lines in 1 file changed: 1 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14386/head:pull/14386

PR: https://git.openjdk.org/jdk/pull/14386

From manc at openjdk.org  Thu Jun  8 22:14:40 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 8 Jun 2023 22:14:40 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <coCoMVzsZ5AoRD5bPl2w9y06N5mjXkM5d41wLhWZiIA=.4730d458-6527-4605-a831-707b2ed6528c@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

The pre-submit failures for windows are due to https://bugs.openjdk.org/browse/CODETOOLS-7903482.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1583457081

From jjg at openjdk.org  Thu Jun  8 22:19:47 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 8 Jun 2023 22:19:47 GMT
Subject: Integrated: JDK-8309686: inconsistent URL for
 https://www.unicode.org/reports/tr35
In-Reply-To: <REcBL46mnOB7lxrqBVJfEl5go9audLpZSDtqEvkaZEA=.164107c3-956a-4213-b9c8-e9a88a149664@github.com>
References: <REcBL46mnOB7lxrqBVJfEl5go9audLpZSDtqEvkaZEA=.164107c3-956a-4213-b9c8-e9a88a149664@github.com>
Message-ID: <C2bfcVLVTCZJZ34_2wFYULE84ke2Q4BgC4y8U-iWCz8=.27ee6001-10e2-4990-8421-452e8c0504dc@github.com>

On Thu, 8 Jun 2023 21:36:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial docs change to fix a URL in a `@spec` tag consistent with equivalent URLs in other tags.
> (Consistency will be required when the External Specifications page is enabled.)

This pull request has now been integrated.

Changeset: 6f492e80
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f492e800597c9ce332b9d5b54c00f551f145a0d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8309686: inconsistent URL for https://www.unicode.org/reports/tr35

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14384

From manc at openjdk.org  Fri Jun  9 01:05:56 2023
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Jun 2023 01:05:56 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <D0Wyj9tE1uTY2CD1GDOEXP60gJRgSniH7ZQ14xZuOpw=.ed82b915-1cc8-46da-8803-6d9f0cffb6f1@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

The presubmit failure on linux-x86 looks unrelated to this PR. It is https://bugs.openjdk.org/browse/JDK-8309592.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1583718746

From dholmes at openjdk.org  Fri Jun  9 01:39:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 Jun 2023 01:39:54 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
Message-ID: <kz5ylCE22pZTzL4PWsXqusTsKZumF55H9wMQhZ_IIy0=.7d1aef46-0e6e-4a5b-ad39-e3cf0ac206d4@github.com>

On Wed, 7 Jun 2023 15:12:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.
> 
> This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.
> 
> Testing: tier1-5

Changes look fine. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14361#pullrequestreview-1471042631

From jpai at openjdk.org  Fri Jun  9 04:58:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 04:58:53 GMT
Subject: RFR: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
Message-ID: <hVXm44G1Lf5QeJdUpNyk19Xwe1uRtt49Tln2gKKCcks=.06cea592-c76f-4609-8e25-994d471a3909@github.com>

On Wed, 7 Jun 2023 15:12:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.
> 
> This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.
> 
> Testing: tier1-5

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14361#pullrequestreview-1471228293

From asotona at openjdk.org  Fri Jun  9 06:19:42 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 06:19:42 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v10]
In-Reply-To: <QU1ZsVotsQTwtlp6E42zqsDWiB4stkj4lJbO1yZQz5c=.a5030342-8858-4bb2-9bdf-992ccfd44dda@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <8LzoOpItGA_LBdMX5sJxyPJNV2ZCavz2mIs8t1qrWhw=.908dd1f2-6250-4a43-844e-3dcd100be19e@github.com>
 <QU1ZsVotsQTwtlp6E42zqsDWiB4stkj4lJbO1yZQz5c=.a5030342-8858-4bb2-9bdf-992ccfd44dda@github.com>
Message-ID: <XNBfxW7noKrBQYi3Mx-3-L5W00lROMimOKlL6jm6jjI=.24394135-e32f-46e8-bc8e-56cfcaba7265@github.com>

On Thu, 8 Jun 2023 16:35:28 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

> I have a hard time imagining heavy parallel use here; concurrency against the same cache would most likely come from accidental sharing.? So this is not necessarily a problem.? Are you imagining differnet use cases?

I think it is common practice for example in web services to pre-configure as much of the common parts as possible (and Classfile context logically falls into that category) and then register the service to the server, which use group of thread workers to handle individual requests.
With (non-reusable) virtual threads and structured concurrency on the table makes internal use of thread locals even less sense. I can imagine a new virtual thread launched (and finished) for each individual transformation. Our `CorpusTest` relying on Junit parallelization  is not so far from that scenario (I'm not sure if Junit already uses virtual threads or just a group of workers).

It is technically irrelevant if user will share the context directly or through a `ClassModel` (for example an instrumentor class used to transform all incoming code - this BTW an idea of faster `j.l.r.ProxyGenerator` I'm thinking about). I think we should be sure that `Classfile` context (and also expansion of `ClassModel`) does not fail in parallel environments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584034695

From alanb at openjdk.org  Fri Jun  9 06:20:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 06:20:41 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods
In-Reply-To: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
Message-ID: <8VFTGt5LmczcxNXDsT3a0XGQrVVNmUBKIEH48vHR5rU=.b85de065-5ff0-4ee5-890a-5e857398ffc5@github.com>

On Thu, 8 Jun 2023 15:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14380#pullrequestreview-1471296218

From asotona at openjdk.org  Fri Jun  9 06:38:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 06:38:47 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
Message-ID: <I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com>

On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache

I'll run our standard benchmarks to compare following scenarios:
- static synchronized single instance cache (current master)
- context-based non-synchronized caches  `HM::computeIfAbsent`
- context-based fully synchronized caches `CHM::computeIfAbsent`
- context-based thread-safe lazy synchronized caches `CHM::get ... compute ... CHM::put`

And let's see the performance impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539

From adam.sotona at oracle.com  Fri Jun  9 06:54:54 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Fri, 9 Jun 2023 06:54:54 +0000
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v9]
In-Reply-To: <2cff101c-d1cb-e557-ff16-cf8240c6f799@oracle.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <rAc69XkrLAlzf8-ootepnoTNoD7cAwZK-Y5xJ0GPBns=.d1dc2a8d-ee97-450e-bd4e-defa751e4693@github.com>
 <BtKBI04H2enVA_iX7hBDqSIZPjGdtRrysVo4zJJIobc=.37f6497b-b922-4830-b3ad-89b0b7d0b658@github.com>
 <2cff101c-d1cb-e557-ff16-cf8240c6f799@oracle.com>
Message-ID: <CY4PR1001MB215054D2CB7F056FAFA0D0F08C51A@CY4PR1001MB2150.namprd10.prod.outlook.com>

The tests use statically specified Transforms and each transformation also held set of options.
Now the transformations hold static instance of Classfile context instead.
Junit execute them in parallel for each individual class file being transformed, so one context is used in parallel environment.
If we fall back to store List<Option> and create new Classfile context for each invocation ? we will degrade the performance significantly (starting always with an empty cache).
Trying to stick Classfile context with thread locality is possible, however it requires to re-design our CorpusTest and Transforms and performance will be randomly dependent on Junit decision about threads assignment. Also Junit may silently move to virtual threads (unless it already did) and performance will be back to an empty cache for each invocation.


From: Brian Goetz <brian.goetz at oracle.com>
Date: Thursday, 8 June 2023 21:58
To: Adam Sotona <asotona at openjdk.org>, core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>, kulla-dev at openjdk.org <kulla-dev at openjdk.org>
Subject: Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v9]
I still don't understand this point.  Why are separate tests sharing a context at all?
On 6/8/2023 9:26 AM, Adam Sotona wrote:

Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare.

I can fix our Corpus tests and hope the race condition won't raise also somewhere else later.

However how to explain this limitation to users?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230609/68a83b95/attachment-0001.htm>

From duke at openjdk.org  Fri Jun  9 07:27:09 2023
From: duke at openjdk.org (Romain Manni-Bucau)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an Iterator
 rather than Enumeration
Message-ID: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>

enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.

Another side but nice effect is to have some lighter classloading (subgraph)

-------------

Commit messages:
 - [JDK-8305947] Unify SequenceInputStream 'backend' using an Iterator which enables to avoid one abstraction for binary case

Changes: https://git.openjdk.org/jdk/pull/11718/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305947
  Stats: 19 lines in 1 file changed: 12 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11718/head:pull/11718

PR: https://git.openjdk.org/jdk/pull/11718

From duke at openjdk.org  Fri Jun  9 07:27:09 2023
From: duke at openjdk.org (Benjamin Marwell)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
Message-ID: <fl6glarOr0RrKDh2NFcN1VBOt7qkcH3UlZhfo9ix1bk=.2f7bf4f0-0465-454f-b449-2c93461a2bff@github.com>

On Mon, 19 Dec 2022 11:26:25 GMT, Romain Manni-Bucau <duke at openjdk.org> wrote:

> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
> 
> Another side but nice effect is to have some lighter classloading (subgraph)

Greatly spotted! ??
This will also introduce a new constructor which is much more handy than the previous ones.

bump - forgot to send a mail to the mailing list.

bump

-------------

Marked as reviewed by bmarwell at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/11718#pullrequestreview-1222737433
PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1500913999
PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1584022022

From duke at openjdk.org  Fri Jun  9 07:27:09 2023
From: duke at openjdk.org (Romain Manni-Bucau)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
Message-ID: <9GinJEQm7Gt0ma4pRtY-Jvfh_5GwEOsvZLAORAtzCP0=.5c2eb448-50b4-4d72-b6c5-a75c21891c8e@github.com>

On Mon, 19 Dec 2022 11:26:25 GMT, Romain Manni-Bucau <duke at openjdk.org> wrote:

> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
> 
> Another side but nice effect is to have some lighter classloading (subgraph)

Still hope it can make it to the jdk.

think it is still relevant

would be great to get it onboard instead of letting it dying slowly if possible, guess commit message can be edited at merge time with github and comments were addressed AFAIK so looks ready for me

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1384464985
PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1438146415
PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1544428157

From jpai at openjdk.org  Fri Jun  9 07:27:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <9GinJEQm7Gt0ma4pRtY-Jvfh_5GwEOsvZLAORAtzCP0=.5c2eb448-50b4-4d72-b6c5-a75c21891c8e@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
 <9GinJEQm7Gt0ma4pRtY-Jvfh_5GwEOsvZLAORAtzCP0=.5c2eb448-50b4-4d72-b6c5-a75c21891c8e@github.com>
Message-ID: <DyVnDTjNLasSO92neLtwTArSF25QxdUJ3hSe7gcsfTA=.141e45c7-0995-43f7-b190-cd1493051849@github.com>

On Mon, 16 Jan 2023 19:21:36 GMT, Romain Manni-Bucau <duke at openjdk.org> wrote:

>> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
>> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
>> 
>> Another side but nice effect is to have some lighter classloading (subgraph)
>
> Still hope it can make it to the jdk.

Hello @rmannibucau, PRs which do not have a corresponding bug tracker issue, don't trigger the review process (backed by bots). Typically, for obvious fixes/changes, someone with access to the JDK issue tracker creates a issue and then helps the PR author to update the PR title to match that bug id and summary. 

In cases like this current one, where it isn't clear whether this change is necessary, it's recommended that the change be first discussed in the relevant dev mailing list before creating a JDK issue (and proposing the PR) for it. 

For the current change, core-libs-dev is the right mailing list https://mail.openjdk.org/mailman/listinfo/core-libs-dev. Could you please open a discussion there about this change and request for inputs? You will have to subscribe to that list first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1401467296

From duke at openjdk.org  Fri Jun  9 07:27:09 2023
From: duke at openjdk.org (Benjamin Marwell)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <DyVnDTjNLasSO92neLtwTArSF25QxdUJ3hSe7gcsfTA=.141e45c7-0995-43f7-b190-cd1493051849@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
 <9GinJEQm7Gt0ma4pRtY-Jvfh_5GwEOsvZLAORAtzCP0=.5c2eb448-50b4-4d72-b6c5-a75c21891c8e@github.com>
 <DyVnDTjNLasSO92neLtwTArSF25QxdUJ3hSe7gcsfTA=.141e45c7-0995-43f7-b190-cd1493051849@github.com>
Message-ID: <DK9tbmjA1Frazt3qxMPW4q1kzxTNtrrPR4O-7JYcyo4=.6f678812-6067-4926-bcb1-528db5bcd11c@github.com>

On Tue, 24 Jan 2023 06:54:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> PRs which do not have a corresponding bug tracker issue

Will write to the mailing list

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1464897988

From jpai at openjdk.org  Fri Jun  9 07:27:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
Message-ID: <_8heB5v9WJsrp1gLGLYQUBaxY5MaIpjcox_6AOriU2E=.68fb914a-28a7-41d1-8f65-076970e0f9fa@github.com>

On Mon, 19 Dec 2022 11:26:25 GMT, Romain Manni-Bucau <duke at openjdk.org> wrote:

> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
> 
> Another side but nice effect is to have some lighter classloading (subgraph)

This was brought up on the core-libs dev mailing list and a JBS issue has been created for this a while back https://bugs.openjdk.org/browse/JDK-8305947. Please update the title of this PR to `8305947: SequenceInputStream implementation can use an Iterator rather than Enumeration` to trigger a official review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1584033379

From duke at openjdk.org  Fri Jun  9 07:27:09 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
Message-ID: <g_wQved39r5cuZOG_TeNggGxL39QPuNq_is9Rt2c0go=.65655a95-3e1a-4772-9ca1-09a01c77ff2a@github.com>

On Mon, 19 Dec 2022 11:26:25 GMT, Romain Manni-Bucau <duke at openjdk.org> wrote:

> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
> 
> Another side but nice effect is to have some lighter classloading (subgraph)

src/java.base/share/classes/java/io/SequenceInputStream.java line 82:

> 80:      */
> 81:     public SequenceInputStream(InputStream s1, InputStream s2) {
> 82:         this(List.of(s1, s2).iterator());

This changes the behaviour for null streams. This line will throw NPE. The previous code throwed NPE in `peekNextStream`, only if the stream was used.

Have your make sure that it is okay to change behaviour?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11718#discussion_r1162428158

From duke at openjdk.org  Fri Jun  9 07:27:09 2023
From: duke at openjdk.org (Romain Manni-Bucau)
Date: Fri, 9 Jun 2023 07:27:09 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <g_wQved39r5cuZOG_TeNggGxL39QPuNq_is9Rt2c0go=.65655a95-3e1a-4772-9ca1-09a01c77ff2a@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
 <g_wQved39r5cuZOG_TeNggGxL39QPuNq_is9Rt2c0go=.65655a95-3e1a-4772-9ca1-09a01c77ff2a@github.com>
Message-ID: <zcVjcmtSqsSEPPMhHAxKRda4i_C7KlVXkhAJTHdl8AM=.6f036451-70c8-4b3b-b0d9-9382d5da4378@github.com>

On Tue, 11 Apr 2023 07:48:45 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
>> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
>> 
>> Another side but nice effect is to have some lighter classloading (subgraph)
>
> src/java.base/share/classes/java/io/SequenceInputStream.java line 82:
> 
>> 80:      */
>> 81:     public SequenceInputStream(InputStream s1, InputStream s2) {
>> 82:         this(List.of(s1, s2).iterator());
> 
> This changes the behaviour for null streams. This line will throw NPE. The previous code throwed NPE in `peekNextStream`, only if the stream was used.
> 
> Have your make sure that it is okay to change behaviour?

good catch, switching back to Arrays.asList then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11718#discussion_r1162434746

From alanb at openjdk.org  Fri Jun  9 07:32:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 07:32:49 GMT
Subject: Integrated: 8309545: Thread.interrupted from virtual thread needlessly
 resets interrupt status
In-Reply-To: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
References: <4knBoamdYaN-bauCPfgm-gfat2fZOTtq1KOQxnFAzE4=.39f02244-7b97-4404-9a40-405a2f506251@github.com>
Message-ID: <c76Me-_NEbqkXmOIVJ0HLaN1-8QuBL3wB4IjN5RO4gY=.0244ea48-a75d-410a-a662-1f3adc8ae1b1@github.com>

On Wed, 7 Jun 2023 15:12:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.interrupted is used to "get and clear" the current thread's interrupt status. When called from a virtual thread, the current implementation always clears the carrier's interrupt status. There is no need to do this when the interrupt status is not set, it can just read the interrupt status and return false in that case.
> 
> This was found by Sergey Kuksenko when comparing platform vs. virtual thread performance. Once CODETOOLS-7903476 is in a released version of JMH then we can start to accumulate benchmarks that execute in virtual threads.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: 97df6cf5
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97df6cf55ab66552612bf0a2eefb83c0783fd586
Stats:     6 lines in 1 file changed: 1 ins; 0 del; 5 mod

8309545: Thread.interrupted from virtual thread needlessly resets interrupt status

Reviewed-by: rpressler, dholmes, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14361

From alanb at openjdk.org  Fri Jun  9 08:02:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 08:02:45 GMT
Subject: RFR: 8309702: Exclude java/lang/ScopedValue/StressStackOverflow.java
 from JTREG_TEST_THREAD_FACTORY=Virtual runs
Message-ID: <KEtHUiHs1tc3k1Tg4taXrvKM7iFAhfFisedJ3F4cGnE=.3f1c1609-390e-4594-96eb-7feddba83c2f@github.com>

This test moved from test/jdk/jdk/incubator/concurrent to test/jdk/java/lang as part of the JEP 446 integration so it is running in a lot more configurations now. It's unstable in some configurations, including JTREG_TEST_THREAD_FACTORY=Virtual runs. The implementation may need more @DontInline/@ReservedStackAccess foo, or the test needs to made more stable. Need to temporarily exclude to reduce noise until the implementation or test is fixed.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14388&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309702
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14388/head:pull/14388

PR: https://git.openjdk.org/jdk/pull/14388

From jpai at openjdk.org  Fri Jun  9 08:28:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 08:28:40 GMT
Subject: RFR: 8309702: Exclude
 java/lang/ScopedValue/StressStackOverflow.java from
 JTREG_TEST_THREAD_FACTORY=Virtual runs
In-Reply-To: <KEtHUiHs1tc3k1Tg4taXrvKM7iFAhfFisedJ3F4cGnE=.3f1c1609-390e-4594-96eb-7feddba83c2f@github.com>
References: <KEtHUiHs1tc3k1Tg4taXrvKM7iFAhfFisedJ3F4cGnE=.3f1c1609-390e-4594-96eb-7feddba83c2f@github.com>
Message-ID: <Ch5RYjcdNuCM49WMzidFB8VJgMff9uFmMouuf75esX0=.72437993-c8ab-46c5-b9e3-221342f024aa@github.com>

On Fri, 9 Jun 2023 07:51:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test moved from test/jdk/jdk/incubator/concurrent to test/jdk/java/lang as part of the JEP 446 integration so it is running in a lot more configurations now. It's unstable in some configurations, including JTREG_TEST_THREAD_FACTORY=Virtual runs. The implementation may need more @DontInline/@ReservedStackAccess foo, or the test needs to made more stable. Need to temporarily exclude to reduce noise until the implementation or test is fixed.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14388#pullrequestreview-1471485459

From alanb at openjdk.org  Fri Jun  9 08:36:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 08:36:48 GMT
Subject: Integrated: 8309702: Exclude
 java/lang/ScopedValue/StressStackOverflow.java from
 JTREG_TEST_THREAD_FACTORY=Virtual runs
In-Reply-To: <KEtHUiHs1tc3k1Tg4taXrvKM7iFAhfFisedJ3F4cGnE=.3f1c1609-390e-4594-96eb-7feddba83c2f@github.com>
References: <KEtHUiHs1tc3k1Tg4taXrvKM7iFAhfFisedJ3F4cGnE=.3f1c1609-390e-4594-96eb-7feddba83c2f@github.com>
Message-ID: <LdfosxNl45WCArZtZpF60Td8DiHxaUIQQAYDlEAvjjU=.77f202c5-b9ed-4508-9940-872d04e7425c@github.com>

On Fri, 9 Jun 2023 07:51:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test moved from test/jdk/jdk/incubator/concurrent to test/jdk/java/lang as part of the JEP 446 integration so it is running in a lot more configurations now. It's unstable in some configurations, including JTREG_TEST_THREAD_FACTORY=Virtual runs. The implementation may need more @DontInline/@ReservedStackAccess foo, or the test needs to made more stable. Need to temporarily exclude to reduce noise until the implementation or test is fixed.

This pull request has now been integrated.

Changeset: 30708561
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/307085618d76f49f982453253c27a3cb2b9728c3
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8309702: Exclude java/lang/ScopedValue/StressStackOverflow.java from JTREG_TEST_THREAD_FACTORY=Virtual runs

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14388

From liach at openjdk.org  Fri Jun  9 08:37:43 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 9 Jun 2023 08:37:43 GMT
Subject: RFR: 8180892: Correct handling of annotations on parameters [v2]
In-Reply-To: <TwuU-R1pNpx9rCfyEEehPaO72LmCMtPF6MZqWSDWksI=.f70a4aaf-6c09-4e02-ae05-dbafb69ae3fe@github.com>
References: <A5gWbMb6WLzQW2wbgC5USyPITDoslCEJKWCEO1IGOgs=.d89a8805-8e74-4e2f-8fcd-a4768c95ef7e@github.com>
 <TwuU-R1pNpx9rCfyEEehPaO72LmCMtPF6MZqWSDWksI=.f70a4aaf-6c09-4e02-ae05-dbafb69ae3fe@github.com>
Message-ID: <vSB7zUsQ6Bv64LmzZhCspTBYhzSrtOiPVf-oIFoyI4U=.0064d29c-bd20-48ac-b151-816c88bc439f@github.com>

On Wed, 26 Apr 2023 14:46:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch aims to correct handling of annotations on parameters with the help of `MethodParameters` attribute, which will be always available once #9862 is integrated.
>> 
>> It utilizes and expands upon the existing parameter matching logic present in `Executable::getAllGenericParameterTypes`, and delegate parameter parameterized types, parameter annotation, and parameter type annotation accesses through the matched results, if matching is available. If matching failed, it falls back to existing heuristics that works without `MethodParameters` attributes for annotations, in `Executable::handleParameterNumberMismatch` and `TypeAnnotationParser::buildAnnotatedTypes` (renamed `buildAnnotatedTypesWithHeuristics` in this patch)
>> 
>> `ParameterMappingTest` covers these scenarios with class files that have `MethodParameters` or `Signature` attributes stripped or preserved to ensure the new Reflection API implementation works for both class files generated before #9862 and after its integration.
>> 
>> Also special thanks to Joe Darcy for reviewing 8304918 (#13183); this brings much convenience to this patch.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assuming match without MethodParameters for type annotations, move implementation related to getAnnotatedParameterTypes to around it

Now that JDK 21 is RDP 1, should we take a look at this now?
This patch makes use of MethodParameters information to map (explicit) parameter annotations to formal parameters. In case that information is not available, the code falls back to the existing heuristic that guesses the offset for inner classes.

Two more potential issues with core reflection and annotations/generics include:
1. `getGenericParameterTypes()[i]` usages should be replaced by `getParameters()[i].getParameterizedType()`, which returns the correct generic type if MethodParameters attribute is present
2. There is some issues with `Constructor.getAnnotatedReceiverType()` due to some effectively-static local and anonymous classes (like ones in static methods and initializers); this is tracked at [JDK-8162500](https://bugs.openjdk.org/browse/JDK-8162500). Those classes don't carry enough information about whether they should have an mandated outer instance parameter, such as through a static flag in InnerClasses attribute; might need Javac tweaks to fix that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13664#issuecomment-1584187625

From vladimir.petko at canonical.com  Fri Jun  9 08:53:22 2023
From: vladimir.petko at canonical.com (Vladimir Petko)
Date: Fri, 9 Jun 2023 20:53:22 +1200
Subject: test/jdk/java/foreign/TestLayouts.java fails on S390X
Message-ID: <CALFf3kd+sJfb=_ur+HPHSe-dkjoyxy8SCVr5=7d8q3p0vt8+qw@mail.gmail.com>

Dear Maintainers,

test/jdk/java/foreign/TestLayouts.java assumes little endian
architecture and hardcoded string representation of int.
This results in the following failure:
-----cut-----
test TestLayouts.testStructToString(): failure
java.lang.AssertionError: expected [[i4](struct)] but found [[I4](struct)]
-----cut-----
as JAVA_INT is represented as 'I4' for big endian.

Would it be possible to consider the attached patch to resolve the issue?

Best Regards,
 Vladimir.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestLayouts.patch
Type: text/x-patch
Size: 1012 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230609/ce4c5db6/TestLayouts.patch>

From duke at openjdk.org  Fri Jun  9 09:19:48 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 9 Jun 2023 09:19:48 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors
Message-ID: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>

The test used a too-small heap for generic testing, and coupled with looking at `freeMemory()` it led to a less-than-ideal determinism of execution of the test.

-------------

Commit messages:
 - Increasing minimum heap size to make the BasicCancelTest complete more timely,

Changes: https://git.openjdk.org/jdk/pull/14389/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14389&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308047
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14389.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14389/head:pull/14389

PR: https://git.openjdk.org/jdk/pull/14389

From stefank at openjdk.org  Fri Jun  9 09:48:42 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jun 2023 09:48:42 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors
In-Reply-To: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
Message-ID: <N8B2TfLOxQweZDfIPMUucsMWrWOg2_OuSywf3u2ovWU=.21be72f6-1700-42dc-80b5-7bdd7ebf5e4d@github.com>

On Fri, 9 Jun 2023 09:13:08 GMT, Viktor Klang <duke at openjdk.org> wrote:

> The test used a too-small heap for generic testing, and coupled with looking at `freeMemory()` it led to a less-than-ideal determinism of execution of the test.

Did you test if this significantly changed the execution time of the test? I'm wondering if it would make sense to change this to something smaller, say `maxMemory / 32`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14389#pullrequestreview-1471626631

From redestad at openjdk.org  Fri Jun  9 10:03:08 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 9 Jun 2023 10:03:08 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods [v2]
In-Reply-To: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
Message-ID: <Hrb043BV1589iy9XXYPs0W9wgycH_w8iba0g1IUnE1g=.c75e91a0-bf4d-4f75-a794-4399c7a233c1@github.com>

> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Remove pointless comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14380/files
  - new: https://git.openjdk.org/jdk/pull/14380/files/09b06d77..ae809dfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14380&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14380&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14380.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14380/head:pull/14380

PR: https://git.openjdk.org/jdk/pull/14380

From redestad at openjdk.org  Fri Jun  9 10:03:08 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 9 Jun 2023 10:03:08 GMT
Subject: Integrated: 8309665: Simplify Arrays.copyOf/-Range methods
In-Reply-To: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
Message-ID: <iSlufH5qSs0iN90csbXH_LYR4X7XEydv0AQcOPFYLe8=.e60daa2f-bcd4-4746-89f2-bc495c9846cf@github.com>

On Thu, 8 Jun 2023 15:08:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8301958 and later changes improved Arrays.copyOf/-Range methods to improve peak performance in microbenchmarks when copying the entire array, but it's resulted in a few lurking footprint benchmark issues that come down to incurring slightly more JIT activity. As a partial remedy I propose simplifying the implementation so that no new methods are added compared to the JDK 20 baseline. This patch maintains the microbenchmark speed-up from JDK-8301958 while reducing JIT compilations in startup/footprint benchmarks.

This pull request has now been integrated.

Changeset: dc842e85
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc842e8587f1e27ef599abeec80a38a043b3d0b3
Stats:     107 lines in 1 file changed: 25 ins; 64 del; 18 mod

8309665: Simplify Arrays.copyOf/-Range methods

Reviewed-by: jlaskey, rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14380

From redestad at openjdk.org  Fri Jun  9 10:03:08 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 9 Jun 2023 10:03:08 GMT
Subject: RFR: 8309665: Simplify Arrays.copyOf/-Range methods [v2]
In-Reply-To: <jpZ5A4DeZOuOP7YKf15CRktnxNu2u0L4YlIHDQPVF0Q=.3be78670-c2fc-4b90-851b-3b9db00338e3@github.com>
References: <kiMWLfzJrGppuyzegf5Uk6hrGrYzrQ1bGf4X9XTJCJI=.fc98b55f-c83c-4417-9ae1-27783a51b68f@github.com>
 <jpZ5A4DeZOuOP7YKf15CRktnxNu2u0L4YlIHDQPVF0Q=.3be78670-c2fc-4b90-851b-3b9db00338e3@github.com>
Message-ID: <ttkTgCFnn6NkT3fk8HCmLJWETDVzvQ1_MoUKt5AjiFQ=.8dff1db4-8ef2-4e5e-a100-89a7b47d86a2@github.com>

On Thu, 8 Jun 2023 16:15:21 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove pointless comments
>
> src/java.base/share/classes/java/util/Arrays.java line 3845:
> 
>> 3843:      */
>> 3844:     public static byte[] copyOfRange(byte[] original, int from, int to) {
>> 3845:         // Tickle the JIT to fold special cases optimally
> 
> this comment has been inconsistently left vs removed in the various methods (even though the other changes appear the same). was this intentional?

Fixed. Removed all for consistency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14380#discussion_r1224108002

From duke at openjdk.org  Fri Jun  9 10:07:31 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 9 Jun 2023 10:07:31 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
Message-ID: <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>

> The test used a too-small heap for generic testing, and coupled with looking at `freeMemory()` it led to a less-than-ideal determinism of execution of the test.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Decresing the number of iterations proportional to the increase in the max memory size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14389/files
  - new: https://git.openjdk.org/jdk/pull/14389/files/b8d547c8..1d137e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14389&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14389&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14389.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14389/head:pull/14389

PR: https://git.openjdk.org/jdk/pull/14389

From duke at openjdk.org  Fri Jun  9 10:09:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 9 Jun 2023 10:09:42 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <N8B2TfLOxQweZDfIPMUucsMWrWOg2_OuSywf3u2ovWU=.21be72f6-1700-42dc-80b5-7bdd7ebf5e4d@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
 <N8B2TfLOxQweZDfIPMUucsMWrWOg2_OuSywf3u2ovWU=.21be72f6-1700-42dc-80b5-7bdd7ebf5e4d@github.com>
Message-ID: <Ji7TSfwFE3mKzxOPloOdq8rbewpAF3N5pN6X_MuYHE4=.ab291473-6427-4ad3-ae86-794af1492f13@github.com>

On Fri, 9 Jun 2023 09:45:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decresing the number of iterations proportional to the increase in the max memory size
>
> Did you test if this significantly changed the execution time of the test? I'm wondering if it would make sense to change this to something smaller, say `maxMemory / 32`?

@stefank Good point. The runtime didn't meaningfully change on my own machine, but I've now decresed the iterations proportionally to the memory, and made sure that it still errors out (locally) if it doesn't GC the tasks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14389#issuecomment-1584320889

From alanb at openjdk.org  Fri Jun  9 10:49:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 10:49:39 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
In-Reply-To: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
References: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
Message-ID: <uCaGStjWpGVU0gw1lPnnQCSlV4EQUCf9mN4wtypc-h8=.9a984768-86f7-41dc-ace8-8900f7c22b76@github.com>

On Thu, 8 Jun 2023 18:56:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The `RuntimeArguments` test verifies the VM arguments returned by `jdk.internal.misc.VM::getRuntimeArguments` as expected.    This test fails when running with GraalVM as it was created with `jlink --add-options` and the application will always be launched with that additional set of VM options.  This PR updates the test to read if 'jdk/internal/vm/options` is present and includle those options in the expected list.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14383#pullrequestreview-1471711972

From brian.goetz at oracle.com  Fri Jun  9 11:02:33 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 9 Jun 2023 07:02:33 -0400
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
 <I1oi--jOrgA4cAMIQhpiL7q3DdHCxMWaf6To9d0LGGU=.73eb9ca8-941c-4283-9154-dfce8d0594a2@github.com>
Message-ID: <e5b34f5e-216c-8938-b91a-5836b6b01541@oracle.com>

Observation: It's dramatic how injecting a tiny amount of shared mutable 
state ripples throughout the design.

After thinking about this some more, I think the main problem is that we 
are still trying to have the cache be transparent, which means that 
Classfile is taking on all the complexity of unbounded shared mutability 
"just in case" the user wants some.

The other part of this refactor, which we've not done yet, is 
refactoring the caching of the CHR data (through Option) so it is more 
explicit.? I think part of what we're running into here is that we've 
not done that part yet, so we are stills stuck in the as-if-static world.

So let's take a step back and sketch out what the CHR/caching options 
might look like.? If we make caching explicit, we can make sharability 
explicit too, and then we are not trying to add thread-safety back into 
a seemingly-immutable-but-not-really object.

On 6/9/2023 2:38 AM, Adam Sotona wrote:
> On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona<asotona at openjdk.org>  wrote:
>
>>> Classfile context object and multi-state options have been discussed athttps://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>>>
>>> Please review.
>>>
>>> Thanks,
>>> Adam
>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>>
>>   - proposed semi-synchronized caching, where the map is not locked during delegate call
>>   - used Factory.INSTANCE for system ClassHierarchyResolver cache
> I'll run our standard benchmarks to compare following scenarios:
> - static synchronized single instance cache (current master)
> - context-based non-synchronized caches  `HM::computeIfAbsent`
> - context-based fully synchronized caches `CHM::computeIfAbsent`
> - context-based thread-safe lazy synchronized caches `CHM::get ... compute ... CHM::put`
>
> And let's see the performance impact.
>
> -------------
>
> PR Comment:https://git.openjdk.org/jdk/pull/14180#issuecomment-1584050539
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230609/e065f743/attachment-0001.htm>

From asotona at openjdk.org  Fri Jun  9 11:35:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 11:35:48 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
Message-ID: <Zy8zwtxdiqQ9MTETR6eWNdc27qul2XiDlE8rG5C3Z-I=.e9e1877f-31ac-4a37-b14a-b79a629391fa@github.com>

On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache

I've performed a lot of benchmarking and the key result is that introduction of `Classfile` context (or rather say context specific CHR instead of global static field) cause a lot of regressions in our benchmarks.

Below are aggregated only relative results of benchmarks with significant regressions.
Current `master` with global static cache instance is the base for relative regressions in the table.
- `ConcurrentHashMap::computeIfAbsent` represents the initial fully-synchronized cache implementation.
- `HashMap::computeIfAbsent` is the thread-unsafe option.
- `ConcurrentHashMap::get and put` is the lazy-synchronized solution
- **Always create a fresh context with an empty cache** is what Brian proposed as one of the options
- **Class loading with local cache only** is a step back to what ASM is using.


Interesting point is that **Always create a fresh context with an empty cache** works with similar performance as the others, except for `GenerateStackMaps.benchmark`, where it causes significant regression.

**Class loading with local cache only** assumes `ClassLoader` would do the caching for us. Even the class loading is initially slower and does not work for all use cases, it may be the best for the default CHR. And we could skip any `CHR::cached` in the API. 

Also interesting is that `ConcurrentHashMap::computeIfAbsent` cause 10% regression of **ParseOptions.transformNoStackmap** benchmark, where it should have no or minimal effect.

? | `ConcurrentHashMap::computeIfAbsent` | `HashMap::computeIfAbsent` | `ConcurrentHashMap::get and put` | Always create a fresh context with an empty cache | Class loading with local cache only
-- | -- | -- | -- | -- | --
AdHocAdapt.transform LIFT | -19% | -17% | -16% | -17% | -17%
AdHocAdapt.transform LIFT1 | -24% | -25% | -23% | -26% | -23%
AdHocAdapt.transform LIFT2 | -23% | -26% | -23% | -25% | -23%
AdaptInjectNoop.transform NOP_SHARED | -16% | -19% | -16% | -18% | -7%
AdaptNull.transform SHARED_3 | -18% | -21% | -19% | -17% | -18%
AdaptNull.transform SHARED_3_NO_DEBUG | -22% | -22% | -25% | -21% | -22%
GenerateStackMaps.benchmark | ? | ? | ? | -27% | ?
ParseOptions.transformNoDebug | -31% | -20% | -20% | -19% | -18%
ParseOptions.transformNoLineNumbers | -25% | -24% | -20% | -20% | -20%
ParseOptions.transformNoStackmap | -10% | ? | ? | ? | ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584430448

From briangoetz at openjdk.org  Fri Jun  9 11:47:47 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Fri, 9 Jun 2023 11:47:47 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
Message-ID: <fw7mnM-TCfmyIIRzZ4SUvoj_oqqGYpiYzLU21LEq5mQ=.2a85f959-ec34-4730-bec0-7e29bb9ea737@github.com>

On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache

FWIW: I have found AdaptNull.SHARED_3 to be among the most useful 
benchmarks for finding unexpected regressions.

I think there's something fishy going on.? Given that the baseline 
(static shared cache) has to protect against concurrent access already, 
and that there should be little or no other significant difference 
between the static version and the context version aside from caching, I 
can't see how those differences explain these regressions.? Are we 
making an apples-to-apples comparison of what CHR algorithm we're using? 
Is the creation of the CHR instances is perturbing the results?

Let's try to take CHR operation out of the equation: runt both baseline 
and context versions using a CHR that does almost nothing (e.g., says 
LUB(a,b) is always Object) or which uses a precomputed static cache.? 
I'm guessing this shows no regression, and if so, this will likely tell 
us that the _context_ refactor is not the problem, but attempting to 
unshare the CHR cache.? Then we can drill into that problem.



On 6/9/2023 7:31 AM, Adam Sotona wrote:
>
> I've performed a lot of benchmarking and the key result is that 
> introduction of |Classfile| context cause a lot of regressions in our 
> benchmarks.
>
> Below are aggregated only relative results of benchmarks with 
> significant regressions.
> Current |master| with global static cache instance is a base for the 
> relative regressions in the table.
>
>   * |ConcurrentHashMap::computeIfAbsent| represents the initial
>     fully-synchronized cache implementation.
>   * |HashMap::computeIfAbsent| is the thread-unsafe option.
>   * |ConcurrentHashMap::get and put| is the lazy-synchronized solution
>   * *Always create a fresh context with an empty cache* is what Brian
>     proposed as one of the options
>   * *Class loading with local cache only* is a step back to what ASM
>     is using.
>
> Interesting point is that *Always create a fresh context with an empty 
> cache* works with similar performance as the others, except for 
> |GenerateStackMaps.benchmark|, where it causes significant regression.
>
> *Class loading with local cache only* assumes |ClassLoader| would do 
> the caching for us. Even the class loading is initially slower and 
> does not work for all use cases, it may be the best for the default 
> CHR. And we could skip any |CHR::cached| in the API.
>
> Also interesting is that |ConcurrentHashMap::computeIfAbsent| cause 
> 10% regression of *ParseOptions.transformNoStackmap* benchmark, where 
> it should have no or minimal effect.
>
> 	|ConcurrentHashMap::computeIfAbsent| 	|HashMap::computeIfAbsent| 
> |ConcurrentHashMap::get and put| 	Always create a fresh context with 
> an empty cache 	Class loading with local cache only
> AdHocAdapt.transform LIFT 	-19% 	-17% 	-16% 	-17% 	-17%
> AdHocAdapt.transform LIFT1 	-24% 	-25% 	-23% 	-26% 	-23%
> AdHocAdapt.transform LIFT2 	-23% 	-26% 	-23% 	-25% 	-23%
> AdaptInjectNoop.transform NOP_SHARED 	-16% 	-19% 	-16% 	-18% 	-7%
> AdaptNull.transform SHARED_3 	-18% 	-21% 	-19% 	-17% 	-18%
> AdaptNull.transform SHARED_3_NO_DEBUG 	-22% 	-22% 	-25% 	-21% 	-22%
> GenerateStackMaps.benchmark 				-27% 	
> ParseOptions.transformNoDebug 	-31% 	-20% 	-20% 	-19% 	-18%
> ParseOptions.transformNoLineNumbers 	-25% 	-24% 	-20% 	-20% 	-20%
> ParseOptions.transformNoStackmap 	-10% 				
>
> ?
> Reply to this email directly, view it on GitHub 
> <https://github.com/openjdk/jdk/pull/14180#issuecomment-1584430448>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/AABJ4RD7CBCQU3MSP4LJVILXKMCP3ANCNFSM6AAAAAAYQLACYQ>.
> You are receiving this because you commented.Message ID: 
> ***@***.***>
>

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584445113

From stefank at openjdk.org  Fri Jun  9 11:56:49 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 Jun 2023 11:56:49 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
 <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
Message-ID: <oY539hUvQyMNoBNOmfemF2GjDhbueUVe-rzUgMzIrKg=.eec7e413-9745-4935-a038-0e715caa4991@github.com>

On Fri, 9 Jun 2023 10:07:31 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> The test used a too-small heap for generic testing, and coupled with looking at `freeMemory()` it led to a less-than-ideal determinism of execution of the test.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decresing the number of iterations proportional to the increase in the max memory size

I'm happy with the changes, but make sure to get a Review from one of the maintainers of this code area. Thanks.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14389#pullrequestreview-1471817200

From tholenstein at openjdk.org  Fri Jun  9 12:55:47 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Fri, 9 Jun 2023 12:55:47 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v3]
In-Reply-To: <1iF_2pFExGpBX1dxqyM6TiQecD8o1qSJWeIv4HVG0vE=.930245c2-8033-402e-a0e8-0a7e3ffaff6c@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <1iF_2pFExGpBX1dxqyM6TiQecD8o1qSJWeIv4HVG0vE=.930245c2-8033-402e-a0e8-0a7e3ffaff6c@github.com>
Message-ID: <6e9OLFYSVDsASSN0k8mSceLxSQf5FuchlB45eokbscI=.75ea9cb1-2891-4025-9101-131e80034bdf@github.com>

On Wed, 17 May 2023 16:52:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with 11 additional commits since the last revision:
>> 
>>  - Update TestStableUShort.java
>>  - Update TestStableUByte.java
>>  - Update TestStableShort.java
>>  - Update TestStableObject.java
>>  - Update TestStableLong.java
>>  - Update TestStableInt.java
>>  - Update TestStableFloat.java
>>  - Update TestStableDouble.java
>>  - Update TestStableChar.java
>>  - Update TestStableByte.java
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/40b17296...e320a9de
>
> Thank you for fixing this finally!
> 
> FTR. We planned to do this for long time. Main motivations: unify syntax and catch invalid commands.

Thanks for the reviews @vnkozlov , @chhagedorn and @TobiHartmann

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13802#issuecomment-1584530237

From chegar at openjdk.org  Fri Jun  9 13:12:06 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 13:12:06 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
Message-ID: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>

A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").

The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.

This is the only such security manager related issue I see in this code, and I have looked.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/14392/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14392&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309727
  Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14392.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14392/head:pull/14392

PR: https://git.openjdk.org/jdk/pull/14392

From chegar at openjdk.org  Fri Jun  9 13:12:07 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 13:12:07 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
Message-ID: <c5o8u73sgpm-r0FTK1qy1v2UihyLqCf1rVCNZqFneMc=.8ebdb071-21f0-4f66-8a59-3315ce7e9e5d@github.com>

On Fri, 9 Jun 2023 13:02:18 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
> 
> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
> 
> This is the only such security manager related issue I see in this code, and I have looked.

@PaulSandoz We just ran into this yesterday, https://github.com/elastic/elasticsearch/pull/96715. The change here is trivial.

test/jdk/jdk/incubator/vector/VectorRuns.java line 32:

> 30:  * @modules jdk.incubator.vector
> 31:  * @run main VectorRuns
> 32:  * @run main/othervm/java.security.policy=empty_security.policy VectorRuns

I just added a minimal test here, so as not to otherwise disturb other areas. This is sufficient to very the fix, and ensure that it does not reoccur.

test/jdk/jdk/incubator/vector/VectorRuns.java line 73:

> 71:             return a.length;
> 72: 
> 73:         int length = a.length & ~(species.length() - 1);

pre existing test issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14392#issuecomment-1584549575
PR Review Comment: https://git.openjdk.org/jdk/pull/14392#discussion_r1224274145
PR Review Comment: https://git.openjdk.org/jdk/pull/14392#discussion_r1224275043

From chegar at openjdk.org  Fri Jun  9 13:18:07 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 13:18:07 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v2]
In-Reply-To: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
Message-ID: <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>

> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
> 
> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
> 
> This is the only such security manager related issue I see in this code, and I have looked.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  add at bug and remove newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14392/files
  - new: https://git.openjdk.org/jdk/pull/14392/files/1e15af5a..4312aec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14392&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14392&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14392.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14392/head:pull/14392

PR: https://git.openjdk.org/jdk/pull/14392

From adam.sotona at oracle.com  Fri Jun  9 13:23:11 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Fri, 9 Jun 2023 13:23:11 +0000
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v11]
In-Reply-To: <fw7mnM-TCfmyIIRzZ4SUvoj_oqqGYpiYzLU21LEq5mQ=.2a85f959-ec34-4730-bec0-7e29bb9ea737@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WHTBCbzf4cMGOc3QP8KlEGjMB-28ARCJKwpEs1adk50=.bee8e74c-337e-45eb-8023-c052be4c1709@github.com>
 <fw7mnM-TCfmyIIRzZ4SUvoj_oqqGYpiYzLU21LEq5mQ=.2a85f959-ec34-4730-bec0-7e29bb9ea737@github.com>
Message-ID: <CY4PR1001MB2150BA412E3934747E77B62E8C51A@CY4PR1001MB2150.namprd10.prod.outlook.com>



From: kulla-dev <kulla-dev-retn at openjdk.org> on behalf of Brian Goetz <briangoetz at openjdk.org>

>  I think there's something fishy going on.
Yes, transformation lambdas become significantly slower when moved from ClassModel to Classfile (unless I missed anything else).
I?ll do some experiments to get the performance back.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230609/3a925b12/attachment-0001.htm>

From tholenstein at openjdk.org  Fri Jun  9 13:28:22 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Fri, 9 Jun 2023 13:28:22 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v4]
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <JR_9mW0QeTUNeFKG57x4uS2sXwhLoAagriVu-YZoeII=.ed05408d-c9fa-44f6-b7de-2da102111a9a@github.com>

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileCommand=compileonly` with possibility to take lists as ...

Tobias Holenstein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into JDK-8027711
 - Update TestStableUShort.java
 - Update TestStableUByte.java
 - Update TestStableShort.java
 - Update TestStableObject.java
 - Update TestStableLong.java
 - Update TestStableInt.java
 - Update TestStableFloat.java
 - Update TestStableDouble.java
 - Update TestStableChar.java
 - ... and 8 more: https://git.openjdk.org/jdk/compare/c0527561...c9ae4991

-------------

Changes: https://git.openjdk.org/jdk/pull/13802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=03
  Stats: 374 lines in 71 files changed: 29 ins; 69 del; 276 mod
  Patch: https://git.openjdk.org/jdk/pull/13802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13802/head:pull/13802

PR: https://git.openjdk.org/jdk/pull/13802

From chagedorn at openjdk.org  Fri Jun  9 13:28:23 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 9 Jun 2023 13:28:23 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v4]
In-Reply-To: <JR_9mW0QeTUNeFKG57x4uS2sXwhLoAagriVu-YZoeII=.ed05408d-c9fa-44f6-b7de-2da102111a9a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <JR_9mW0QeTUNeFKG57x4uS2sXwhLoAagriVu-YZoeII=.ed05408d-c9fa-44f6-b7de-2da102111a9a@github.com>
Message-ID: <Fe3E1twxKIB5FlLQc8RyeVnCVNQQUFBHaYE-PTQHrj0=.3331f268-33f6-426e-a5c3-7d8ea8171a2f@github.com>

On Fri, 9 Jun 2023 13:24:20 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
>> 
>> ### Old CompileOnly format
>> - matching a **method name** with **class name** and **package name**:
>> `-XX:CompileOnly=package/path/Class.method`
>> `-XX:CompileOnly=package/path/Class::method`
>> `-XX:CompileOnly=package.path.Class::method`
>> BUT NOT `-XX:CompileOnly=package.path.Class.method`
>> 
>> - just matching a **single method name**:
>> `-XX:CompileOnly=.hashCode`
>> `-XX:CompileOnly=::hashCode`
>> BUT NOT `-XX:CompileOnly=hashCode`
>> 
>> - Matching **all method names** in a **class name** with **package name**
>> `-XX:CompileOnly=java/lang/String`
>> BUT NOT `-XX:CompileOnly=java/lang/String.`
>> BUT NOT `-XX:CompileOnly=java.lang.String`
>> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
>> BUT NOT `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - Matching **all method names** in a **class name** with **NO package name**
>> `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
>> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
>> 
>> ### CompileCommand=compileonly format
>> `CompileCommand` allows two different forms for paths: 
>> - `package/path/Class.method`
>> - `package.path.Class::method`
>> 
>> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
>> 
>>  Valid forms: 
>> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
>> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
>> `-XX:CompileCommand=compileonly,java.lang.String::*`
>> `-XX:CompileCommand=compileonly,*::hashCode`
>> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
>> `-XX:CompileCommand=compileonly,*String::hash*`
>> 
>>  Invalid forms (Error: Embedded * not allowed):
>>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
>> 
>> ### Use CompileCommand syntax for CompileOnly
>> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
>> 
>> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
>> 
>> W...
>
> Tobias Holenstein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' into JDK-8027711
>  - Update TestStableUShort.java
>  - Update TestStableUByte.java
>  - Update TestStableShort.java
>  - Update TestStableObject.java
>  - Update TestStableLong.java
>  - Update TestStableInt.java
>  - Update TestStableFloat.java
>  - Update TestStableDouble.java
>  - Update TestStableChar.java
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/c0527561...c9ae4991

Marked as reviewed by chagedorn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1472058579

From duke at openjdk.org  Fri Jun  9 13:36:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 9 Jun 2023 13:36:42 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <oY539hUvQyMNoBNOmfemF2GjDhbueUVe-rzUgMzIrKg=.eec7e413-9745-4935-a038-0e715caa4991@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
 <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
 <oY539hUvQyMNoBNOmfemF2GjDhbueUVe-rzUgMzIrKg=.eec7e413-9745-4935-a038-0e715caa4991@github.com>
Message-ID: <Se00C0z7Hhkw21vg9csBEVZuO_MM4yLrzy8x9bIx6zM=.d0065fd9-d6f8-41d2-af28-6cfca2356370@github.com>

On Fri, 9 Jun 2023 11:53:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decresing the number of iterations proportional to the increase in the max memory size
>
> I'm happy with the changes, but make sure to get a Review from one of the maintainers of this code area. Thanks.

@stefank ?

@AlanBateman Would you want to review this one? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14389#issuecomment-1584585377

From tholenstein at openjdk.org  Fri Jun  9 13:44:20 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Fri, 9 Jun 2023 13:44:20 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v5]
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <EHHiquqPEAXwOmBed95r8Bmy-oKzD8a2HDtbBrMh_A8=.3158217a-4ffc-4115-930a-08eccaa2813b@github.com>

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileCommand=compileonly` with possibility to take lists as ...

Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:

  Update compilerOracle.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13802/files
  - new: https://git.openjdk.org/jdk/pull/13802/files/c9ae4991..c5a7f608

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13802/head:pull/13802

PR: https://git.openjdk.org/jdk/pull/13802

From mcimadamore at openjdk.org  Fri Jun  9 13:44:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 Jun 2023 13:44:58 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>
Message-ID: <xz0oc-eX0_Z3KmIsuXondRBAlI4uigzMo2OE5OpunqQ=.9bcd4a2b-f473-4d54-b977-a5fbddd37321@github.com>

On Thu, 8 Jun 2023 20:21:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> test/jdk/java/foreign/TestLayoutPaths.java line 125:
>> 
>>> 123:     }
>>> 124: 
>>> 125:     public void testByteOffsetHandleRange() {
>> 
>> Missing `@Test`?
>
> FWIW, it looks like this needs `@Test(expectedExceptions = IllegalArgumentException.class)` since range elements are not allowed for `byteOffsetHandle`

Note sure - javadoc says:

* @throws IllegalArgumentException if the layout path is not <a href="#well-formedness">well-formed</a> for this layout.
     * @throws IllegalArgumentException if the layout path contains one or more <a href=#deref-path-elements>dereference path elements</a>.


Which seems correct. The handle version can accept indices, so that's ok?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1224327629

From mcimadamore at openjdk.org  Fri Jun  9 13:44:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 9 Jun 2023 13:44:59 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <xz0oc-eX0_Z3KmIsuXondRBAlI4uigzMo2OE5OpunqQ=.9bcd4a2b-f473-4d54-b977-a5fbddd37321@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>
 <xz0oc-eX0_Z3KmIsuXondRBAlI4uigzMo2OE5OpunqQ=.9bcd4a2b-f473-4d54-b977-a5fbddd37321@github.com>
Message-ID: <DYryHRUnx221CyxFIxROmydIRCUDOr0NQks5Iwttnik=.39a21a8b-1525-420d-84bf-54a674fbcdfb@github.com>

On Fri, 9 Jun 2023 13:40:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> FWIW, it looks like this needs `@Test(expectedExceptions = IllegalArgumentException.class)` since range elements are not allowed for `byteOffsetHandle`
>
> Note sure - javadoc says:
> 
> * @throws IllegalArgumentException if the layout path is not <a href="#well-formedness">well-formed</a> for this layout.
>      * @throws IllegalArgumentException if the layout path contains one or more <a href=#deref-path-elements>dereference path elements</a>.
> 
> 
> Which seems correct. The handle version can accept indices, so that's ok?

Note that the javadoc has been rectified here (as part of the PR) as I think it has always been wrong in the past (probably cut and paste issue from the non-MH version?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1224329494

From mbaesken at openjdk.org  Fri Jun  9 13:45:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Jun 2023 13:45:58 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
Message-ID: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>

On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :

----------System.err:(294/28579)----------
STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)

Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
This is what I find in the manpage of AIX 7.2 or 7.3 :
https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'

Sounds different to what Linux documents in the manpage:
https://man7.org/linux/man-pages/man3/dlopen.3.html
'If the same shared object is opened again with dlopen(), the same object handle is returned.'

We skip this special subtest on AIX .

-------------

Commit messages:
 - JDK-8309549

Changes: https://git.openjdk.org/jdk/pull/14393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14393&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309549
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14393/head:pull/14393

PR: https://git.openjdk.org/jdk/pull/14393

From alanb at openjdk.org  Fri Jun  9 13:56:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 13:56:41 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <jTTgIWtMUapbJUbPefWdFkMQhK2TbYjFZBWdeZ-DDoA=.20c4f71f-453d-4c68-8ec3-44b57180ff61@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

If I read the existing code correctly, ClassCache::get can't return null. If there are two threads racing then it's okay for both to read a non-null strong ref, one read non-null and the other null, or both read null (if someone else cleared it). It just means there may be fallback to the soft ref or if that gets cleared then the remove/re-compute the ClassValue. Maybe more eyes are needed but it could be that this TSAN is reporting a false positive here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1584614945

From alanb at openjdk.org  Fri Jun  9 13:58:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 13:58:42 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <IMkz43uCX0IVcnnbipyCkc2A0FguK0vhNM3x-8kGz7Q=.48d33158-bcc9-4f90-9466-4cc005f86ebe@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

Thanks for taking this one. The spec doesn't require warnings be de-duplicated when the same agent library is loaded more than once, thus skipping this test is okay where it's too complex to detect that the agent library is already loaded.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14393#pullrequestreview-1472159054

From chagedorn at openjdk.org  Fri Jun  9 14:03:44 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 9 Jun 2023 14:03:44 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v5]
In-Reply-To: <EHHiquqPEAXwOmBed95r8Bmy-oKzD8a2HDtbBrMh_A8=.3158217a-4ffc-4115-930a-08eccaa2813b@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <EHHiquqPEAXwOmBed95r8Bmy-oKzD8a2HDtbBrMh_A8=.3158217a-4ffc-4115-930a-08eccaa2813b@github.com>
Message-ID: <b2JyUhEAgzbpWPkkT2Kp8C2PuqzYE4_jXRk7SkWKbuw=.a1f7abcc-c332-4e69-a9dc-dad2133c9288@github.com>

On Fri, 9 Jun 2023 13:44:20 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
>> 
>> ### Old CompileOnly format
>> - matching a **method name** with **class name** and **package name**:
>> `-XX:CompileOnly=package/path/Class.method`
>> `-XX:CompileOnly=package/path/Class::method`
>> `-XX:CompileOnly=package.path.Class::method`
>> BUT NOT `-XX:CompileOnly=package.path.Class.method`
>> 
>> - just matching a **single method name**:
>> `-XX:CompileOnly=.hashCode`
>> `-XX:CompileOnly=::hashCode`
>> BUT NOT `-XX:CompileOnly=hashCode`
>> 
>> - Matching **all method names** in a **class name** with **package name**
>> `-XX:CompileOnly=java/lang/String`
>> BUT NOT `-XX:CompileOnly=java/lang/String.`
>> BUT NOT `-XX:CompileOnly=java.lang.String`
>> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
>> BUT NOT `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - Matching **all method names** in a **class name** with **NO package name**
>> `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
>> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
>> 
>> ### CompileCommand=compileonly format
>> `CompileCommand` allows two different forms for paths: 
>> - `package/path/Class.method`
>> - `package.path.Class::method`
>> 
>> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
>> 
>>  Valid forms: 
>> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
>> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
>> `-XX:CompileCommand=compileonly,java.lang.String::*`
>> `-XX:CompileCommand=compileonly,*::hashCode`
>> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
>> `-XX:CompileCommand=compileonly,*String::hash*`
>> 
>>  Invalid forms (Error: Embedded * not allowed):
>>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
>> 
>> ### Use CompileCommand syntax for CompileOnly
>> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
>> 
>> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
>> 
>> W...
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update compilerOracle.cpp

Marked as reviewed by chagedorn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1472172737

From coffeys at openjdk.org  Fri Jun  9 14:03:50 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 9 Jun 2023 14:03:50 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
Message-ID: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>

New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

-------------

Commit messages:
 - minor edits, copyright, descriptions etc
 - Merge branch 'master' into 8281658-showsettings-security
 - Merge branch 'master' into 8281658-showsettings-security
 - 8281658

Changes: https://git.openjdk.org/jdk/pull/14394/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8281658
  Stats: 195 lines in 4 files changed: 177 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From jpai at openjdk.org  Fri Jun  9 15:06:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 15:06:03 GMT
Subject: RFR: 8308184: Launching java with large number of jars in classpath
 with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError
Message-ID: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@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-8308184?

When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).

`JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.

The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.

The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use the system provided protocol handler.

Do note that this doesn't in any way impact the ability of applications to override the protocol handler for `jar` protocol. Applications can still continue to do it by setting the `java.protocol.handler.pkgs` system property to configure their application specific implementation for the `jar` protocol (or other protocols). `URL` instances created by the application code will continue to use their overridden `jar` protocol handler. The commit in this PR merely fixes the jar protocol handler that is used by the `app` classloader.


A new jtreg test has been added which reproduces this issue and verifies the fix. tier testing is in progress.

-------------

Commit messages:
 - 8308184: Launching java with large number of jars in classpath with java.protocol.handler.pkgs system property set can lead to StackOverflowError

Changes: https://git.openjdk.org/jdk/pull/14395/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308184
  Stats: 148 lines in 3 files changed: 143 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14395/head:pull/14395

PR: https://git.openjdk.org/jdk/pull/14395

From alanb at openjdk.org  Fri Jun  9 15:06:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 15:06:04 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <tsMfq3OznrYyUYujObDJfZm1Tt2x3aZ4-fpdN3kXItQ=.5e875d6a-4e75-402a-851d-53a51529a73e@github.com>

On Fri, 9 Jun 2023 14:55:50 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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 186:

> 184:      * @apiNote Used to create the application class path.
> 185:      */
> 186:     URLClassPath(String cp, URLStreamHandler jarHandler, boolean skipEmptyElements) {

This is a special constructor for the application class path so shouldn't have the jarHandle parameter. This should allow you to drop the changes to ClassLoaders.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224427082

From jpai at openjdk.org  Fri Jun  9 15:23:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 15:23:09 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v2]
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <Tf0Cqb5hMIShkDXwGx_JqXx_ySn4gkOoYcfZ5JZL3rg=.fa58dd66-bc52-4fe4-ba50-bbc959162d97@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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's review suggestion - no need to pass jarHandler as a parameter to the URLClassPath

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14395/files
  - new: https://git.openjdk.org/jdk/pull/14395/files/418dd36d..2fdb5679

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=00-01

  Stats: 15 lines in 2 files changed: 4 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14395/head:pull/14395

PR: https://git.openjdk.org/jdk/pull/14395

From rriggs at openjdk.org  Fri Jun  9 15:43:46 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Jun 2023 15:43:46 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <DPkH1sld0iInqkadzFkPF1nEuOZeJu27v7rY2Ur5Saw=.d051107b-3f41-413a-b408-3302d5c0c019@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 65:

> 63: import java.text.MessageFormat;
> 64: import java.text.Normalizer;
> 65: import java.util.*;

Wild card imports are discouraged. (Your IDE may have done this behind your back)

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 328:

> 326: 
> 327:     private static void printSecuritySettings(String arg) {
> 328:         if (arg.toLowerCase(Locale.ROOT).equals("properties")) {

How about a string switch with "all" and default: being the catchall. It would be easier to add others and avoid multiple calls to `toLowerCase`.
It might be a good idea for unrecognized settings to print a 1-liner reminder of the valid values, including `all`

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 354:

> 352:             }
> 353:         }
> 354:         ostream.print("\n");

or just `ostream.println();`

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 363:

> 361:                     SSLContext.getDefault().getSocketFactory().createSocket();
> 362:         } catch (IOException | NoSuchAlgorithmException e) {
> 363:             throw new RuntimeException(e);

That's pretty rude of the runtime; perhaps `throw InternalError("Unable to create secure socket")`.
It would give some clue that doesn't look like a coding bug.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 376:

> 374:             System.out.println(THREEINDENT + s);
> 375:         }
> 376:         ostream.print("\n");

`ostream.println();`

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 393:

> 391:     }
> 392: 
> 393:     // return a string split across multiple lines which aims to limit max width

This utility method might be usable in more places if the indentation was an argument instead of hard coded.
For example, in `printSecurityProperties`.  It might need to be able to split in more places.

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 171:

> 169: \    -XshowSettings:vm\n\
> 170: \                      show all vm related settings and continue\n\
> 171: \    -XshowSettings:security\n\

`all` should probably be documented.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224440655
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224444089
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224451282
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224456125
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224457654
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224460749
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1224467126

From jpai at openjdk.org  Fri Jun  9 15:47:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 15:47:54 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v3]
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  newline at end of test file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14395/files
  - new: https://git.openjdk.org/jdk/pull/14395/files/2fdb5679..b1260557

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14395/head:pull/14395

PR: https://git.openjdk.org/jdk/pull/14395

From jpai at openjdk.org  Fri Jun  9 15:47:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 9 Jun 2023 15:47:56 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v3]
In-Reply-To: <tsMfq3OznrYyUYujObDJfZm1Tt2x3aZ4-fpdN3kXItQ=.5e875d6a-4e75-402a-851d-53a51529a73e@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <tsMfq3OznrYyUYujObDJfZm1Tt2x3aZ4-fpdN3kXItQ=.5e875d6a-4e75-402a-851d-53a51529a73e@github.com>
Message-ID: <3Lv8BY42EmlwpuzfQSUZvLvZ5M3ZG47h-cQ4nmTgqi8=.71c93fb0-f206-4c97-8b4f-62f3493d5dcd@github.com>

On Fri, 9 Jun 2023 15:01:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   newline at end of test file
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 186:
> 
>> 184:      * @apiNote Used to create the application class path.
>> 185:      */
>> 186:     URLClassPath(String cp, URLStreamHandler jarHandler, boolean skipEmptyElements) {
> 
> This is a special constructor for the application class path so shouldn't have the jarHandle parameter. This should allow you to drop the changes to ClassLoaders.

Thank you Alan for the suggestion. I've updated the PR accordingly. The test continues to pass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224470836

From bpb at openjdk.org  Fri Jun  9 15:51:48 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Jun 2023 15:51:48 GMT
Subject: RFR: 8305947: SequenceInputStream implementation can use an
 Iterator rather than Enumeration
In-Reply-To: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
References: <7vYuNCtcK8vZO7G23klG7qhLiQhE8GWxVJznQ5nRt64=.a252085e-e0b1-4020-96b1-51b9f65095ff@github.com>
Message-ID: <FrSt-VBQqsi0UfENhLyGQNEjTtjtRkcoshYbpcLRLO4=.869a26e1-2032-47b3-abc6-cd5b843100d7@github.com>

On Mon, 19 Dec 2022 11:26:25 GMT, Romain Manni-Bucau <duke at openjdk.org> wrote:

> enumeration(list) will create an enumeration, a list and an iterator whereas the impl only requires an iterator
> this PR drops the enumeration wrapper for binary constructor and just maps the enumeration to an iterator for the other case which should be a better compromise in practise.
> 
> Another side but nice effect is to have some lighter classloading (subgraph)

Please see [I have a patch, what do I do?](https://openjdk.org/guide/#i-have-a-patch-what-do-i-do) and in particular [Socialize your change](https://openjdk.org/guide/#socialize-your-change).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11718#issuecomment-1584798592

From kvn at openjdk.org  Fri Jun  9 16:02:47 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 9 Jun 2023 16:02:47 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v5]
In-Reply-To: <EHHiquqPEAXwOmBed95r8Bmy-oKzD8a2HDtbBrMh_A8=.3158217a-4ffc-4115-930a-08eccaa2813b@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <EHHiquqPEAXwOmBed95r8Bmy-oKzD8a2HDtbBrMh_A8=.3158217a-4ffc-4115-930a-08eccaa2813b@github.com>
Message-ID: <dtuvjwER9n-uDfNgZyVukPJSmAJ34c3Li0TfN3kebqE=.7c79afac-9f8a-4530-a634-8351c35db7ed@github.com>

On Fri, 9 Jun 2023 13:44:20 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
>> 
>> ### Old CompileOnly format
>> - matching a **method name** with **class name** and **package name**:
>> `-XX:CompileOnly=package/path/Class.method`
>> `-XX:CompileOnly=package/path/Class::method`
>> `-XX:CompileOnly=package.path.Class::method`
>> BUT NOT `-XX:CompileOnly=package.path.Class.method`
>> 
>> - just matching a **single method name**:
>> `-XX:CompileOnly=.hashCode`
>> `-XX:CompileOnly=::hashCode`
>> BUT NOT `-XX:CompileOnly=hashCode`
>> 
>> - Matching **all method names** in a **class name** with **package name**
>> `-XX:CompileOnly=java/lang/String`
>> BUT NOT `-XX:CompileOnly=java/lang/String.`
>> BUT NOT `-XX:CompileOnly=java.lang.String`
>> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
>> BUT NOT `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - Matching **all method names** in a **class name** with **NO package name**
>> `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
>> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
>> 
>> ### CompileCommand=compileonly format
>> `CompileCommand` allows two different forms for paths: 
>> - `package/path/Class.method`
>> - `package.path.Class::method`
>> 
>> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
>> 
>>  Valid forms: 
>> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
>> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
>> `-XX:CompileCommand=compileonly,java.lang.String::*`
>> `-XX:CompileCommand=compileonly,*::hashCode`
>> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
>> `-XX:CompileCommand=compileonly,*String::hash*`
>> 
>>  Invalid forms (Error: Embedded * not allowed):
>>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
>> 
>> ### Use CompileCommand syntax for CompileOnly
>> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
>> 
>> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
>> 
>> W...
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update compilerOracle.cpp

GHA testing failed. Please look.

CompileOnly: An error occurred during parsing
Error: Could not parse method pattern
Line: 'TestZeroTripGuardShared'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13802#issuecomment-1584812719

From rriggs at openjdk.org  Fri Jun  9 16:08:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Jun 2023 16:08:48 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v2]
In-Reply-To: <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
 <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
Message-ID: <66BvC-t2duCsvqxJhULDEtj-FBrE1ZIW0Ljfjfo2dRM=.3123f3dd-b5e3-4daf-a6c6-59fcb6c4ff34@github.com>

On Fri, 9 Jun 2023 13:18:07 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
>> 
>> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
>> 
>> This is the only such security manager related issue I see in this code, and I have looked.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add at bug and remove newline

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14392#pullrequestreview-1472530074

From uschindler at openjdk.org  Fri Jun  9 16:18:43 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 9 Jun 2023 16:18:43 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v2]
In-Reply-To: <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
 <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
Message-ID: <9MZDp8BNibFSpsEdQk-KYY53Ic32A6jAYgo_I9LqWYw=.53d2c72c-57d5-425e-9a9a-1f0bda46f608@github.com>

On Fri, 9 Jun 2023 13:18:07 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
>> 
>> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
>> 
>> This is the only such security manager related issue I see in this code, and I have looked.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add at bug and remove newline

Marked as reviewed by uschindler (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14392#pullrequestreview-1472554819

From uschindler at openjdk.org  Fri Jun  9 16:18:45 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 9 Jun 2023 16:18:45 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <c5o8u73sgpm-r0FTK1qy1v2UihyLqCf1rVCNZqFneMc=.8ebdb071-21f0-4f66-8a59-3315ce7e9e5d@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
 <c5o8u73sgpm-r0FTK1qy1v2UihyLqCf1rVCNZqFneMc=.8ebdb071-21f0-4f66-8a59-3315ce7e9e5d@github.com>
Message-ID: <TD4aFJBV2ncLgIq3QXri5x6pV9bF4ARqWBkPZpHvaEw=.112ba423-c64a-4b36-a3b4-ee8d9df44ccf@github.com>

On Fri, 9 Jun 2023 13:07:27 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
>> 
>> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
>> 
>> This is the only such security manager related issue I see in this code, and I have looked.
>
> @PaulSandoz We just ran into this yesterday, https://github.com/elastic/elasticsearch/pull/96715. The change here is trivial.

Thanks @ChrisHegarty for fixing. Lucene's tests didn't find this, unfortunately!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14392#issuecomment-1584832808

From asotona at openjdk.org  Fri Jun  9 16:25:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 9 Jun 2023 16:25:06 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v12]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <nK2l6I95xSA7v8lf3J_sKGQHvgpviCjmcjzz7m8e6Hc=.ea13157b-bfe8-46e8-8065-70c0d2e0fe32@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed StackMapsOption dispatching in DirectCodeBuilder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/ae287751..fd65c367

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=10-11

  Stats: 90 lines in 1 file changed: 50 ins; 16 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From jiangli at openjdk.org  Fri Jun  9 16:26:44 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 9 Jun 2023 16:26:44 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <SD7hzglOVjoSLADlSgMYRPL07fq8z9fDHXausUDgI1k=.61e33381-4b31-4e34-ab26-cfb587499a48@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
 <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>
 <no_IokSpHZ4PQVxLcCE9_RNKPTXsg6F_3mQw207ogDA=.f66b440d-4e72-40ae-ba65-484fe1e6e4ba@github.com>
 <2f--_CXGRLyMkNXfMQe66aDhJ-zPPU7hplrNYRyKDMU=.9797a05f-36dd-4eea-bc12-aecb49749a1e@github.com>
 <SD7hzglOVjoSLADlSgMYRPL07fq8z9fDHXausUDgI1k=.61e33381-4b31-4e34-ab26-cfb587499a48@github.com>
Message-ID: <EpA_MdbQY0exQ6mlojFmKSP90pzphgt6pFPhOixriGM=.af1f27ff-e986-4d58-8bd0-01b429a08d7a@github.com>

On Fri, 2 Jun 2023 14:04:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Sounds good for solving the macosx `ar` limitation differently. I'll change that. We can also exclude the partial linking part for gcc (due the older tool issue that you've found). Any concerns with including partial linking step for clang on Linux?
> 
> I have no concerns regarding clang on Linux.

I've updated this PR to include partial linking for building static libraries with clang on Linux only. On macosx builds, relative path is used when needed for long path and many objects. @erikj79, could you please help run another iteration of your tests to see if there are any remaining missed cases. Hopefully we'll be able to wrap up this change. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1584840824

From alanb at openjdk.org  Fri Jun  9 16:45:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 16:45:45 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v3]
In-Reply-To: <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@github.com>
Message-ID: <gDVqwI2R1pszRWMO4zZpM8o15UNxn51kp6bmX_OLny8=.338055dc-ffa2-4c6f-a2dc-09f56c7f8ffa@github.com>

On Fri, 9 Jun 2023 15:47:54 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-8308184?
>> 
>> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
>> 
>> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
>> 
>> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
>> 
>> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class ...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline at end of test file

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 215:

> 213:         // this URLClassPath constructor is solely for the app classloader, for which we use
> 214:         // the system provided jar protocol handler implementation for loading jars
> 215:         // in the classpath

The apiNote on the constructor makes it clear that the constructor is for the application class path.  Also just to say that the term used in the URL docs is "built-in protocol handler". Combined then it might be clearer if the comment says that the application class loader must use the built-in protocol handler.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 216:

> 214:         // the system provided jar protocol handler implementation for loading jars
> 215:         // in the classpath
> 216:         this.jarHandler = new Handler();

I wouldn't normally suggest dropping an import and using a qualified class name but "Handler" is a very generic class name, replacing it with "new sun.net.www.protocol.jar.Handler()" might be clearer. Another approach would be to move the registry/lookup of the built-in protocol handler from URL to a support class so it could be used in several places but that that might be more trouble that it is worth so what you have is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224523768
PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224527185

From mchung at openjdk.org  Fri Jun  9 16:47:46 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 9 Jun 2023 16:47:46 GMT
Subject: Integrated: 8309303: jdk/internal/misc/VM/RuntimeArguments test
 ignores jdk/internal/vm/options
In-Reply-To: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
References: <h2ptpoS_tdpLQF4AHgZt5--Kgx-AKHeOxD8CaYjhRz8=.f5f6345b-8f0d-4d8b-9c65-b39b00604793@github.com>
Message-ID: <e8r5IYcqnHgP-RHaa992avjixOvqP4Qdt5S6rOS3GE0=.0f5e45a6-00dc-4d1e-ac08-ab271b0bd823@github.com>

On Thu, 8 Jun 2023 18:56:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The `RuntimeArguments` test verifies the VM arguments returned by `jdk.internal.misc.VM::getRuntimeArguments` as expected.    This test fails when running with GraalVM as it was created with `jlink --add-options` and the application will always be launched with that additional set of VM options.  This PR updates the test to read if 'jdk/internal/vm/options` is present and includle those options in the expected list.

This pull request has now been integrated.

Changeset: 679a6d89
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/679a6d89358eb36c596e3ffa9a86869402c9beb9
Stats:     37 lines in 1 file changed: 33 ins; 1 del; 3 mod

8309303: jdk/internal/misc/VM/RuntimeArguments test ignores jdk/internal/vm/options

Reviewed-by: dnsimon, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14383

From alanb at openjdk.org  Fri Jun  9 16:55:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 16:55:46 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
 <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
Message-ID: <pEn4o8BSl7LHk8ksVIT6V1RqPJhOW0TD70_406vuPus=.c9ed5157-7daf-436e-8e1f-e40f1eb7ff6b@github.com>

On Fri, 9 Jun 2023 10:07:31 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> The test used a too-small heap for generic testing, and coupled with looking at `freeMemory()` it led to a less-than-ideal determinism of execution of the test.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decresing the number of iterations proportional to the increase in the max memory size

This looks okay to me and I assume it tested on with all GCs/configurations. If it comes back then maybe an alternative way to test this would be a timed loop of submit+task. If the cancel policy isn't working then it would throw OOME very quickly with a 64Mb heap.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14389#pullrequestreview-1472651211

From aph at openjdk.org  Fri Jun  9 16:59:40 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 9 Jun 2023 16:59:40 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations"
Message-ID: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>

Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.

`BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.

Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

-------------

Commit messages:
 - Move runWith() from VirtualThread to BaseVirtualThread.

Changes: https://git.openjdk.org/jdk/pull/14399/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308609
  Stats: 25 lines in 4 files changed: 14 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From alanb at openjdk.org  Fri Jun  9 17:22:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 17:22:41 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations"
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <OMrMSAx2LWZ6_N1O5YZFLol3vW4s-_thluMzIYWJDbo=.1294b9a1-6daa-45cb-b3b7-58e0896af5ec@github.com>

On Fri, 9 Jun 2023 16:53:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

src/java.base/share/classes/java/lang/BaseVirtualThread.java line 78:

> 76:         op.run();
> 77:         Reference.reachabilityFence(bindings);
> 78:     }

BaseVirtualThread <: Thread.  Would it be simpler, and avoid duplicate, to just change Thread.runWith to be a final method with default access. That would be accessibility to VirtualThread and BoundVirtualThread without duplication.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14399#discussion_r1224563933

From amitkumar at openjdk.org  Fri Jun  9 17:31:42 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 9 Jun 2023 17:31:42 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations"
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <gwynHhY9LtvSCeTTLGbHUcylatdvWC8aXFeE6iHqvT4=.a2f04188-b0b6-4cca-a171-4c88e4c9074e@github.com>

On Fri, 9 Jun 2023 16:53:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Hi Andrew, 

This test failure is no more reproducible on s390x now, would you consider undo-ing problemlisting done by [JDK-8303499](https://bugs.openjdk.org/browse/JDK-8303499), I'll close the parent task [JDK-8303498](https://bugs.openjdk.org/browse/JDK-8303498)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1584919138

From cjplummer at openjdk.org  Fri Jun  9 17:35:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 Jun 2023 17:35:44 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <LUjsslxWWY8dKjsEvkOQxz3tIJp0OeSCfJ1br6vwk2k=.7de8eef7-37ad-4e92-a513-cd89efe9da9b@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14393#pullrequestreview-1472750566

From mchung at openjdk.org  Fri Jun  9 17:48:43 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 9 Jun 2023 17:48:43 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v3]
In-Reply-To: <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@github.com>
Message-ID: <x-1nNDMbWLlKrjB4sUsAgqPM4X6VdxLBpHDifDF1N2k=.29102c07-086d-444c-b9bf-e7762396d839@github.com>

On Fri, 9 Jun 2023 15:47:54 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-8308184?
>> 
>> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
>> 
>> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
>> 
>> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
>> 
>> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class ...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   newline at end of test file

Using the built-in jar protocol handler looks right.   I like Alan's suggestion to use the fully qualified name in the source to make it clearer.

test/jdk/java/net/URL/HandlersPkgPrefix/LargeClasspathWithPkgPrefix.java line 115:

> 113:     // javac -d <destDir> <javaFile>
> 114:     private static void compile(Path javaFile, Path destDir) throws Exception {
> 115:         String javacPath = JDKToolFinder.getJDKTool("javac");

FYI.   `jdk.test.lib.compiler.CompilerUtils` can be used to compile classes in process.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14395#pullrequestreview-1472770525
PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224585461

From rriggs at openjdk.org  Fri Jun  9 17:51:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 9 Jun 2023 17:51:40 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <1naylOEDbJxrbOaBrbqMP3WbUqaVN-G6u9NhHKwEEOQ=.a6a2a357-92d9-42a9-8ed0-fcaf0cf04af8@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

I think the race is benign also but the change maintains the essential semantics.
The use of AtomicRef will have a very slight performance impact.

The semantic is that at-least-one caller gets the reference before it can become "only" soft-referenced and might be reclaimed.

The use of AtomicReference changes the semantic to be exactly-one caller gets the initial hard reference; other callers will be able to get the value from the soft-reference as long as the first caller holds the reference and perhaps beyond depending on memory pressure.

ClassCaches are used by serialization to provide ObjectStreamClass descriptors.
It is quite possible that multiple threads may be serializing the same classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1584941066

From psandoz at openjdk.org  Fri Jun  9 18:15:38 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 9 Jun 2023 18:15:38 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v2]
In-Reply-To: <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
 <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
Message-ID: <MtzeVv9ohskWL-NUo3w7uYZi1aA_61o7e1vza55CGNk=.a69d9338-95f4-4357-aba2-ca4b498325b2@github.com>

On Fri, 9 Jun 2023 13:18:07 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
>> 
>> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
>> 
>> This is the only such security manager related issue I see in this code, and I have looked.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add at bug and remove newline

Marked as reviewed by psandoz (Reviewer).

test/jdk/jdk/incubator/vector/VectorRuns.java line 74:

> 72:             return a.length;
> 73: 
> 74:         int length = a.length & ~(species.length() - 1);

Recommend:
Suggestion:

        int length = species.loopBound(a.length);

-------------

PR Review: https://git.openjdk.org/jdk/pull/14392#pullrequestreview-1472841843
PR Review Comment: https://git.openjdk.org/jdk/pull/14392#discussion_r1224610480

From uschindler at openjdk.org  Fri Jun  9 18:15:39 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 9 Jun 2023 18:15:39 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v2]
In-Reply-To: <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
 <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
Message-ID: <_xG9XyRv1mulnTNk34jk4RMzKNpfDPv4B4md8eYkwmw=.4f4b32f1-26ce-446d-aac6-05a05fd187b7@github.com>

On Fri, 9 Jun 2023 13:18:07 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
>> 
>> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
>> 
>> This is the only such security manager related issue I see in this code, and I have looked.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add at bug and remove newline

Here is our Lucene workaround: https://github.com/apache/lucene/pull/12362

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14392#issuecomment-1584965386

From jvernee at openjdk.org  Fri Jun  9 18:25:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 9 Jun 2023 18:25:29 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <DYryHRUnx221CyxFIxROmydIRCUDOr0NQks5Iwttnik=.39a21a8b-1525-420d-84bf-54a674fbcdfb@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>
 <xz0oc-eX0_Z3KmIsuXondRBAlI4uigzMo2OE5OpunqQ=.9bcd4a2b-f473-4d54-b977-a5fbddd37321@github.com>
 <DYryHRUnx221CyxFIxROmydIRCUDOr0NQks5Iwttnik=.39a21a8b-1525-420d-84bf-54a674fbcdfb@github.com>
Message-ID: <ys6EN4ua3EleWhZOGWgFXMrivoxFGepeWcARYf5ND68=.8c33d02a-37f2-4c55-9d77-b6f016853a57@github.com>

On Fri, 9 Jun 2023 13:42:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Note sure - javadoc says:
>> 
>> * @throws IllegalArgumentException if the layout path is not <a href="#well-formedness">well-formed</a> for this layout.
>>      * @throws IllegalArgumentException if the layout path contains one or more <a href=#deref-path-elements>dereference path elements</a>.
>> 
>> 
>> Which seems correct. The handle version can accept indices, so that's ok?
>
> Note that the javadoc has been rectified here (as part of the PR) as I think it has always been wrong in the past (probably cut and paste issue from the non-MH version?)

But, the implementation of `byteOffsetHandle` rejects range elements: https://github.com/openjdk/jdk/pull/14098/files/265e0d5b082ad54d1cadea1d4a8bd844e72e3926#diff-90ecdacbee63a90f6e695a8bb4c1ad69b591602501613a774561c4032f01fb95R352

So this test fails (at least it does here...)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1224616797

From jvernee at openjdk.org  Fri Jun  9 18:25:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 9 Jun 2023 18:25:30 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <ys6EN4ua3EleWhZOGWgFXMrivoxFGepeWcARYf5ND68=.8c33d02a-37f2-4c55-9d77-b6f016853a57@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>
 <xz0oc-eX0_Z3KmIsuXondRBAlI4uigzMo2OE5OpunqQ=.9bcd4a2b-f473-4d54-b977-a5fbddd37321@github.com>
 <DYryHRUnx221CyxFIxROmydIRCUDOr0NQks5Iwttnik=.39a21a8b-1525-420d-84bf-54a674fbcdfb@github.com>
 <ys6EN4ua3EleWhZOGWgFXMrivoxFGepeWcARYf5ND68=.8c33d02a-37f2-4c55-9d77-b6f016853a57@github.com>
Message-ID: <B5v9SN6F-iSLZxy3l6w7HsMGzCM5Relu4ihnOkVni64=.28872a91-8aba-408c-b627-13b98e0b5bca@github.com>

On Fri, 9 Jun 2023 18:20:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Note that the javadoc has been rectified here (as part of the PR) as I think it has always been wrong in the past (probably cut and paste issue from the non-MH version?)
>
> But, the implementation of `byteOffsetHandle` rejects range elements: https://github.com/openjdk/jdk/pull/14098/files/265e0d5b082ad54d1cadea1d4a8bd844e72e3926#diff-90ecdacbee63a90f6e695a8bb4c1ad69b591602501613a774561c4032f01fb95R352
> 
> So this test fails (at least it does here...)

Though, I agree that it seems fine to support ranges

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1224618487

From mullan at openjdk.org  Fri Jun  9 18:32:08 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 9 Jun 2023 18:32:08 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <QP9p3zbvdFZtzdCG_uIpLpJCgG_lpuXFF_-QLwdzWX0=.7d24d65e-2d4b-42bc-bf92-30d6e245fd49@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Did you consider only showing the security settings if the "security" option is specified? Seems like a lot of data to show in the default case and may not be interesting to many users.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1584984068

From psandoz at openjdk.org  Fri Jun  9 19:02:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 9 Jun 2023 19:02:49 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v11]
In-Reply-To: <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
Message-ID: <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>

On Thu, 8 Jun 2023 01:32:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt  Score   Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> Benchmark                                            Mode  Cnt   Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove meaningless target calls and clear outdated cache as needed

Something was bothering me about the current complexity with method handles and the potential interactions with indirect var handles. Its hard to reason about all the interactions so i needed to take a deeper dive, which i really should have done earlier on. Apologies if we are circling around this many times.

Since we are now leaning on `LazyInitializingVarHandle::target` to initialize I think we can just do this:

    private void initialize() {
        UNSAFE.ensureClassInitialized(refc);
        this.initialized = true;
    }

    @Override
    public MethodHandle toMethodHandle(AccessMode accessMode) {
        if (initialized) {
            return target.toMethodHandle(accessMode);
        } else {
            if (isAccessModeSupported(accessMode)) {
                MethodHandle mh = target.getMethodHandle(accessMode.ordinal());
                // Ensure target on this VH is called to initialize the class
                return mh.bindTo(this);
            }
            else {
                // Ensure an UnsupportedOperationException is thrown
                return MethodHandles.varHandleInvoker(accessMode, accessModeType(accessMode)).
                        bindTo(this);
            }
        }
    }


However, construction of an indirect VH will result in initialization:

    private IndirectVarHandle(VarHandle target, Class<?> value, Class<?>[] coordinates,
                      BiFunction<AccessMode, MethodHandle, MethodHandle> handleFactory, VarForm form, boolean exact) {
        super(form, exact);
        this.handleFactory = handleFactory;
        this.target = target;
        this.directTarget = target.target();
        this.value = value;
        this.coordinates = coordinates;
    }


Since this is not performance sensitive code we could check if target is an instance of `LazyInitializingVarHandle` then conditionally get it's target if initialized e.g.,

   this.target = target instanceof LazyInitializingVarHandle lazyTarget ? lazyTarget.lazyTarget() : target.target();

?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1585012917

From sspitsyn at openjdk.org  Fri Jun  9 19:25:39 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 19:25:39 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <Tqcm_HOK2jRm3LZlJGctO4oyvkygAuz2Yx07fbG2g-M=.1476c101-f5db-4a5f-9b4f-35834c2215ae@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14393#pullrequestreview-1472948256

From chegar at openjdk.org  Fri Jun  9 19:31:10 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 19:31:10 GMT
Subject: Integrated: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
Message-ID: <NDvv9wfMDJbAXCntbtEPX53XBsvVbSk54SVMFRogADo=.4e09baf6-2a66-4502-9f9c-41128fb582a6@github.com>

On Fri, 9 Jun 2023 13:02:18 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
> 
> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
> 
> This is the only such security manager related issue I see in this code, and I have looked.

This pull request has now been integrated.

Changeset: cee5724d
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d
Stats:     10 lines in 3 files changed: 7 ins; 0 del; 3 mod

8309727: Assert privileges while reading the jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property

Reviewed-by: rriggs, uschindler, psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/14392

From chegar at openjdk.org  Fri Jun  9 19:31:08 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 19:31:08 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v2]
In-Reply-To: <MtzeVv9ohskWL-NUo3w7uYZi1aA_61o7e1vza55CGNk=.a69d9338-95f4-4357-aba2-ca4b498325b2@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
 <9PlxtV86NcyNY1YRDeZ0UmXpdQo8Hgb28AsfMZBHbFI=.01701f58-fa7f-47f4-b72d-1b7c766cceea@github.com>
 <MtzeVv9ohskWL-NUo3w7uYZi1aA_61o7e1vza55CGNk=.a69d9338-95f4-4357-aba2-ca4b498325b2@github.com>
Message-ID: <2iunK7WllC4DfYlvzffEdSYotgyaPalSNnJ464_-Pks=.2de31639-ec27-40a3-ac50-8239e3e4874a@github.com>

On Fri, 9 Jun 2023 18:12:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add at bug and remove newline
>
> test/jdk/jdk/incubator/vector/VectorRuns.java line 74:
> 
>> 72:             return a.length;
>> 73: 
>> 74:         int length = a.length & ~(species.length() - 1);
> 
> Recommend:
> Suggestion:
> 
>         int length = species.loopBound(a.length);

Done, [5a4be97](https://github.com/openjdk/jdk/pull/14392/commits/5a4be97faa822a612dbb9d86cf9b6cf4d88483da)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14392#discussion_r1224679125

From chegar at openjdk.org  Fri Jun  9 19:31:06 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 19:31:06 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property [v3]
In-Reply-To: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
References: <RCUbYX59iB3ZG_68id4qccqsd9ktJeKvEcfR8TWHFgE=.bcb1e28b-7c02-47cd-8d61-e8d32b7dd23d@github.com>
Message-ID: <6rfN8_ksvEw7uDAEeuGi2N8gilVlmK7omBBEahLqiFU=.384062f0-c870-4eec-a06d-32989f25427f@github.com>

> A trivial use of the Vector API when run with the security manager and a domain that does not grant permissions fails with java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK" "read").
> 
> The fix it minimal, as consistent with other system property access in the JDK - just access the property while asserting privileged. Note: no explicit permission grant to the vector module is required, as it is in the boot loader.
> 
> This is the only such security manager related issue I see in this code, and I have looked.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  use loopBound

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14392/files
  - new: https://git.openjdk.org/jdk/pull/14392/files/4312aec1..5a4be97f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14392&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14392&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14392.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14392/head:pull/14392

PR: https://git.openjdk.org/jdk/pull/14392

From chegar at openjdk.org  Fri Jun  9 19:53:59 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Fri, 9 Jun 2023 19:53:59 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
Message-ID: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>

Hi all,

This pull request contains a backport of commit [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.

Thanks!

-------------

Commit messages:
 - Backport cee5724d09b9ef9bd528fb721b756cb052265e3d

Changes: https://git.openjdk.org/jdk21/pull/3/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=3&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309727
  Stats: 10 lines in 3 files changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk21/pull/3.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/3/head:pull/3

PR: https://git.openjdk.org/jdk21/pull/3

From erikj at openjdk.org  Fri Jun  9 20:05:43 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Jun 2023 20:05:43 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>
Message-ID: <H1ApGrPYxiyYdMeudIna-IWn5vammTSrSVpy26Soesk=.8f5000df-7e3c-4591-842a-ad8e5787c025@github.com>

On Thu, 8 Jun 2023 20:34:15 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou 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 branch 'master' into JDK-8307858
>  - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
>  - Merge branch 'master' into JDK-8307858
>  - Address comments/suggestions from @erikj79:
>    - Only do partial linking step for building static libraries with clang on linux.
>    - On macosx, workaround the long argument issue for 'AR' with relative path.
>    
>    Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
>  - Update make/common/NativeCompilation.gmk
>    
>    Thanks you!
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
>  - Update make/common/NativeCompilation.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8307858
>  - Merge branch 'master' into JDK-8307858
>  - Clean up.
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/c4e65425...c664c601

All our builds succeeded, so this is looking pretty good now. Just a minor suggestion left.

make/common/NativeCompilation.gmk line 1186:

> 1184:     # Include partial linking when building the static library with clang on linux.
> 1185:     ifeq ($(call isTargetOs, linux), true)
> 1186:       ifneq ($(findstring $(TOOLCHAIN_TYPE), clang), )

This combination of conditions is repeated 3 times. Maybe we could assign the result to a variable (e.g. `$1_ENABLE_PARTIAL_LINKING`) and check for that instead?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1472988455
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1224714975

From manc at openjdk.org  Fri Jun  9 23:02:58 2023
From: manc at openjdk.org (Man Cao)
Date: Fri, 9 Jun 2023 23:02:58 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <eZvdmO-4xQgDj0iVAc3vzYheOSAztLrxB7SCBjHGY_o=.d39ccc51-a4d9-4551-889f-aea84f74ac68@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Agree with the analysis that this race looks benign, and the slight change in semantics is OK. It is still a true data race and TSAN is NOT reporting a false positive though.

In our experience, the best practice is to avoid all data races unless there's a strong reason that fixing the race has undesirable effect (e.g. noticeable performance penalty). A benign race could become problematic in the future with unsuspecting changes to this file, and has higher maintenance cost in general.

I hope we can actually fix this data race. If we decide not to, at least add a comment about this intentionally benign data race.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1585216278

From uschindler at openjdk.org  Fri Jun  9 23:02:59 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 9 Jun 2023 23:02:59 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
References: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
Message-ID: <bsfHGUBl8i3rDFMHvU7H-vY1GgObxaCq-s76CMMWySo=.d8064018-1992-40db-92c4-376e4d9fbc9e@github.com>

On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.
> 
> Thanks!

Marked as reviewed by uschindler (Author).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/3#pullrequestreview-1473013982

From jiangli at openjdk.org  Fri Jun  9 23:04:33 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 9 Jun 2023 23:04:33 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v8]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <uvcmm38GNLtRtiwla8ziUGR3SRwPFdrkeOIeC5gjGC0=.3819e441-9348-4fec-9bea-4c32432d8e48@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into JDK-8307858
 - - Use $1_ENABLE_PARTIAL_LINKING for checking if partial linking should be enabled, as suggested by @erikj79.
 - Merge branch 'master' into JDK-8307858
 - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Merge branch 'master' into JDK-8307858
 - ... and 11 more: https://git.openjdk.org/jdk/compare/beec734f...28585b84

-------------

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=07
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From jiangli at openjdk.org  Fri Jun  9 23:04:33 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 9 Jun 2023 23:04:33 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <H1ApGrPYxiyYdMeudIna-IWn5vammTSrSVpy26Soesk=.8f5000df-7e3c-4591-842a-ad8e5787c025@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <4RwP9DFW7ZseAU9J5qUI_Azy6oqSxY8R3NYShKYS4uQ=.09d65652-2443-4067-ac21-cc0a1f917148@github.com>
 <H1ApGrPYxiyYdMeudIna-IWn5vammTSrSVpy26Soesk=.8f5000df-7e3c-4591-842a-ad8e5787c025@github.com>
Message-ID: <4UxQ6tu2JPttQxkKLhi-TFLR7M46F0CgeXt4QZzWNN0=.b7620fe4-725c-41c9-a0fa-1a90b8013769@github.com>

On Fri, 9 Jun 2023 20:03:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> All our builds succeeded, so this is looking pretty good now. Just a minor suggestion left.

Thanks a lot!

> This combination of conditions is repeated 3 times. Maybe we could assign the result to a variable (e.g. `$1_ENABLE_PARTIAL_LINKING`) and check for that instead?

Done, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1585213568
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1224866324

From bchristi at openjdk.org  Fri Jun  9 23:29:56 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 9 Jun 2023 23:29:56 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner
 [v16]
In-Reply-To: <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <eFt6SCXR1oCUa1Q2D7g8KIbx-_UsXJa5zU4xMvIjF8E=.e69adc7f-f489-4d77-917d-dfb4a0f73f27@github.com>
Message-ID: <JIAYJF3odLTpqQXt31oAXNFP2ufjRzwL912_FHsm168=.c412e6eb-dd47-42a6-949b-4a661450dc2c@github.com>

On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove some more tabs

Let's hang on to this for a bit longer

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8311#issuecomment-1585244767

From naoto at openjdk.org  Fri Jun  9 23:34:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 Jun 2023 23:34:44 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
Message-ID: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>

This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:

(w/o fix)

Benchmark                       Mode  Cnt      Score     Error  Units
LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op

(w/ fix)
Benchmark                       Mode  Cnt      Score     Error  Units
LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

-------------

Commit messages:
 - minor comment fix
 - equals/hash fix, constructor simplification
 - Removed Key
 - minor fixup
 - Use WeakHashMap
 - Modified JMH test
 - Added a test variation for the issue
 - added microbenchmark
 - 8309622: Re-examine the cache mechanism in BaseLocale

Changes: https://git.openjdk.org/jdk/pull/14404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309622
  Stats: 244 lines in 3 files changed: 104 ins; 117 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From erikj at openjdk.org  Fri Jun  9 23:43:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 9 Jun 2023 23:43:44 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v8]
In-Reply-To: <uvcmm38GNLtRtiwla8ziUGR3SRwPFdrkeOIeC5gjGC0=.3819e441-9348-4fec-9bea-4c32432d8e48@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <uvcmm38GNLtRtiwla8ziUGR3SRwPFdrkeOIeC5gjGC0=.3819e441-9348-4fec-9bea-4c32432d8e48@github.com>
Message-ID: <vhiSPrvXKhH5j32Bnb0zz0GR0FNy2v6dO9smZI0JsMU=.65bb7de3-eaa3-4b48-8181-7ad604b5228f@github.com>

On Fri, 9 Jun 2023 23:04:33 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'master' into JDK-8307858
>  - - Use $1_ENABLE_PARTIAL_LINKING for checking if partial linking should be enabled, as suggested by @erikj79.
>  - Merge branch 'master' into JDK-8307858
>  - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
>  - Merge branch 'master' into JDK-8307858
>  - Address comments/suggestions from @erikj79:
>    - Only do partial linking step for building static libraries with clang on linux.
>    - On macosx, workaround the long argument issue for 'AR' with relative path.
>    
>    Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
>  - Update make/common/NativeCompilation.gmk
>    
>    Thanks you!
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
>  - Update make/common/NativeCompilation.gmk
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8307858
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/beec734f...28585b84

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1473186956

From duke at openjdk.org  Fri Jun  9 23:51:51 2023
From: duke at openjdk.org (duke)
Date: Fri, 9 Jun 2023 23:51:51 GMT
Subject: Withdrawn: 8303920: Avoid calling out to python in
 DataDescriptorSignatureMissing test
In-Reply-To: <O8QlaVgZodtXVtw_1IaBp7BdNr-WRHLfWKrpTULRyko=.f7f2c640-3205-43a0-ac74-2e96834715c6@github.com>
References: <O8QlaVgZodtXVtw_1IaBp7BdNr-WRHLfWKrpTULRyko=.f7f2c640-3205-43a0-ac74-2e96834715c6@github.com>
Message-ID: <EPcTgybwCrbEtRp_sz82oTEXyLMoIa2xWtIrd9YFyuI=.7fb8d0b7-0181-4763-a6ca-29c147c6435a@github.com>

On Thu, 9 Mar 2023 19:53:44 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which brings  the DataDescriptorSignatureMissing test back to life.
> 
> This test currently calls out to Python to create a test vector ZIP with a Data Descriptor without the recommended but optional signature. The Python dependency has turned out to be very brittle, so the test is currently marked with `@ignore` 
> 
> The PR replaces Python callouts with directly creating the test vector ZIP in the test itself. We can then remove the `@ignore`tag and run this useful test automatically.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12959

From jpai at openjdk.org  Sat Jun 10 01:21:39 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 01:21:39 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v4]
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <2F1C0gU9OvBMqrVj7LzO2aqZA-aLXRakqvIxAb-9iJs=.c8581831-5e74-46f9-8142-f68b82350bd4@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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - minor comment adjustment on test method
 - Mandy's suggestion - use CompilerUtils for in-process compilation
 - minor code comment change and use fully qualified classname at call site

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14395/files
  - new: https://git.openjdk.org/jdk/pull/14395/files/b1260557..39d7ea28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=02-03

  Stats: 18 lines in 2 files changed: 2 ins; 6 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14395/head:pull/14395

PR: https://git.openjdk.org/jdk/pull/14395

From jpai at openjdk.org  Sat Jun 10 01:21:42 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 01:21:42 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v3]
In-Reply-To: <gDVqwI2R1pszRWMO4zZpM8o15UNxn51kp6bmX_OLny8=.338055dc-ffa2-4c6f-a2dc-09f56c7f8ffa@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@github.com>
 <gDVqwI2R1pszRWMO4zZpM8o15UNxn51kp6bmX_OLny8=.338055dc-ffa2-4c6f-a2dc-09f56c7f8ffa@github.com>
Message-ID: <GSbuBsOTwRYznY-RHQFSC3gTK2JdZBq8iiHcBWaoWpM=.17013adf-0d34-46e4-bbc8-7e0318559a1d@github.com>

On Fri, 9 Jun 2023 16:42:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wouldn't normally suggest dropping an import and using a qualified class name but "Handler" is a very generic class name, replacing it with "new sun.net.www.protocol.jar.Handler()" might be clearer.

I agree. I have now updated the PR to use the fully qualified name at the call site and also adjusted the code comment as recommended.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224950954

From jpai at openjdk.org  Sat Jun 10 01:21:44 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 01:21:44 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v3]
In-Reply-To: <x-1nNDMbWLlKrjB4sUsAgqPM4X6VdxLBpHDifDF1N2k=.29102c07-086d-444c-b9bf-e7762396d839@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <E_rq84EXiTmYQ542EPh2wThyLeGTAGpD2QnFvpHM6-8=.7b4f1b2f-414f-4940-bf80-680077ea7fc1@github.com>
 <x-1nNDMbWLlKrjB4sUsAgqPM4X6VdxLBpHDifDF1N2k=.29102c07-086d-444c-b9bf-e7762396d839@github.com>
Message-ID: <7ni-A5R5dQ_mN49wgVhKR6Bv25NI7z-pwFIYxlhXm4M=.13e6c838-80da-4def-80ca-3e65f8e26228@github.com>

On Fri, 9 Jun 2023 17:40:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   newline at end of test file
>
> test/jdk/java/net/URL/HandlersPkgPrefix/LargeClasspathWithPkgPrefix.java line 115:
> 
>> 113:     // javac -d <destDir> <javaFile>
>> 114:     private static void compile(Path javaFile, Path destDir) throws Exception {
>> 115:         String javacPath = JDKToolFinder.getJDKTool("javac");
> 
> FYI.   `jdk.test.lib.compiler.CompilerUtils` can be used to compile classes in process.

Thank you Mandy, this is useful, I wasn't aware of this one. I have now updated the test to use this utility class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1224951220

From jpai at openjdk.org  Sat Jun 10 05:16:28 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 05:16:28 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v5]
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <1ErvU2_EMZH071GN6vX_ipZCB1EGegBMDOD-f_Mq6qg=.394e9487-934d-406c-9240-aa0c53c38846@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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  minor update to the test to allow tracking the time taken to create the jars for debug purpose

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14395/files
  - new: https://git.openjdk.org/jdk/pull/14395/files/39d7ea28..362ef5ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=03-04

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14395/head:pull/14395

PR: https://git.openjdk.org/jdk/pull/14395

From alanb at openjdk.org  Sat Jun 10 06:21:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Jun 2023 06:21:43 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v5]
In-Reply-To: <1ErvU2_EMZH071GN6vX_ipZCB1EGegBMDOD-f_Mq6qg=.394e9487-934d-406c-9240-aa0c53c38846@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <1ErvU2_EMZH071GN6vX_ipZCB1EGegBMDOD-f_Mq6qg=.394e9487-934d-406c-9240-aa0c53c38846@github.com>
Message-ID: <blD7ck-zxaQY4nsEggAZKNhSndmLZOU8PpuFjN4RJwQ=.302bbab0-0174-4347-bbcb-cd9f98c5672b@github.com>

On Sat, 10 Jun 2023 05:16:28 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-8308184?
>> 
>> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
>> 
>> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
>> 
>> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
>> 
>> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class ...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor update to the test to allow tracking the time taken to create the jars for debug purpose

Thanks for taking this one. My guess is that this issue goes back 20+ but not noticed because it's running with the system property to specify another location for protocol handlers is probably rare, and it seems a scanning of a large large class path to trigger it.

I assume you'll see the comment about moving the test to be with the other tests for URLClassPath.

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 212:

> 210:         // the application class loader uses the built-in protocol handler to avoid protocol
> 211:         // handler lookup when opening JAR files on the class path.
> 212:         this.jarHandler = new sun.net.www.protocol.jar.Handler();

Good, this looks much better.

test/jdk/java/net/URL/HandlersPkgPrefix/LargeClasspathWithPkgPrefix.java line 44:

> 42:  * @run driver LargeClasspathWithPkgPrefix
> 43:  */
> 44: public class LargeClasspathWithPkgPrefix {

test/jdk/java/net/URL/HandlersPkgPrefix is an unusual location for the test, maybe it could move to test/jdk/sun/misc/URLClassPath so it's the same location as the other tests for URLClassPath. Separately (not suggesting it for this PR) is that test directory should probably be renamed to jdk/internal/loader as the URLClassPath moved in JDK 9.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14395#pullrequestreview-1473325189
PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1225140617
PR Review Comment: https://git.openjdk.org/jdk/pull/14395#discussion_r1225140504

From jpai at openjdk.org  Sat Jun 10 06:44:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 06:44:56 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v6]
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  move the test to test/jdk/sun/misc/URLClassPath directory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14395/files
  - new: https://git.openjdk.org/jdk/pull/14395/files/362ef5ce..5a57fe8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14395&range=04-05

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14395/head:pull/14395

PR: https://git.openjdk.org/jdk/pull/14395

From dnsimon at openjdk.org  Sat Jun 10 06:59:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 10 Jun 2023 06:59:49 GMT
Subject: Withdrawn: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <lbkzRlaq4YnkRfNZLrf4vGMs1dgvWpTNs_Xzg_ZZM6s=.0b4690a6-60d5-4c73-9601-733061a4024e@github.com>

On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real  ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14291

From alanb at openjdk.org  Sat Jun 10 07:18:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Jun 2023 07:18:39 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <8YVrR0xPCqo7X1OykjWSWKmNFTXtrd0kk42zjJvsRrM=.a33af31b-8543-4522-82a7-ddc44029f616@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

There is a lot of output and does seem to overwhelm the java -XshowSettings output with detail that I wouldn't expect by default.  It's effectively printing conf/java.security and enumerating all the capabilities of the providers and cipher suites. So I think I agree with Sean's suggestion to require the :security sub-option for the detail. We could potentially do this for the available locales too. The -XshowSettings output could include a message at the end about using -XshowSettings:detailed or some such sub-option for more detailed output.

In passing, it looks like some of the output is going to stderr, some to stdout, so you might want to check that. Also StringTokenizer is legacy, I don't think we want that in the java launcher code, it looks like it just needs String.split.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1585530294

From aph at openjdk.org  Sat Jun 10 09:06:40 2023
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 10 Jun 2023 09:06:40 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations"
In-Reply-To: <OMrMSAx2LWZ6_N1O5YZFLol3vW4s-_thluMzIYWJDbo=.1294b9a1-6daa-45cb-b3b7-58e0896af5ec@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <OMrMSAx2LWZ6_N1O5YZFLol3vW4s-_thluMzIYWJDbo=.1294b9a1-6daa-45cb-b3b7-58e0896af5ec@github.com>
Message-ID: <f9hRgXslaVKecUx3iAWoTbJfParg_6F0w1WWNiGZOvA=.625a3e34-f0e0-41b9-b1fc-c9fc69c99aad@github.com>

On Fri, 9 Jun 2023 17:19:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
>> 
>> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
>> 
>> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.
>
> src/java.base/share/classes/java/lang/BaseVirtualThread.java line 78:
> 
>> 76:         op.run();
>> 77:         Reference.reachabilityFence(bindings);
>> 78:     }
> 
> BaseVirtualThread <: Thread.  Would it be simpler, and avoid duplicate code, to just change Thread.runWith to be a final method with default access. That would be accessible to VirtualThread and BoundVirtualThread without needing to override runWith.

Sure, that makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14399#discussion_r1225234193

From daniel at wwwmaster.at  Sat Jun 10 12:10:46 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Sat, 10 Jun 2023 14:10:46 +0200
Subject: Adapt ArrayList Javadoc for sequenced collections
In-Reply-To: <cb0f6d03-ce36-44d9-fc50-8e4b352731f1@wwwmaster.at>
References: <cb0f6d03-ce36-44d9-fc50-8e4b352731f1@wwwmaster.at>
Message-ID: <9bcb8f8e-ac95-1403-c64a-1b7371835152@wwwmaster.at>

Dear members of the core-libs-dev mailing list,

The JEP for sequenced collection (https://openjdk.org/jeps/431) would 
add addFirst(), removeFirst() and reversed() methods to lists.
However, the Javadoc of List mentions:
 > The size, isEmpty, get, set, iterator, and listIterator operations 
run in constant time. The add operation runs in amortized constant time, 
that is, adding n elements requires O(n) time. All of the other 
operations run in linear time (roughly speaking). The constant factor is 
low compared to that for the LinkedList implementation.

This is (at the time of writing) still the case for the jdk21-fork 
(https://github.com/openjdk/jdk21/blob/430ffe7ae691d097de2818391531522f2538431d/src/java.base/share/classes/java/util/ArrayList.java#L42-L47).

I think this should be updated to include that reversed() runs in 
constant time while addFirst() and removeFirst() run in linear time.

Yours,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230610/cb9dcda7/smime-0001.p7s>

From tholenstein at openjdk.org  Sat Jun 10 12:25:57 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Sat, 10 Jun 2023 12:25:57 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v6]
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <ERPIRYWlmzrLw8dhG9Ggyp_u7SusdwhGc5DUh7yLMpE=.b6990f67-6395-4c2e-868a-1064e1334e4f@github.com>

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileCommand=compileonly` with possibility to take lists as ...

Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:

  update new Tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13802/files
  - new: https://git.openjdk.org/jdk/pull/13802/files/c5a7f608..799b10ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13802/head:pull/13802

PR: https://git.openjdk.org/jdk/pull/13802

From jpai at openjdk.org  Sat Jun 10 13:45:43 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 13:45:43 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v6]
In-Reply-To: <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
Message-ID: <f9oiAcGTSiR-QlbnC7FwH4EPCTUxbR1oIIompSv4ANY=.fa59e3c5-4395-426c-bf83-48d96aa9c66d@github.com>

On Sat, 10 Jun 2023 06:44:56 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-8308184?
>> 
>> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
>> 
>> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
>> 
>> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
>> 
>> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class ...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test to test/jdk/sun/misc/URLClassPath directory

Hello Alan,

> Thanks for taking this one. My guess is that this issue goes back 20+ years but not noticed because it's running with the system property to specify another location for protocol handlers is probably rare, and it seems a scanning of a large large class path to trigger it.

When I started looking into this issue, I was curious why this wasn't reported in Java 8 since the reporter was merely switching Java version from 8 to a newer version. When I look into Java 8 code, I see that the `sun.misc.Launcher` in Java 8 specifically deals with this case by using the built-in protocol handler and uses the bootstrap classloader for loading that hander, while launching the application's main class:
https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/sun/misc/Launcher.java#L53
https://github.com/openjdk/jdk8u-dev/blob/master/jdk/src/share/classes/sun/misc/Launcher.java#L512

I think that explains why it isn't seen in that version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14395#issuecomment-1585669219

From jpai at openjdk.org  Sat Jun 10 13:45:45 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 10 Jun 2023 13:45:45 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v5]
In-Reply-To: <blD7ck-zxaQY4nsEggAZKNhSndmLZOU8PpuFjN4RJwQ=.302bbab0-0174-4347-bbcb-cd9f98c5672b@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <1ErvU2_EMZH071GN6vX_ipZCB1EGegBMDOD-f_Mq6qg=.394e9487-934d-406c-9240-aa0c53c38846@github.com>
 <blD7ck-zxaQY4nsEggAZKNhSndmLZOU8PpuFjN4RJwQ=.302bbab0-0174-4347-bbcb-cd9f98c5672b@github.com>
Message-ID: <3vgCaO9kdHXB7Z1pYpz4Kg8jnSBAm9Pjfn_HhU56KrA=.08ea249e-2056-49f3-9460-07200518b40f@github.com>

On Sat, 10 Jun 2023 06:18:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you'll see the comment about moving the test to be with the other tests for URLClassPath.

I have updated the PR to change the location of this new test class. Additionally I've filed https://bugs.openjdk.org/browse/JDK-8309763 to move the `sun/misc/URLClassPath` tests to `jdk/internal/loader` directory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14395#issuecomment-1585669931

From weijun at openjdk.org  Sat Jun 10 14:44:42 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 10 Jun 2023 14:44:42 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <uTVVj7JJwgb_N7zrRHeuIZhKbsc6AdNisFhhdDUNmis=.1bb2cdc3-d00f-4344-a983-e2bbfb0632e0@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 349:

> 347:                 // split lines longer than 60 chars which have multiple values
> 348:                 ostream.println(TWOINDENT + key + "=");
> 349:                 List.of(val.split(",")).forEach(s -> ostream.println(THREEINDENT + s.trim()));

You should probably add back `,` when printing them out.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 381:

> 379:     private static void printSecurityProviderConfig() {
> 380:         ostream.println(INDENT + "Security provider static configuration:");
> 381:         for (Provider p : Security.getProviders()) {

Maybe add an empty line or something like `-----` between providers?

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 385:

> 383:             ostream.println(TWOINDENT + "Provider information: " + wrappedString(p.getInfo(), 80));
> 384:             ostream.println(TWOINDENT + "Provider services: (type : algorithm)");
> 385:             for (Provider.Service ps : p.getServices().stream()

If this stream is empty, should you print out something like "none"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1225400656
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1225401386
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1225401803

From alanb at openjdk.org  Sat Jun 10 18:52:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Jun 2023 18:52:40 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations"
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <E9PF7F5wCq17fqJECQLEIoFR3NVclGrlgcYgoRRMoyQ=.16da8684-d2d4-4cab-9496-371cdbb4347f@github.com>

On Fri, 9 Jun 2023 16:53:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

One suggestion for the test is to have it re-run with -XX:-VMContinuations on platforms/ports that do do have VM continuations support. Some of the tests for virtual threads do the same thing to ensure this operating mode is tested. This should do it:


--- a/test/jdk/java/lang/ScopedValue/StressStackOverflow.java
+++ b/test/jdk/java/lang/ScopedValue/StressStackOverflow.java
@@ -21,8 +21,8 @@
  * questions.
  */
 
-/**
- * @test
+/*
+ * @test id=default
  * @summary StressStackOverflow the recovery path for ScopedValue
  * @enablePreview
  * @run main/othervm/timeout=300 -XX:-TieredCompilation StressStackOverflow
@@ -30,6 +30,13 @@
  * @run main/othervm/timeout=300 StressStackOverflow
  */
 
+/*
+ * @test id=no-vmcontinuations
+ * @requires vm.continuations
+ * @enablePreview
+ * @run main/othervm/timeout=300 -XX:+UnlockExperimentalVMOptions -XX:-VMContinuations StressStackOverflow
+ */
+

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1585769878

From alanb at openjdk.org  Sat Jun 10 19:01:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Jun 2023 19:01:58 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v6]
In-Reply-To: <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
Message-ID: <fLz4TkTlaG-jxFj4WzF8Fjpzj8_60j6qLOXZUImlsYk=.676d5bde-8c08-4e38-b115-a67612fef085@github.com>

On Sat, 10 Jun 2023 06:44:56 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-8308184?
>> 
>> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
>> 
>> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
>> 
>> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
>> 
>> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class ...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test to test/jdk/sun/misc/URLClassPath directory

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14395#pullrequestreview-1473475851

From alanb at openjdk.org  Sat Jun 10 19:02:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 10 Jun 2023 19:02:00 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v6]
In-Reply-To: <f9oiAcGTSiR-QlbnC7FwH4EPCTUxbR1oIIompSv4ANY=.fa59e3c5-4395-426c-bf83-48d96aa9c66d@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
 <f9oiAcGTSiR-QlbnC7FwH4EPCTUxbR1oIIompSv4ANY=.fa59e3c5-4395-426c-bf83-48d96aa9c66d@github.com>
Message-ID: <HoNKqMAnzTeETWzC0ZonnheP3zUTGsmbM-5WOX2EvdM=.e929ab2a-3e6a-44be-a428-81d0d2816ed5@github.com>

On Sat, 10 Jun 2023 13:40:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> When I started looking into this issue, I was curious why this wasn't reported in Java 8 since the reporter was merely switching Java version from 8 to a newer version. When I look into Java 8 code, I see that the `sun.misc.Launcher` in Java 8 specifically deals with this case by using the built-in protocol handler

Thanks for the digging into that, I was curious why this hasn't come up before now. I suppose part of it is that it's rare to run with this system property to override or add URL protocol handlers. There are a number of JDK 1.0/1.1 era APIs that used this approach for pluggability. In time it may be possible to deprecate this mechanism, newer code use services and URLStreamHandlerProvider.

Anyway, it's good that you've tracked this down, thanks for spending time on it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14395#issuecomment-1585771873

From duke at openjdk.org  Sat Jun 10 21:12:00 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 10 Jun 2023 21:12:00 GMT
Subject: Withdrawn: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
References: <p1U1_TXgS27HyrZW6Z4n1OaaaHtPCNkKeqG-vpnI2Dk=.89a94f4f-7b77-4e1c-9375-e6a782ed5e61@github.com>
Message-ID: <MpQzFco9lG8ymMcpe3NYcCj1_YLR-f_UPiWlVt4r_Bg=.5ad8f206-4677-4843-ab71-c3d3bec7cb0c@github.com>

On Thu, 13 Oct 2022 21:15:16 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10704

From duke at openjdk.org  Sun Jun 11 11:40:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Sun, 11 Jun 2023 11:40:55 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <pEn4o8BSl7LHk8ksVIT6V1RqPJhOW0TD70_406vuPus=.c9ed5157-7daf-436e-8e1f-e40f1eb7ff6b@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
 <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
 <pEn4o8BSl7LHk8ksVIT6V1RqPJhOW0TD70_406vuPus=.c9ed5157-7daf-436e-8e1f-e40f1eb7ff6b@github.com>
Message-ID: <7EVAcKdPYCtuJtEe-9Otekap-AevzPpDcgw4NHd-PM8=.c4792be2-12b5-4977-b1ad-09b90f9be4b7@github.com>

On Fri, 9 Jun 2023 16:53:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decresing the number of iterations proportional to the increase in the max memory size
>
> This looks okay to me and I assume it tested on with all GCs/configurations. If it comes back then maybe an alternative way to test this would be a timed loop of submit+task. If the cancel policy isn't working then it would throw OOME very quickly with a 64Mb heap.

@AlanBateman Yes, i've run it extensively. I decided against running it in a timed loop because that would technically make it succeed if the application thread didn't get enough CPU-time. (And makes it difficult to know how it behaves on very slow machines)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14389#issuecomment-1586129041

From chegar at openjdk.org  Sun Jun 11 13:46:54 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Sun, 11 Jun 2023 13:46:54 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
References: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
Message-ID: <1QLuxv-yKjBN5UB6cUUkBnPoDBEBFNEC1ayqZtkb1YU=.e944a31a-c459-44b6-8566-c6f884adaafc@github.com>

On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.
> 
> Thanks!

@RogerRiggs @PaulSandoz this is a clean backport. Could you please add your review. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/3#issuecomment-1586171692

From asemenov at openjdk.org  Sun Jun 11 15:40:28 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 11 Jun 2023 15:40:28 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
 <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
 <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>
Message-ID: <eBtSHGuk6jA2M9fjawmCo9mpiqkzcvZUXalngywokB0=.4f3f5cfc-45ba-4cb8-94c6-fbe843201879@github.com>

On Tue, 6 Jun 2023 17:47:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is rarely used in the code and is not the essence of the current changes.
>> If you introduce such changes, then throughout the code.
>> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225
>
> I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now.

I think you can create a separate ticket and pull request to discuss this issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1225842637

From asemenov at openjdk.org  Sun Jun 11 16:38:31 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 11 Jun 2023 16:38:31 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - update
 - update
 - update
 - update
 - 8308286 Fix clang warnings in linux code

-------------

Changes: https://git.openjdk.org/jdk/pull/14033/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04
  Stats: 16 lines in 6 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From dnsimon at openjdk.org  Sun Jun 11 17:26:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sun, 11 Jun 2023 17:26:28 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v3]
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <kiL-2LqTUkcx0n5lOJzwdTmvaxyTlh3pw6v4r-iBh98=.d5aaef2b-4092-48cf-99db-dd7df9a1fbeb@github.com>

> This PR improves the startup time for libgraal by speeding up how `VM.savedProps` is copied into libgraal. This data structure is now serialized to a native buffer directly from C++ and the native buffer is then directly decoded by libgraal.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         0.02 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.10 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.07 user         0.01 sys
>         0.08 real         0.06 user         0.01 sys
>         0.08 real  ...

Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  copy system properties into libgraal more efficiently

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14291/files
  - new: https://git.openjdk.org/jdk/pull/14291/files/c3c04749..7a82c24e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=01-02

  Stats: 26320 lines in 384 files changed: 24869 ins; 633 del; 818 mod
  Patch: https://git.openjdk.org/jdk/pull/14291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14291/head:pull/14291

PR: https://git.openjdk.org/jdk/pull/14291

From duke at openjdk.org  Sun Jun 11 20:51:43 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 11 Jun 2023 20:51:43 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v3]
In-Reply-To: <q4dAvY29BadEcunZeqSSBqpwf5minhl7n6w7fhZggd8=.f693b939-b66d-4431-a5b2-5cbf8bb65d58@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <q4dAvY29BadEcunZeqSSBqpwf5minhl7n6w7fhZggd8=.f693b939-b66d-4431-a5b2-5cbf8bb65d58@github.com>
Message-ID: <llf7cpAr5y1dy-PWsRjlvJhCQ6WJ-YEiBaSeHDaJIOU=.136bc9b9-e316-4715-afe0-36677e42d6a7@github.com>

On Thu, 8 Jun 2023 16:46:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback

src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 314:

> 312:      * 4. the member takes a variable number of arguments and the last parameter
> 313:      *    is an array (see details below)
> 314:      * 5. the member's method type has an arity >= 255

Suggestion:

     * 1. during VM early startup before method handle support is fully initialized
     * 2. a Java native method
     * 3. -Djdk.reflect.useNativeAccessorOnly=true is set
     * 4. the member takes a variable number of arguments and the last parameter
     *    is not an array (see details below)
     * 5. the member's method type has an arity >= 255

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1225921483

From duke at openjdk.org  Sun Jun 11 23:18:12 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Sun, 11 Jun 2023 23:18:12 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a jlink
 image
Message-ID: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>

Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".

Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods

This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

-------------

Commit messages:
 - 8240567: MethodTooLargeException thrown while creating a jlink image

Changes: https://git.openjdk.org/jdk/pull/14408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8240567
  Stats: 254 lines in 2 files changed: 241 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14408/head:pull/14408

PR: https://git.openjdk.org/jdk/pull/14408

From duke at openjdk.org  Sun Jun 11 23:18:13 2023
From: duke at openjdk.org (Christoph)
Date: Sun, 11 Jun 2023 23:18:13 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <iaVY8lII5Vq86sWOfEfePEnYynsIRm_-4VxluJ3zn1g=.118844ab-d757-4950-ba44-2640fdecc779@github.com>

On Sun, 11 Jun 2023 21:01:54 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

We validated this by compiling JabRef against it and a) writing out the generated class file for the generated bytecode  and b)  verifying with -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal 

Is there a way to "parse" or call the verifyer after generation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1586339612

From mchung at openjdk.org  Mon Jun 12 00:53:38 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Jun 2023 00:53:38 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v4]
In-Reply-To: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
Message-ID: <aWowdCKV2CZDMXIsFzORWy0RHKEf7Mus0poAVkePyLo=.4a72383d-b32f-4e09-94d0-d90d23972766@github.com>

> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.

Mandy Chung has updated the pull request with a new target base 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:

 - fix typo
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - review feedback
 - fix merge issue
 - clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - Merge branch 'master' of https://github.com/openjdk/jdk into remove-old-reflection
 - merge
 - ... and 2 more: https://git.openjdk.org/jdk/compare/94b8262f...af4db44b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14371/files
  - new: https://git.openjdk.org/jdk/pull/14371/files/fc164c71..af4db44b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14371&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14371&range=02-03

  Stats: 9457 lines in 207 files changed: 8323 ins; 496 del; 638 mod
  Patch: https://git.openjdk.org/jdk/pull/14371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14371/head:pull/14371

PR: https://git.openjdk.org/jdk/pull/14371

From mchung at openjdk.org  Mon Jun 12 00:53:42 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Jun 2023 00:53:42 GMT
Subject: RFR: 8305104: Remove the old core reflection implementation [v3]
In-Reply-To: <llf7cpAr5y1dy-PWsRjlvJhCQ6WJ-YEiBaSeHDaJIOU=.136bc9b9-e316-4715-afe0-36677e42d6a7@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
 <q4dAvY29BadEcunZeqSSBqpwf5minhl7n6w7fhZggd8=.f693b939-b66d-4431-a5b2-5cbf8bb65d58@github.com>
 <llf7cpAr5y1dy-PWsRjlvJhCQ6WJ-YEiBaSeHDaJIOU=.136bc9b9-e316-4715-afe0-36677e42d6a7@github.com>
Message-ID: <03GtgbXxb_ruUGrK0d6IPeWyjW3_o9ulRjbT0toCiuk=.a6fbaa01-9428-4eae-bf61-3f8fcb553d6b@github.com>

On Sun, 11 Jun 2023 20:42:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 314:
> 
>> 312:      * 4. the member takes a variable number of arguments and the last parameter
>> 313:      *    is an array (see details below)
>> 314:      * 5. the member's method type has an arity >= 255
> 
> Suggestion:
> 
>      * 1. during VM early startup before method handle support is fully initialized
>      * 2. a Java native method
>      * 3. -Djdk.reflect.useNativeAccessorOnly=true is set
>      * 4. the member takes a variable number of arguments and the last parameter
>      *    is not an array (see details below)
>      * 5. the member's method type has an arity >= 255

Fixed.  Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14371#discussion_r1225976789

From jiangli at openjdk.org  Mon Jun 12 02:18:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 12 Jun 2023 02:18:57 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v9]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <ihqFliQYggKep8pnBDk8p9hPDo7CG9RfpWhiDXkp4cU=.c2a5b740-308f-498d-8040-07d8fde0dddc@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - - Use $1_ENABLE_PARTIAL_LINKING for checking if partial linking should be enabled, as suggested by @erikj79.
 - Merge branch 'master' into JDK-8307858
 - Need '$(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; )' for AR command if relative path is used.
 - Merge branch 'master' into JDK-8307858
 - Address comments/suggestions from @erikj79:
   - Only do partial linking step for building static libraries with clang on linux.
   - On macosx, workaround the long argument issue for 'AR' with relative path.
   
   Tested building jdk-image and static-libs-image on linux-x64 (for both gcc and clang) and macosx-x64 (clang) manually.
 - Update make/common/NativeCompilation.gmk
   
   Thanks you!
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
 - Update make/common/NativeCompilation.gmk
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - ... and 12 more: https://git.openjdk.org/jdk/compare/16c3d53b...af271e2c

-------------

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=08
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From duke at openjdk.org  Mon Jun 12 02:43:59 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 12 Jun 2023 02:43:59 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
Message-ID: <1d5S3drCyq7Snt6riJ7Qb85nt4L6tMZUPWqpkd7Xnyg=.4cb61015-49ab-4d5e-81c6-e9e0aacd6711@github.com>

On Wed, 7 Jun 2023 14:15:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Review changes, fixed tests
>  - Merge branch 'master' into hierarchy-resolve
>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>    2. Removed SecurityManager related content
>    3. Changed ClassHierarchyInfo into an interface
>    4. Moved caching method from static to instance method
>  - Merge branch 'master' into hierarchy-resolve
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/a1ab377d...90645b6f

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 103:

> 101:             }
> 102:             return descOrInternalName.substring(1, descOrInternalName.length() - 1).replace('/', '.');
> 103:         } else {

Note?that?this won?t?work?right if?this?method is?called?with the?internal?name of?a?class whose?FQCN starts?with?`L`, the correct implementation would be:
Suggestion:

        if (descOrInternalName.startsWith("L") && descOrInternalName.endsWith(";")) {
            // descriptors of classes or interfaces
            if (descOrInternalName.length() <= 2) {
                throw new IllegalArgumentException(descOrInternalName);
            }
            return descOrInternalName.substring(1, descOrInternalName.length() - 1).replace('/', '.');
        } else {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1226031008

From never at openjdk.org  Mon Jun 12 03:03:48 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 12 Jun 2023 03:03:48 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v3]
In-Reply-To: <kiL-2LqTUkcx0n5lOJzwdTmvaxyTlh3pw6v4r-iBh98=.d5aaef2b-4092-48cf-99db-dd7df9a1fbeb@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <kiL-2LqTUkcx0n5lOJzwdTmvaxyTlh3pw6v4r-iBh98=.d5aaef2b-4092-48cf-99db-dd7df9a1fbeb@github.com>
Message-ID: <J1ZtgxnE1Xy3DfrXEIWWCTRh96WMPwdxaB8yqRhmqAE=.fccae795-8ef8-4770-8d69-fc376cd4a981@github.com>

On Sun, 11 Jun 2023 17:26:28 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
>> 
>> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
>> 
>> ## Times
>> 
>> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
>> 
>> 
>> public class Nop {
>>     public static void main(String[] args) {}
>> }
>> 
>> 
>> (1) Baseline (no options):
>> 
>>> for i in (seq 10); java Nop; end
>>         0.05 real         0.04 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.00 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>> 
>> 
>> (2) Eagerly initialize libgraal (with PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.06 real         0.04 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>> 
>> 
>> (3) Eagerly initialize libgraal (without PR):
>> 
>>> for i in (seq 10...
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   copy system properties into libgraal more efficiently

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java line 314:

> 312:             String key = toJavaString(unsafe, unsafe.getLong(prop + keyOffset));
> 313:             long valueAddress = unsafe.getLong(prop + valueOffset);
> 314:             if (valueAddress != 0) {

Is the lazy value construction really necessary?  It seems like it requires quite a bit of extra machinery.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14291#discussion_r1226038627

From liach at openjdk.org  Mon Jun 12 04:56:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 04:56:11 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <1d5S3drCyq7Snt6riJ7Qb85nt4L6tMZUPWqpkd7Xnyg=.4cb61015-49ab-4d5e-81c6-e9e0aacd6711@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
 <1d5S3drCyq7Snt6riJ7Qb85nt4L6tMZUPWqpkd7Xnyg=.4cb61015-49ab-4d5e-81c6-e9e0aacd6711@github.com>
Message-ID: <QdEB5XTRUSOdhRYfXKtsbmefowiGNMc_nJ9yxKEMvOU=.c39452e1-f639-45cd-9107-eb3bf6e3e811@github.com>

On Mon, 12 Jun 2023 02:41:02 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Review changes, fixed tests
>>  - Merge branch 'master' into hierarchy-resolve
>>  - 1. Moved the default resolver to a static method, in anticipation of future changes
>>    2. Removed SecurityManager related content
>>    3. Changed ClassHierarchyInfo into an interface
>>    4. Moved caching method from static to instance method
>>  - Merge branch 'master' into hierarchy-resolve
>>  - rename to ofClassLoading/ofResourceParsing
>>    convert the default class provider to bypass security manager restrictions
>>  - Merge branch 'master' into hierarchy-resolve
>>  - Merge branch 'master' into hierarchy-resolve
>>  - Test both cached and uncached resolvers
>>  - Update the class hierarchy resolver api as per mailing list last week
>>  - Merge branch 'master' into hierarchy-resolve
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/a1ab377d...90645b6f
>
> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 103:
> 
>> 101:             }
>> 102:             return descOrInternalName.substring(1, descOrInternalName.length() - 1).replace('/', '.');
>> 103:         } else {
> 
> Note?that?this won?t?work?right if?this?method is?called?with the?internal?name of?a?class whose?FQCN starts?with?`L`, the correct implementation would be:
> Suggestion:
> 
>         if (descOrInternalName.startsWith("L") && descOrInternalName.endsWith(";")) {
>             // descriptors of classes or interfaces
>             if (descOrInternalName.length() <= 2) {
>                 throw new IllegalArgumentException(descOrInternalName);
>             }
>             return descOrInternalName.substring(1, descOrInternalName.length() - 1).replace('/', '.');
>         } else {

Honestly, this API should be changed to take a ClassDesc instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1226080172

From alanb at openjdk.org  Mon Jun 12 05:06:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Jun 2023 05:06:51 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>

On Sun, 11 Jun 2023 21:01:54 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

@koppor Is this ready for review? The other PR went through a dozens or so iterations before it was returned to draft. It seems like you were still battling with verifier errors. The comment on this PR says you it was created because a force-push so I can't tell if you the changes are ready or not.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 754:

> 752:                             // Restore all (!) sets from parameter to local variables
> 753:                             if (nextLocalVar > firstVariableForDedup) {
> 754:                                 // We need to go from the end to the beginning as we will probably overwrite position 2 (which holds the list at the beginning)

Do you mind fixing all the comments as these 160+ lines make it impossible to look at the changes side-by-side again. You had fixed that in the original PR but it looks like they have come back with this PR.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14408#pullrequestreview-1474034803
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1226084193

From liach at openjdk.org  Mon Jun 12 05:26:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 05:26:54 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v11]
In-Reply-To: <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
Message-ID: <m2BZwiwO190Mo4r5kUv0A97JUG9P6H4a8-ehzciFZRE=.5b44619c-8ac3-4653-a50f-bca3c68dbed1@github.com>

On Thu, 8 Jun 2023 01:32:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt  Score   Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt     Score     Error  Units
>> Benchmark                                            Mode  Cnt   Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove meaningless target calls and clear outdated cache as needed

Will fix the indirect var handle NPE in a separate patch as recommended by Mandy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1586604136

From liach at openjdk.org  Mon Jun 12 05:43:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 05:43:07 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v9]
In-Reply-To: <QdEB5XTRUSOdhRYfXKtsbmefowiGNMc_nJ9yxKEMvOU=.c39452e1-f639-45cd-9107-eb3bf6e3e811@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <0RmULuYLatKjDyzBQB7Qxep-oSkpCKdh7zBDzuQiPvM=.2eed570e-cc6d-4103-b733-8cca3c4eaf33@github.com>
 <1d5S3drCyq7Snt6riJ7Qb85nt4L6tMZUPWqpkd7Xnyg=.4cb61015-49ab-4d5e-81c6-e9e0aacd6711@github.com>
 <QdEB5XTRUSOdhRYfXKtsbmefowiGNMc_nJ9yxKEMvOU=.c39452e1-f639-45cd-9107-eb3bf6e3e811@github.com>
Message-ID: <0B6CAdfoNLjLpDFcwFjuL7ZWbZ2Ml1fVG6Fs4332G4Y=.4d1d9566-d930-4153-a491-649b46a67019@github.com>

On Mon, 12 Jun 2023 04:52:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 103:
>> 
>>> 101:             }
>>> 102:             return descOrInternalName.substring(1, descOrInternalName.length() - 1).replace('/', '.');
>>> 103:         } else {
>> 
>> Note?that?this won?t?work?right if?this?method is?called?with the?internal?name of?a?class whose?FQCN starts?with?`L`, the correct implementation would be:
>> Suggestion:
>> 
>>         if (descOrInternalName.startsWith("L") && descOrInternalName.endsWith(";")) {
>>             // descriptors of classes or interfaces
>>             if (descOrInternalName.length() <= 2) {
>>                 throw new IllegalArgumentException(descOrInternalName);
>>             }
>>             return descOrInternalName.substring(1, descOrInternalName.length() - 1).replace('/', '.');
>>         } else {
>
> Honestly, this API should be changed to take a ClassDesc instead.

In fact, the specification (javadoc) on this method is wrong: it will never take an internal name; it only takes descriptors and tries to simulate the result of `Class::getName`, since `ClassDesc` lacks such functionality.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1226107958

From duke at openjdk.org  Mon Jun 12 05:47:41 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 12 Jun 2023 05:47:41 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <bfpF0d9eG0aNmZzhZfrU0meK5O9O36KVKcSPtwck3p0=.c0617ed7-dc36-49a2-bad7-1ac42acf5551@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:

 - Remove "final" at "enabled" - not part of the point of this PR
 - Remove comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/7c486935..9d4142cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=00-01

  Stats: 26 lines in 1 file changed: 0 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14408/head:pull/14408

PR: https://git.openjdk.org/jdk/pull/14408

From duke at openjdk.org  Mon Jun 12 05:47:45 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 12 Jun 2023 05:47:45 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
Message-ID: <3jnh9kj7t4mVGbxfpFIJC6IGQS_QhqlSG-DrTGW1d1A=.9775f848-b147-45d6-bf14-68f73adc4231@github.com>

On Mon, 12 Jun 2023 05:02:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you mind fixing all the comments as these 160+ lines

Done. I copied the (for me) important comments to the GitHub reply https://github.com/openjdk/jdk/pull/14408#issuecomment-1586615579.

> You had fixed that in the original PR but it looks like they have come back with this PR.

This is my job training ?: Comment the core ideas (and do not verbatim repeat what is said by the code directly). - For me, the good thing is, the diff now has all the comments (https://github.com/openjdk/jdk/pull/14408/commits/23bbc0ce0c8fd8a4cd689c0260c5fbcb91b20046). OK, at least one has go to nirvana in all cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1226108776

From duke at openjdk.org  Mon Jun 12 05:47:43 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 12 Jun 2023 05:47:43 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <HEERfuTBs3A1EVydPZ3vduxxNNodx_jjMdoWWRKGwUM=.6569a9cd-7790-4cef-b81b-55e95678c37e@github.com>

On Sun, 11 Jun 2023 21:01:54 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

TL;DR: summary of the changes

- In the other PR we missed that `dedupSetBuilder` requires local variables in the method for caching
  - Code comments: `// Restore all (!) sets from parameter to local variables` and `// Store all new sets to List`
- In this PR, these variables are transferred from method to method by a `ArrayList`
- `0` is `this` when a method is called. `this` is needed to call the next helper method, thus we moved `BUILDER_VAR` to another place.
  - Code comments: `MAX_LOCAL_VARS + 1; // we need 0 for "this"` and on `MAX_LOCAL_VARS`: `// Constant chosen for this generator, can be higher in practice`

> @koppor Is this ready for review?

Yes, it is! We especially checked it with our (rather large) desktop application.

> The other PR went through a dozens or so iterations before it was returned to draft.

I remember ?. Therefore, we first had this as draft, waited for the "on-site checks" and then opened it.

> It seems like you were still battling with verifier errors. 

We missed an important point and the other PR.

> The comment on this PR says you it was created because a force-push so I can't tell if you the changes are ready or not.

I am sorry for that. I weighted the requirement to have a single commit higher than reviewing the changes. The "excuse" for this decision is that nearly all code submitted back than has changed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1586615579

From chagedorn at openjdk.org  Mon Jun 12 06:45:02 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 12 Jun 2023 06:45:02 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v6]
In-Reply-To: <ERPIRYWlmzrLw8dhG9Ggyp_u7SusdwhGc5DUh7yLMpE=.b6990f67-6395-4c2e-868a-1064e1334e4f@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <ERPIRYWlmzrLw8dhG9Ggyp_u7SusdwhGc5DUh7yLMpE=.b6990f67-6395-4c2e-868a-1064e1334e4f@github.com>
Message-ID: <fRe6Y1CckZrP5pJAOBIaiy3TekbEEhCgnYa4gmyvjDc=.5d71c2c5-cd60-4384-a532-9f81a459cc89@github.com>

On Sat, 10 Jun 2023 12:25:57 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
>> 
>> ### Old CompileOnly format
>> - matching a **method name** with **class name** and **package name**:
>> `-XX:CompileOnly=package/path/Class.method`
>> `-XX:CompileOnly=package/path/Class::method`
>> `-XX:CompileOnly=package.path.Class::method`
>> BUT NOT `-XX:CompileOnly=package.path.Class.method`
>> 
>> - just matching a **single method name**:
>> `-XX:CompileOnly=.hashCode`
>> `-XX:CompileOnly=::hashCode`
>> BUT NOT `-XX:CompileOnly=hashCode`
>> 
>> - Matching **all method names** in a **class name** with **package name**
>> `-XX:CompileOnly=java/lang/String`
>> BUT NOT `-XX:CompileOnly=java/lang/String.`
>> BUT NOT `-XX:CompileOnly=java.lang.String`
>> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
>> BUT NOT `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - Matching **all method names** in a **class name** with **NO package name**
>> `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
>> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
>> 
>> ### CompileCommand=compileonly format
>> `CompileCommand` allows two different forms for paths: 
>> - `package/path/Class.method`
>> - `package.path.Class::method`
>> 
>> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
>> 
>>  Valid forms: 
>> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
>> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
>> `-XX:CompileCommand=compileonly,java.lang.String::*`
>> `-XX:CompileCommand=compileonly,*::hashCode`
>> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
>> `-XX:CompileCommand=compileonly,*String::hash*`
>> 
>>  Invalid forms (Error: Embedded * not allowed):
>>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
>> 
>> ### Use CompileCommand syntax for CompileOnly
>> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
>> 
>> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
>> 
>> W...
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update new Tests

Update and testing results look good now!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1474141188

From thartmann at openjdk.org  Mon Jun 12 06:45:03 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 12 Jun 2023 06:45:03 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v6]
In-Reply-To: <ERPIRYWlmzrLw8dhG9Ggyp_u7SusdwhGc5DUh7yLMpE=.b6990f67-6395-4c2e-868a-1064e1334e4f@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <ERPIRYWlmzrLw8dhG9Ggyp_u7SusdwhGc5DUh7yLMpE=.b6990f67-6395-4c2e-868a-1064e1334e4f@github.com>
Message-ID: <VdA9pkjGE3TN-eaam3O_h53Z3hY46vxUf0T3wjhw43I=.cc16b15d-1b6a-48d7-b346-e4d7c88f4542@github.com>

On Sat, 10 Jun 2023 12:25:57 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
>> 
>> ### Old CompileOnly format
>> - matching a **method name** with **class name** and **package name**:
>> `-XX:CompileOnly=package/path/Class.method`
>> `-XX:CompileOnly=package/path/Class::method`
>> `-XX:CompileOnly=package.path.Class::method`
>> BUT NOT `-XX:CompileOnly=package.path.Class.method`
>> 
>> - just matching a **single method name**:
>> `-XX:CompileOnly=.hashCode`
>> `-XX:CompileOnly=::hashCode`
>> BUT NOT `-XX:CompileOnly=hashCode`
>> 
>> - Matching **all method names** in a **class name** with **package name**
>> `-XX:CompileOnly=java/lang/String`
>> BUT NOT `-XX:CompileOnly=java/lang/String.`
>> BUT NOT `-XX:CompileOnly=java.lang.String`
>> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
>> BUT NOT `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - Matching **all method names** in a **class name** with **NO package name**
>> `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
>> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
>> 
>> ### CompileCommand=compileonly format
>> `CompileCommand` allows two different forms for paths: 
>> - `package/path/Class.method`
>> - `package.path.Class::method`
>> 
>> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
>> 
>>  Valid forms: 
>> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
>> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
>> `-XX:CompileCommand=compileonly,java.lang.String::*`
>> `-XX:CompileCommand=compileonly,*::hashCode`
>> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
>> `-XX:CompileCommand=compileonly,*String::hash*`
>> 
>>  Invalid forms (Error: Embedded * not allowed):
>>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
>> 
>> ### Use CompileCommand syntax for CompileOnly
>> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
>> 
>> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
>> 
>> W...
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update new Tests

Still looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1474142986

From duke at openjdk.org  Mon Jun 12 06:59:50 2023
From: duke at openjdk.org (Christoph)
Date: Mon, 12 Jun 2023 06:59:50 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <3jnh9kj7t4mVGbxfpFIJC6IGQS_QhqlSG-DrTGW1d1A=.9775f848-b147-45d6-bf14-68f73adc4231@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
 <3jnh9kj7t4mVGbxfpFIJC6IGQS_QhqlSG-DrTGW1d1A=.9775f848-b147-45d6-bf14-68f73adc4231@github.com>
Message-ID: <_BY5BTLKskCjS2X5lcjqLJd4sF89ma8CgGDTiEJt6KI=.699e38b2-9b9b-49cc-9be5-142cff32e74e@github.com>

On Mon, 12 Jun 2023 05:41:08 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 754:
>> 
>>> 752:                             // Restore all (!) sets from parameter to local variables
>>> 753:                             if (nextLocalVar > firstVariableForDedup) {
>>> 754:                                 // We need to go from the end to the beginning as we will probably overwrite position 2 (which holds the list at the beginning)
>> 
>> Do you mind fixing all the comments as these 160+ lines make it impossible to look at the changes side-by-side again. You had fixed that in the original PR but it looks like they have come back with this PR.
>
>> Do you mind fixing all the comments as these 160+ lines
> 
> Done. I copied the (for me) important comments to the GitHub reply https://github.com/openjdk/jdk/pull/14408#issuecomment-1586615579.
> 
>> You had fixed that in the original PR but it looks like they have come back with this PR.
> 
> This is my job training ?: Comment the core ideas (and do not verbatim repeat what is said by the code directly). - For me, the good thing is, the diff now has all the comments (https://github.com/openjdk/jdk/pull/14408/commits/23bbc0ce0c8fd8a4cd689c0260c5fbcb91b20046). OK, at least one has go to nirvana in all cases.

Yes, the verify errors are gone. Application (JabRef) starts sucessfully against the compilation. Is there a way to verify in a tesr the creation of the helper methos in the bytecode? e.g. something like getDeclaredMethods?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1226170715

From mbaesken at openjdk.org  Mon Jun 12 07:10:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 07:10:57 GMT
Subject: Integrated: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <m7gB3eS77Ud8qStzt2DfZ-h-X5lZG7zGVCfVDcOlL9g=.1338427b-7900-4592-bde5-ec97a6085b4b@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

This pull request has now been integrated.

Changeset: 4d66d977
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d66d977450e083214da3dba6ad4ed851c6c1cb4
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

Reviewed-by: alanb, cjplummer, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/14393

From tholenstein at openjdk.org  Mon Jun 12 07:42:59 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Mon, 12 Jun 2023 07:42:59 GMT
Subject: Integrated: JDK-8027711: Unify wildcarding syntax for CompileCommand
 and CompileOnly
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <nBSarxrI7w3aOOYaaiUNGfK2Ic8hT-i-24qfUqiYjkI=.261e8ca4-7881-443e-a293-e5eb4b3ed115@github.com>

On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileCommand=compileonly` with possibility to take lists as ...

This pull request has now been integrated.

Changeset: f5cbe53f
Author:    Tobias Holenstein <tholenstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5cbe53fdd736f54a140e9db2499a7439f8752c4
Stats:     376 lines in 73 files changed: 29 ins; 69 del; 278 mod

8027711: Unify wildcarding syntax for CompileCommand and CompileOnly

Reviewed-by: kvn, thartmann, chagedorn

-------------

PR: https://git.openjdk.org/jdk/pull/13802

From liach at openjdk.org  Mon Jun 12 08:07:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 08:07:15 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class and
 MethodTypeDesc
Message-ID: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>

The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.

1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.

A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.

The rendered specifications:
https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/Class.html
https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/invoke/MethodType.html

-------------

Commit messages:
 - 8309819: Fix specification about descriptor inverses in Class and MethodTypeDesc

Changes: https://git.openjdk.org/jdk/pull/14411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309819
  Stats: 27 lines in 2 files changed: 10 ins; 3 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From coffeys at openjdk.org  Mon Jun 12 08:55:41 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 12 Jun 2023 08:55:41 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <IHpJIOf6DnRqIVVDZUWZX82UNnhrzPxvAWHB4NhOCXs=.798d2f9d-213f-4459-b473-32a07087a849@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Thanks for the reviews to date. All good comments, I'll implement.

Yes, the output of `-XShowSettings` is more verbose. Let me try and re-implement with a new user option. Perhaps, we could have some of the key security settings show up with the `-XShowSettings` option (static provider names (I should list them in preference order actually) and enabled TLS protocols ?) and then have some help output hinting about how to get verbose output ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1586880695

From dnsimon at openjdk.org  Mon Jun 12 09:21:14 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 12 Jun 2023 09:21:14 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v4]
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <bTOmklozZb9KZQ3UGhvqINCpD45kR59QHwIGe61Yqvs=.bb62a33f-f5d2-4830-bb0d-13ee806904ad@github.com>

> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
> 
> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         ...

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  reduced complexity of SystemProperties based on it being unmodifiable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14291/files
  - new: https://git.openjdk.org/jdk/pull/14291/files/7a82c24e..6c346d35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=02-03

  Stats: 207 lines in 2 files changed: 33 ins; 160 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14291/head:pull/14291

PR: https://git.openjdk.org/jdk/pull/14291

From dnsimon at openjdk.org  Mon Jun 12 09:22:53 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 12 Jun 2023 09:22:53 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v3]
In-Reply-To: <J1ZtgxnE1Xy3DfrXEIWWCTRh96WMPwdxaB8yqRhmqAE=.fccae795-8ef8-4770-8d69-fc376cd4a981@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <kiL-2LqTUkcx0n5lOJzwdTmvaxyTlh3pw6v4r-iBh98=.d5aaef2b-4092-48cf-99db-dd7df9a1fbeb@github.com>
 <J1ZtgxnE1Xy3DfrXEIWWCTRh96WMPwdxaB8yqRhmqAE=.fccae795-8ef8-4770-8d69-fc376cd4a981@github.com>
Message-ID: <xsOOrlJZCbziwqp7_bzu3dSVXRKPjlXGCYvkzcsv9uQ=.784266e2-e546-4115-be07-9d3b0ef3bd7d@github.com>

On Mon, 12 Jun 2023 03:00:23 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   copy system properties into libgraal more efficiently
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java line 314:
> 
>> 312:             String key = toJavaString(unsafe, unsafe.getLong(prop + keyOffset));
>> 313:             long valueAddress = unsafe.getLong(prop + valueOffset);
>> 314:             if (valueAddress != 0) {
> 
> Is the lazy value construction really necessary?  It seems like it requires quite a bit of extra machinery.

In big apps, I image there can be quite some large system property values (e.g. `java.class.path`) so we don't want to pay memory overhead per libgraal isolate for such properties as they're ignored by libgraal.

I realized I can reduce the extra machinery based on the fact that `SystemProperties` is unmodifiable: https://github.com/openjdk/jdk/pull/14291/commits/6c346d35923402fb5d6ae0ef83214f8f0ca07b69
The only method that still eager converts the string is `SystemProperties.values()` but that's fine as it's not used by JVMCI or Graal.
I think the trade off is now acceptable?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14291#discussion_r1226352693

From jpai at openjdk.org  Mon Jun 12 09:47:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Jun 2023 09:47:54 GMT
Subject: RFR: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError [v6]
In-Reply-To: <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
 <rUMQPC4RoViwPqIx9_pJrEZqsCGLFDUVkfBvbgPI4V0=.23a41c60-b854-41da-820b-4d19e150289f@github.com>
Message-ID: <3lGk4K_Hp5ezIMmA5jwoJKELEdh3Mlrc_z5DvgN2xWQ=.d4132e17-a8a9-4e9e-83d8-f16c16908b25@github.com>

On Sat, 10 Jun 2023 06:44:56 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-8308184?
>> 
>> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
>> 
>> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
>> 
>> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
>> 
>> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class ...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move the test to test/jdk/sun/misc/URLClassPath directory

Thank you Alan and Mandy for the reviews. tier1, tier2, tier3 testing came back fine. I'll go ahead and merge this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14395#issuecomment-1586976047

From jpai at openjdk.org  Mon Jun 12 09:47:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Jun 2023 09:47:56 GMT
Subject: Integrated: 8308184: Launching java with large number of jars in
 classpath with java.protocol.handler.pkgs system property set can lead to
 StackOverflowError
In-Reply-To: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
References: <QS8ws3r7_dezJsuU0B5mQtg_Eq8oWoKZZX6b0GcrCXY=.6e2c45fc-8038-4202-97e6-86a9276eec80@github.com>
Message-ID: <nkgdFCDmZT-IcndtrUO9GTmMETzTlFHjSly34OWbJr8=.52fcef98-b376-4f40-a05e-95cbc6dcfc25@github.com>

On Fri, 9 Jun 2023 14:55:50 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-8308184?
> 
> When an application is launched, the `app` classloader internally uses a `jdk.internal.loader.URLClassPath` to find and load the main class being launched. The `URLClassPath` uses a list of classpath entries to find resources. Depending on the classpath entry, the `URLClassPath` will use a relevant loader. A couple of such loaders are `URLClassPath$FileLoader` (for loading resources from directories) and `URLClassPath$JarLoader` (for loading resources from jar files).
> 
> `JarLoader` creates instances of `java.net.URL` to represent the jar file being loaded. `java.net.URL` uses protocol specific `java.net.URLStreamHandler` instance to handle connections to those URLs. When constructing an instance of `URL`, callers can pass a protocol handler. If it is not passed then the `URL` class looks for protocol handlers that might have been configured by the application. The `java.protocol.handler.pkgs` system property is the one which allows overriding the protocol handlers (even for the `jar` protocol). When this property is set, the `URL` class triggers lookup and classloading of the protocol handler classes.
> 
> The issue that is reported is triggered when the `java.protocol.handler.pkgs` system property is set and the classpath has too many jar files. `app` classloader triggers lookup of the main class and the `URLClassPath` picks up the first entry in the classpath and uses a `JarLoader` (in this example our classpath entries have a jar file at the beginning of the list). The `JarLoader` instantiates a `java.net.URL`, which notices that the `java.protocol.handler.pkgs` is set, so it now triggers lookup of a (different) class using the same classloader and thus the same `URLClassPath`. The `URLClassPath` picks the next classpath entry and then calls into the `URL` again through the `JarLoader`. This sequence ends up being re-entrant calls and given the large number of classpath entries, these re-entrant calls end up with a `StackOverflowError` as shown in the linked JBS issue.
> 
> The commit in this PR fixes this issue by using the system provided protocol handler implementation of the `jar` protocol in the `app` classloader. This results in the `URL` instances created through the `JarLoader` to use this specific handler instance. This allows the `app` classloader which is responsible for loading the application's main class to reliably use th...

This pull request has now been integrated.

Changeset: 268ec61d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/268ec61d4fa9c5b7d2c7bcafb942b33e5b189974
Stats:     145 lines in 2 files changed: 142 ins; 2 del; 1 mod

8308184: Launching java with large number of jars in classpath with java.protocol.handler.pkgs system property set can lead to StackOverflowError

Reviewed-by: mchung, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14395

From liach at openjdk.org  Mon Jun 12 09:53:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 09:53:53 GMT
Subject: RFR: 8309838: Classfile API Util.toBinaryName and other cleanup
Message-ID: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>

Thanks to @exe-boss for the reviews in #13082. This cleanup patch fixed the typos you pointed out and removed other redundancies in classfile Util as well.

-------------

Commit messages:
 - 8309838: Classfile API Util.toBinaryName and other cleanup

Changes: https://git.openjdk.org/jdk/pull/14412/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14412&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309838
  Stats: 77 lines in 4 files changed: 1 ins; 62 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14412/head:pull/14412

PR: https://git.openjdk.org/jdk/pull/14412

From mcimadamore at openjdk.org  Mon Jun 12 10:04:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 10:04:05 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <B5v9SN6F-iSLZxy3l6w7HsMGzCM5Relu4ihnOkVni64=.28872a91-8aba-408c-b627-13b98e0b5bca@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>
 <Bvs_qCCVorKqn0QV06VCgfQIfi1UBK6am5FAOk4Y0fg=.6fbc297c-9ed2-4a99-b731-27a16011ea3a@github.com>
 <yLOcdp3VmicwSTDLQFmVMt6ZJQNWqkeTHW_LblNlT2U=.b3a5e1c7-ec2b-4bac-93dc-85ed4f53f291@github.com>
 <xz0oc-eX0_Z3KmIsuXondRBAlI4uigzMo2OE5OpunqQ=.9bcd4a2b-f473-4d54-b977-a5fbddd37321@github.com>
 <DYryHRUnx221CyxFIxROmydIRCUDOr0NQks5Iwttnik=.39a21a8b-1525-420d-84bf-54a674fbcdfb@github.com>
 <ys6EN4ua3EleWhZOGWgFXMrivoxFGepeWcARYf5ND68=.8c33d02a-37f2-4c55-9d77-b6f016853a57@github.com>
 <B5v9SN6F-iSLZxy3l6w7HsMGzCM5Relu4ihnOkVni64=.28872a91-8aba-408c-b627-13b98e0b5bca@github.com>
Message-ID: <hdA386-HEx1L03GFP4aZalc1qWxY0zt9XNvE1WWq4W4=.8976a4b7-9dad-409d-bfc4-dac8a14f9e99@github.com>

On Fri, 9 Jun 2023 18:22:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> But, the implementation of `byteOffsetHandle` rejects range elements: https://github.com/openjdk/jdk/pull/14098/files/265e0d5b082ad54d1cadea1d4a8bd844e72e3926#diff-90ecdacbee63a90f6e695a8bb4c1ad69b591602501613a774561c4032f01fb95R352
>> 
>> So this test fails (at least it does here...)
>
> Though, I agree that it seems fine to support ranges

I see, the issue is with the impl (I agree) not with the javadoc as I understood.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1226404584

From mcimadamore at openjdk.org  Mon Jun 12 10:33:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 10:33:41 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v7]
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <fwmQcmgtrm0n_UI4h90UTs1ZYI570asx-oKzIqeK3Kg=.0b272521-06b7-4618-845c-e538de7e6ddb@github.com>

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an overflow during ...

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge branch 'master' into javadoc_fixes
 - Fix implementation for byteOffsetHandle to accept ranged open paths.
 - Merge branch 'master' into javadoc_fixes
 - Fix issue with ArithmeticException not being wrapped in IAE for SequenceLayout::withElementCount
   Fix issue with IAE thrown instead of UOE for ValueLayout::arrayElementVarHandle
   Add apiNote to MemorySegment::address re. reachability
 - Missed a review comment
 - Use more `{@return}` tags
 - Address review comments
 - Fix wrong link in layout well-formedness doc
 - Improve javadoc on supported linker layouts
 - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
 - ... and 21 more: https://git.openjdk.org/jdk/compare/268ec61d...78f7bd24

-------------

Changes: https://git.openjdk.org/jdk/pull/14098/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=06
  Stats: 964 lines in 28 files changed: 357 ins; 138 del; 469 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

PR: https://git.openjdk.org/jdk/pull/14098

From mcimadamore at openjdk.org  Mon Jun 12 10:33:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 10:33:44 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v6]
In-Reply-To: <Vsuf88ibaJ0trBF2u8MS1Lng5JtVvZHjK0z434S8mgs=.ba1db33f-f9d1-4a7e-a7de-aa191f4464bd@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <Vsuf88ibaJ0trBF2u8MS1Lng5JtVvZHjK0z434S8mgs=.ba1db33f-f9d1-4a7e-a7de-aa191f4464bd@github.com>
Message-ID: <St7TeBhD1chuQF3VsxLABKyMOC0Dbrvc-r1f691imgM=.030c5558-b3c1-43e9-a72b-0aa6912cbc27@github.com>

On Tue, 6 Jun 2023 10:35:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' into javadoc_fixes
>  - Fix issue with ArithmeticException not being wrapped in IAE for SequenceLayout::withElementCount
>    Fix issue with IAE thrown instead of UOE for ValueLayout::arrayElementVarHandle
>    Add apiNote to MemorySegment::address re. reachability
>  - Missed a review comment
>  - Use more `{@return}` tags
>  - Address review comments
>  - Fix wrong link in layout well-formedness doc
>  - Improve javadoc on supported linker layouts
>  - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
>  - Merge branch 'master' into javadoc_fixes
>  - Add overflow tests
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/01455a07...b59edd93

Closing, as the review is complete and I have to rebase against the forked 21 repo. A similar PR will pop up soon :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1587049739

From mcimadamore at openjdk.org  Mon Jun 12 10:33:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 10:33:47 GMT
Subject: Withdrawn: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <c2NMm5IwmaNsameezqGgJCKytXM8lnNGb0deJmHX5f0=.a74d8f27-0613-45e2-8de2-3bc81c4b0e65@github.com>

On Tue, 23 May 2023 11:48:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an overflow during ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14098

From duke at openjdk.org  Mon Jun 12 10:47:50 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 12 Jun 2023 10:47:50 GMT
Subject: RFR: 8309838: Classfile API Util.toBinaryName and other cleanup
In-Reply-To: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
References: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
Message-ID: <S3zR0F_4HmLffjlkNXoLh2-Of3R1h8iXdgRs9n7K7kg=.3a25f09c-8c65-4c80-93d4-a102d03591a1@github.com>

On Mon, 12 Jun 2023 09:45:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks to @exe-boss for the reviews in #13082. This cleanup patch fixed the typos you pointed out and removed other redundancies in classfile Util as well.

src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 90:

> 88:     public static String toBinaryName(ClassDesc cd) {
> 89:         return toInternalName(cd).replace('/', '.');
> 90:     }

Note?that this?method is?called?with array?class?descriptors as?well, so?the?correct implementation would?be:
Suggestion:

    public static String toBinaryName(ClassDesc cd) {
        return (cd.isArray() ? cd.descriptorString() : toInternalName(cd))
            .replace('/', '.');
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14412#discussion_r1226461591

From liach at openjdk.org  Mon Jun 12 10:56:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 10:56:52 GMT
Subject: RFR: 8309838: Classfile API Util.toBinaryName and other cleanup
In-Reply-To: <S3zR0F_4HmLffjlkNXoLh2-Of3R1h8iXdgRs9n7K7kg=.3a25f09c-8c65-4c80-93d4-a102d03591a1@github.com>
References: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
 <S3zR0F_4HmLffjlkNXoLh2-Of3R1h8iXdgRs9n7K7kg=.3a25f09c-8c65-4c80-93d4-a102d03591a1@github.com>
Message-ID: <tvMYjZV_s8vsA0F53Q_Ogh8-JOZhSvtupSdGSK0A9PY=.eee6cff4-d891-477b-a80e-f52b7c5489aa@github.com>

On Mon, 12 Jun 2023 10:45:03 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Thanks to @exe-boss for the reviews in #13082. This cleanup patch fixed the typos you pointed out and removed other redundancies in classfile Util as well.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 90:
> 
>> 88:     public static String toBinaryName(ClassDesc cd) {
>> 89:         return toInternalName(cd).replace('/', '.');
>> 90:     }
> 
> Note?that this?method can?get?called with array?class?descriptors as?well, so?the?correct implementation would?be:
> Suggestion:
> 
>     public static String toBinaryName(ClassDesc cd) {
>         return (cd.isArray() ? cd.descriptorString() : toInternalName(cd))
>             .replace('/', '.');
>     }

This isn't. We don't pass array classes to ClassHierarchyResolvers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14412#discussion_r1226470850

From mcimadamore at openjdk.org  Mon Jun 12 11:08:02 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 11:08:02 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
Message-ID: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>

This is the same PR as https://github.com/openjdk/jdk/pull/14098, but backported to the JDK 21 repo fork.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk21/pull/7/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=7&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308645
  Stats: 964 lines in 28 files changed: 357 ins; 138 del; 469 mod
  Patch: https://git.openjdk.org/jdk21/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/7/head:pull/7

PR: https://git.openjdk.org/jdk21/pull/7

From asotona at openjdk.org  Mon Jun 12 11:20:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Jun 2023 11:20:40 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v13]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <WVxhI78Zmqpf6nWEUjjjSmc0pTDCXQ4jP7EVDawuJqg=.cd623a45-bd58-4ffc-8037-08159ad52bc7@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
   esolver.java
 - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
   
   This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/fd65c367..344ccede

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=11-12

  Stats: 83 lines in 7 files changed: 42 ins; 25 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From liach at openjdk.org  Mon Jun 12 11:30:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 11:30:51 GMT
Subject: RFR: 8309838: Classfile API Util.toBinaryName and other cleanup
In-Reply-To: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
References: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
Message-ID: <B7hFaUkllVMLsB8mlhf-vkFPsPygCy6fDDmMfG-JBs0=.1985e29d-c35b-4113-abc0-6c664342055a@github.com>

On Mon, 12 Jun 2023 09:45:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks to @exe-boss for the reviews in #13082. This cleanup patch fixed the typos you pointed out and removed other redundancies in classfile Util as well.

@asotona Can you please review this when you are free?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14412#issuecomment-1587140929

From erikj at openjdk.org  Mon Jun 12 12:30:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Jun 2023 12:30:55 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
Message-ID: <gsunSnFI-zLXJ0T0_foKShSTuXvUuhY0J7y-8oA-HAk=.1a6208f6-261e-49eb-8786-cd11dd2a7c31@github.com>

On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - update
>  - update
>  - update
>  - update
>  - 8308286 Fix clang warnings in linux code

Build changes look ok.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1587242876

From ayang at openjdk.org  Mon Jun 12 12:51:52 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 12 Jun 2023 12:51:52 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

test/hotspot/jtreg/gc/TestAllocHumongousFragment.java line 180:

> 178:  */
> 179: 
> 180: /*

Could you move this block a few lines above (e.g. next to the block of `id=iu-aggressive`) so that similar tests are grouped together?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1226617033

From mullan at openjdk.org  Mon Jun 12 12:59:42 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 12 Jun 2023 12:59:42 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <c_KUu5S9S1Yy157vmNsCQOUf-95cVgSXgPjFMSe6JSI=.198ef85a-7e85-4106-8e64-fbd6cb2a65e4@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Another possibility is to put this under a new option, ex `-XshowSecuritySettings`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1587290923

From jvernee at openjdk.org  Mon Jun 12 13:17:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 12 Jun 2023 13:17:57 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
References: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
Message-ID: <RCdEGxQlmh18dLreIpc-1j6D8ZZYTVPrJStOSMYS4HU=.d27a922e-2096-4593-8c27-9b96f00d529e@github.com>

On Mon, 12 Jun 2023 11:01:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is the same PR as https://github.com/openjdk/jdk/pull/14098, but backported to the JDK 21 repo fork.

Already reviewed the other PR.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/7#pullrequestreview-1474902428

From stsypanov at openjdk.org  Mon Jun 12 13:30:41 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 12 Jun 2023 13:30:41 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <UfvDL9yxr6srcg0YQPvYOzL2ZYhBlAy8Uhz228WZqHc=.7cf17196-b445-4be2-9e73-ddb3d259c017@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo001/ownedMonitorsStackDepthInfo001a.java line 113:

> 111:             return -1;
> 112:         } else {
> 113:             return depth + 2;

Doesn't it change the logic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1226668010

From aph at openjdk.org  Mon Jun 12 14:09:59 2023
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 12 Jun 2023 14:09:59 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v2]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <xFI2j5L-oBu7t3asNxhwHvMrn5BcrH8LKXpc2kgDi00=.9d3ac600-34de-4629-b8fd-9d9131578708@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Whitespace
 - Use RunWith in base Thread class & enable testing without VM Continuations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/0f81c56a..3ab613fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=00-01

  Stats: 28 lines in 5 files changed: 7 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From dfuchs at openjdk.org  Mon Jun 12 14:29:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:29:50 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

The new code looks much easier to maintain than the old one. I couldn't figure out what the old code was actually trying to do, but reading the new code I now understand what it does. Caching, retrieval, hashCode and equals look good. From the code it's trivial to see that a new normalised BaseLocale will be created if none is found in the cache - so that will assuredly fix the NPE that was experienced previously when the cache was cleared. The main change is that base locales will now be cached using WeakReference rather than SoftReference, and thus probably collected more eagerly, but that actually looks like a positive change. Not a usual reviewer in this area so please get another reviewer before integrating (also I haven't looked at the test).

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475076367

From alanb at openjdk.org  Mon Jun 12 14:30:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Jun 2023 14:30:59 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v2]
In-Reply-To: <xFI2j5L-oBu7t3asNxhwHvMrn5BcrH8LKXpc2kgDi00=.9d3ac600-34de-4629-b8fd-9d9131578708@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <xFI2j5L-oBu7t3asNxhwHvMrn5BcrH8LKXpc2kgDi00=.9d3ac600-34de-4629-b8fd-9d9131578708@github.com>
Message-ID: <5sBVyW7eSDpFvOKHqoc6Q-PCYpaAEnT6vu_JBAy236s=.851988b1-fd21-4733-a675-b5a049923741@github.com>

On Mon, 12 Jun 2023 14:09:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
>> 
>> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
>> 
>> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.
>
> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Whitespace
>  - Use RunWith in base Thread class & enable testing without VM Continuations.

src/java.base/share/classes/java/lang/ThreadBuilders.java line 436:

> 434:             if (Thread.currentThread() == this && !runInvoked) {
> 435:                 runInvoked = true;
> 436:                 Object bindings = scopedValueBindings();

Would it be possible to make this Thread.scopedValueBindings() to make it more obvious that it's a static method. Maybe the same in VirtualThread.run.

src/java.base/share/classes/java/lang/VirtualThread.java line 27:

> 25: package java.lang;
> 26: 
> 27: import java.lang.ref.Reference;

I think the import of ForceInline can be removed too.

test/jdk/ProblemList-Virtual.txt line 48:

> 46: 
> 47: java/lang/ScopedValue/StressStackOverflow.java 8309646 generic-all
> 48: 

That's the issue for the JTREG_TEST_THREAD_FACTORY=Virtual runs. I think we need to leave it excluded until that issue is diagnosed/fixed. 

However, in jdk/test/ProblemList.txt, it is excluded on linux-s390x as that platform doesn't seem to have, or use, VM continuations and so is using the fallback/alternative implementation. I think this entry can be removed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14399#discussion_r1226766408
PR Review Comment: https://git.openjdk.org/jdk/pull/14399#discussion_r1226767359
PR Review Comment: https://git.openjdk.org/jdk/pull/14399#discussion_r1226764146

From dfuchs at openjdk.org  Mon Jun 12 14:37:41 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:37:41 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

One thing though - WeakHashMap is not thread safe - and I don't see any locks or synchronized to protect access to CACHE. Is that going to cause trouble if two threads compete to add a locale to the map? In other words - how confident are we that the race would be benign?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475096535

From dfuchs at openjdk.org  Mon Jun 12 14:40:43 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:40:43 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <nw4cq4eBoIjvhodXS-V3HULh5PrdMx6EaG31daNumdw=.05dc657b-3a90-4394-85cd-fff2445d2fb8@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

I think this question should be answered before integrating.

-------------

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475101795

From pminborg at openjdk.org  Mon Jun 12 14:41:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Jun 2023 14:41:22 GMT
Subject: RFR: 8295555: Primitive wrapper caches could be `@Stable`
Message-ID: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>

This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).

Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

-------------

Commit messages:
 - Fix trailing white spaces
 - Reinsert row
 - Annotate CharacterCache @Stable
 - Mark caching arrays @Stable

Changes: https://git.openjdk.org/jdk/pull/14418/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14418&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295555
  Stats: 16 lines in 5 files changed: 11 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14418.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14418/head:pull/14418

PR: https://git.openjdk.org/jdk/pull/14418

From pminborg at openjdk.org  Mon Jun 12 14:41:23 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 12 Jun 2023 14:41:23 GMT
Subject: RFR: 8295555: Primitive wrapper caches could be `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <UTzoXtmaBegvSw8rem61WqS-aywYHUIq9U6rNN9Qua4=.e6a4e9be-0234-412c-88df-cce16e10ab8c@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

The performance is similar with this PR compared to the base line:

Before:

Benchmark         (size)  Mode  Cnt  Score   Error  Units
Integers.valueOf     500  avgt   15  0.652 ? 0.003  ns/op


After

Benchmark         (size)  Mode  Cnt  Score   Error  Units
Integers.valueOf     500  avgt   15  0.649 ? 0.003  ns/op



    @State(Scope.Thread)
    public static class Data {
       int value = 42;
    }
    
    ...
    
    @Benchmark
    public void valueOf(Data data, Blackhole bh) {
        bh.consume(Integer.valueOf(data.value));
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14418#issuecomment-1587463431

From jpai at openjdk.org  Mon Jun 12 14:45:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 12 Jun 2023 14:45:09 GMT
Subject: RFR: 8309763: Move tests in test/jdk/sun/misc/URLClassPath directory
 to test/jdk/jdk/internal/loader
Message-ID: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>

Can I please get a review of this test-only change which moves the tests from under `test/jdk/sun/misc/URLClassPath` to `test/jdk/jdk/internal/loader/URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8309763.

As noted in that issue, in Java 9, the `sun.misc.URLClassPath` was moved to `jdk.internal.loader.URLClassPath`. These are some pre-existing tests which are now being moved to this more relevant location.

I've checked that none of the problem list files have this `sun/misc/URLClassPath` directory problem listed. Additionally, I have verified that `sun/misc/URLClassPath` and `jdk/internal/loader` both belong to the same test group (`jdk_lang` which belongs to `tier1`) and as such this refactoring won't impact the test grouping.

tier1 testing with this change has passed.

-------------

Commit messages:
 - 8309763: Move tests in test/jdk/sun/misc/URLClassPath directory to test/jdk/jdk/internal/loader

Changes: https://git.openjdk.org/jdk/pull/14415/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14415&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309763
  Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14415.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14415/head:pull/14415

PR: https://git.openjdk.org/jdk/pull/14415

From dfuchs at openjdk.org  Mon Jun 12 14:47:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 14:47:49 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <TvCCsF7rNR6_d0nbr9wgFtGzNyq-Ti4BxE9c6kljUz8=.a31f88ea-3a71-4423-bf9b-96c66ca5580f@github.com>
Message-ID: <IIbDWS7D9Utzs38_5cnY4pjte1NvtI-u9LJ1bFLnrTY=.0d5f3a99-546c-4bc7-a219-f6db77493b79@github.com>

On Mon, 12 Jun 2023 14:26:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The main change is that base locales will now be cached using WeakReference rather than SoftReference, and thus probably collected more eagerly, but that actually looks like a positive change.

Hmm.... or not. Nothing references the key, so the binding would be immediately eligible for garbage collection.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587493993

From jvernee at openjdk.org  Mon Jun 12 14:49:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 12 Jun 2023 14:49:13 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
References: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
Message-ID: <LdlBDhpSk3KgVd_5vlq4Lg3M0HM-AuGLQm-34e0tiXc=.0b534699-d6d0-41ae-91cd-a56e2e4c0633@github.com>

On Mon, 12 Jun 2023 11:01:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is the same PR as https://github.com/openjdk/jdk/pull/14098, but backported to the JDK 21 repo fork.

Btw, besides the other 2 issues this solves (from the other PR), I think this also solves: https://bugs.openjdk.org/browse/JDK-8255350

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/7#issuecomment-1587495022

From liach at openjdk.org  Mon Jun 12 14:54:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 14:54:51 GMT
Subject: RFR: 8295555: Primitive wrapper caches could be `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <TGxcnUj9RbMmCL2ZbnoOy5O5_BqVHK_0lch3qKNFIdw=.9998ac2d-7d2d-4cb5-9030-969fa8764c68@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

Seems the `valueOf` APIs already have `@IntrinsicCandidate` and might have some custom logic in C2 or other jit compilers, so there's no performance difference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14418#issuecomment-1587505610

From alanb at openjdk.org  Mon Jun 12 14:58:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Jun 2023 14:58:43 GMT
Subject: RFR: 8309763: Move tests in test/jdk/sun/misc/URLClassPath
 directory to test/jdk/jdk/internal/loader
In-Reply-To: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
References: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
Message-ID: <hvWBmo4AxEyw8mLYxwhM7K_SuuAGrIq8dFiHrm02cnc=.894fc87a-1406-467f-afb2-f1f93a05b360@github.com>

On Mon, 12 Jun 2023 11:30:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which moves the tests from under `test/jdk/sun/misc/URLClassPath` to `test/jdk/jdk/internal/loader/URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8309763.
> 
> As noted in that issue, in Java 9, the `sun.misc.URLClassPath` was moved to `jdk.internal.loader.URLClassPath`. These are some pre-existing tests which are now being moved to this more relevant location.
> 
> I've checked that none of the problem list files have this `sun/misc/URLClassPath` directory problem listed. Additionally, I have verified that `sun/misc/URLClassPath` and `jdk/internal/loader` both belong to the same test group (`jdk_lang` which belongs to `tier1`) and as such this refactoring won't impact the test grouping.
> 
> tier1 testing with this change has passed.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14415#pullrequestreview-1475141858

From kcr at openjdk.org  Mon Jun 12 15:00:13 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 15:00:13 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v6]
In-Reply-To: <St7TeBhD1chuQF3VsxLABKyMOC0Dbrvc-r1f691imgM=.030c5558-b3c1-43e9-a72b-0aa6912cbc27@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <Vsuf88ibaJ0trBF2u8MS1Lng5JtVvZHjK0z434S8mgs=.ba1db33f-f9d1-4a7e-a7de-aa191f4464bd@github.com>
 <St7TeBhD1chuQF3VsxLABKyMOC0Dbrvc-r1f691imgM=.030c5558-b3c1-43e9-a72b-0aa6912cbc27@github.com>
Message-ID: <7TiNtiqQfhkWOCFyJu3UoCuP2VEyQ2Q2OliO-TDvqXM=.f44fe2ce-63c7-4971-8e31-f50773e76199@github.com>

On Mon, 12 Jun 2023 10:29:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Merge branch 'master' into javadoc_fixes
>>  - Fix issue with ArithmeticException not being wrapped in IAE for SequenceLayout::withElementCount
>>    Fix issue with IAE thrown instead of UOE for ValueLayout::arrayElementVarHandle
>>    Add apiNote to MemorySegment::address re. reachability
>>  - Missed a review comment
>>  - Use more `{@return}` tags
>>  - Address review comments
>>  - Fix wrong link in layout well-formedness doc
>>  - Improve javadoc on supported linker layouts
>>  - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
>>  - Merge branch 'master' into javadoc_fixes
>>  - Add overflow tests
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/01455a07...b59edd93
>
> Closing, as the review is complete and I have to rebase against the forked 21 repo. A similar PR will pop up soon :-)

@mcimadamore Is there a reason that this shouldn't be integrated into the mainline?? Absent a compelling reason, fixes should be integrated first into the mainline (for 22) and then backported to 21.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1587513641

From rriggs at openjdk.org  Mon Jun 12 15:06:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 15:06:50 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
References: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
Message-ID: <TwLE9otg3q5G67Ue16w1NQLPC33StyiFE8_REKY6MKc=.9330667a-4e78-450b-85c0-4ff7a7024610@github.com>

On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/3#pullrequestreview-1475160793

From chegar at openjdk.org  Mon Jun 12 15:06:51 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 12 Jun 2023 15:06:51 GMT
Subject: RFR: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
References: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
Message-ID: <YuV9jj3yPjZFWtppY4yid0_S_IZE3mFrpKLLqoIIqh8=.23206a28-52c3-4671-b1e6-443e0e2b8f3c@github.com>

On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.
> 
> Thanks!

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/3#issuecomment-1587529121

From chegar at openjdk.org  Mon Jun 12 15:10:54 2023
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 12 Jun 2023 15:10:54 GMT
Subject: Integrated: 8309727: Assert privileges while reading the
 jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property
In-Reply-To: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
References: <vH8nD7K6CGSaTykn-XU-rhwA-yHbHDLyFVgpDx4kni0=.e9a50428-a6a6-4bca-b8ba-2f7a78c8b856@github.com>
Message-ID: <6SGmJc8iUiwGXY0EKOXimevU5aUTmtvmK4ijmRTDxBo=.9f27dc2a-9929-4f6e-83d8-e2f3918156d9@github.com>

On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Hegarty on 9 Jun 2023 and was reviewed by Roger Riggs, Uwe Schindler and Paul Sandoz.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 73a9f486
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/73a9f486ae36510de1ff462a45d6e88301bd92d5
Stats:     10 lines in 3 files changed: 7 ins; 0 del; 3 mod

8309727: Assert privileges while reading the jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK system property

Reviewed-by: uschindler, rriggs
Backport-of: cee5724d09b9ef9bd528fb721b756cb052265e3d

-------------

PR: https://git.openjdk.org/jdk21/pull/3

From mcimadamore at openjdk.org  Mon Jun 12 15:27:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 15:27:10 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v6]
In-Reply-To: <St7TeBhD1chuQF3VsxLABKyMOC0Dbrvc-r1f691imgM=.030c5558-b3c1-43e9-a72b-0aa6912cbc27@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <Vsuf88ibaJ0trBF2u8MS1Lng5JtVvZHjK0z434S8mgs=.ba1db33f-f9d1-4a7e-a7de-aa191f4464bd@github.com>
 <St7TeBhD1chuQF3VsxLABKyMOC0Dbrvc-r1f691imgM=.030c5558-b3c1-43e9-a72b-0aa6912cbc27@github.com>
Message-ID: <8tw_GyRo93aDM81tYOyjjlD4DX08-vnww0tx8O4j3kI=.ed2ac218-9b79-4485-bff9-fd4f59a2789a@github.com>

On Mon, 12 Jun 2023 10:29:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Merge branch 'master' into javadoc_fixes
>>  - Fix issue with ArithmeticException not being wrapped in IAE for SequenceLayout::withElementCount
>>    Fix issue with IAE thrown instead of UOE for ValueLayout::arrayElementVarHandle
>>    Add apiNote to MemorySegment::address re. reachability
>>  - Missed a review comment
>>  - Use more `{@return}` tags
>>  - Address review comments
>>  - Fix wrong link in layout well-formedness doc
>>  - Improve javadoc on supported linker layouts
>>  - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
>>  - Merge branch 'master' into javadoc_fixes
>>  - Add overflow tests
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/01455a07...b59edd93
>
> Closing, as the review is complete and I have to rebase against the forked 21 repo. A similar PR will pop up soon :-)

> @mcimadamore Is there a reason that this shouldn't be integrated into the mainline?? Absent a compelling reason, fixes should be integrated first into the mainline (for 22) and then backported to 21.

This fix was targeting 21 - but then the repo has forked. It is my understanding that fixes applied to the 21 fork will be forward-ported to 22 automatically.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1587564381

From mcimadamore at openjdk.org  Mon Jun 12 15:27:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 15:27:59 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <LdlBDhpSk3KgVd_5vlq4Lg3M0HM-AuGLQm-34e0tiXc=.0b534699-d6d0-41ae-91cd-a56e2e4c0633@github.com>
References: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
 <LdlBDhpSk3KgVd_5vlq4Lg3M0HM-AuGLQm-34e0tiXc=.0b534699-d6d0-41ae-91cd-a56e2e4c0633@github.com>
Message-ID: <NFdANQgqLTraXeKkNWzOmoeFL9jiuVUl_GgMLbbHGtI=.1dfaaf0d-3550-417a-a29c-e16310188f02@github.com>

On Mon, 12 Jun 2023 14:45:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Btw, besides the other 2 issues this solves (from the other PR), I think this also solves: https://bugs.openjdk.org/browse/JDK-8255350

Thanks for the reminder - JDK-8255350 is not fixed by this, but by https://git.openjdk.org/jdk/pull/14007

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/7#issuecomment-1587557299

From kcr at openjdk.org  Mon Jun 12 15:28:00 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 15:28:00 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <NFdANQgqLTraXeKkNWzOmoeFL9jiuVUl_GgMLbbHGtI=.1dfaaf0d-3550-417a-a29c-e16310188f02@github.com>
References: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
 <LdlBDhpSk3KgVd_5vlq4Lg3M0HM-AuGLQm-34e0tiXc=.0b534699-d6d0-41ae-91cd-a56e2e4c0633@github.com>
 <NFdANQgqLTraXeKkNWzOmoeFL9jiuVUl_GgMLbbHGtI=.1dfaaf0d-3550-417a-a29c-e16310188f02@github.com>
Message-ID: <cXCgT2DNxDjtpI_gEKcXsk0krBd-k92WDYsr_ZOp7DM=.e6cad299-d197-443d-923d-2dd0617c78c3@github.com>

On Mon, 12 Jun 2023 15:19:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Btw, besides the other 2 issues this solves (from the other PR), I think this also solves: https://bugs.openjdk.org/browse/JDK-8255350
>
>> Btw, besides the other 2 issues this solves (from the other PR), I think this also solves: https://bugs.openjdk.org/browse/JDK-8255350
> 
> Thanks for the reminder - JDK-8255350 is not fixed by this, but by https://git.openjdk.org/jdk/pull/14007

@mcimadamore Shouldn't this go into the mainline first?

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/7#issuecomment-1587561904

From mcimadamore at openjdk.org  Mon Jun 12 15:28:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 15:28:01 GMT
Subject: Integrated: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
References: <8jlsRVooklpbYO8C20SzQ1Huqi3qBzxTxs5MUQ6B9h0=.060f4895-6e37-4584-9c15-9901d88d64aa@github.com>
Message-ID: <us7T6-Y-QyEhZ9nnEr_seGqBLmyXZtJEHv6D1lUTTQs=.42fb3d38-0efa-4100-9c78-fa904103ecf3@github.com>

On Mon, 12 Jun 2023 11:01:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is the same PR as https://github.com/openjdk/jdk/pull/14098, but backported to the JDK 21 repo fork.

This pull request has now been integrated.

Changeset: 20371fd9
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/20371fd918124451a068cb9647deebba7c9b4cba
Stats:     964 lines in 28 files changed: 357 ins; 138 del; 469 mod

8308645: Javadoc of FFM API needs to be refreshed
8309398: ValueLayout:: arrayElementVarHandle doesn't throws UnsupportedOperationException - if byteAlignment() > byteSize()
8308812: SequenceLayout::withElementCount(long elementCount) doesn't throw IllegalArgumentException - if elementCount < 0 for some cases

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk21/pull/7

From asotona at openjdk.org  Mon Jun 12 15:34:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Jun 2023 15:34:06 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v13]
In-Reply-To: <WVxhI78Zmqpf6nWEUjjjSmc0pTDCXQ4jP7EVDawuJqg=.cd623a45-bd58-4ffc-8037-08159ad52bc7@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <WVxhI78Zmqpf6nWEUjjjSmc0pTDCXQ4jP7EVDawuJqg=.cd623a45-bd58-4ffc-8037-08159ad52bc7@github.com>
Message-ID: <TyV0mIE2kay3vvly70fLLubjmqdiXbYzaBKX2B9TZLs=.1cda6ce9-3fa2-40e5-8216-2ce66c478519@github.com>

On Mon, 12 Jun 2023 11:20:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>    esolver.java
>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>    
>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.

I've fixed stack map generator dispatching code and reverted the cache-related changes to focus on performance regression caused by the Classfile context introduction and unfortunately it is still there.
Affected by at least 12% regression are all code transformations, with the worst case AdHocAdapt.transform LIFT2 (22% regression).
Detailed profiling shows regressions in self-time spent in code transformation lambda calls, for example `ChainedCodeBuilder::with` only calls `consumer.accept` and in ~30s benchmark it spent 2s in self-time (which is half of the whole regression).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1587575761

From never at openjdk.org  Mon Jun 12 15:36:04 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 12 Jun 2023 15:36:04 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v4]
In-Reply-To: <bTOmklozZb9KZQ3UGhvqINCpD45kR59QHwIGe61Yqvs=.bb62a33f-f5d2-4830-bb0d-13ee806904ad@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <bTOmklozZb9KZQ3UGhvqINCpD45kR59QHwIGe61Yqvs=.bb62a33f-f5d2-4830-bb0d-13ee806904ad@github.com>
Message-ID: <f3GURANwZaHDuTIJSH8xBhxHu0oDOUs2NocVOrnyzlk=.7f9933b4-c411-46e2-861b-09cc14bf4e32@github.com>

On Mon, 12 Jun 2023 09:21:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
>> 
>> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
>> 
>> ## Times
>> 
>> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
>> 
>> 
>> public class Nop {
>>     public static void main(String[] args) {}
>> }
>> 
>> 
>> (1) Baseline (no options):
>> 
>>> for i in (seq 10); java Nop; end
>>         0.05 real         0.04 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.00 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>> 
>> 
>> (2) Eagerly initialize libgraal (with PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.06 real         0.04 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>> 
>> 
>> (3) Eagerly initialize libgraal (without PR):
>> 
>>> for i in (seq 10...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduced complexity of SystemProperties based on it being unmodifiable

Marked as reviewed by never (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14291#pullrequestreview-1475218767

From never at openjdk.org  Mon Jun 12 15:36:06 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 12 Jun 2023 15:36:06 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v3]
In-Reply-To: <xsOOrlJZCbziwqp7_bzu3dSVXRKPjlXGCYvkzcsv9uQ=.784266e2-e546-4115-be07-9d3b0ef3bd7d@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <kiL-2LqTUkcx0n5lOJzwdTmvaxyTlh3pw6v4r-iBh98=.d5aaef2b-4092-48cf-99db-dd7df9a1fbeb@github.com>
 <J1ZtgxnE1Xy3DfrXEIWWCTRh96WMPwdxaB8yqRhmqAE=.fccae795-8ef8-4770-8d69-fc376cd4a981@github.com>
 <xsOOrlJZCbziwqp7_bzu3dSVXRKPjlXGCYvkzcsv9uQ=.784266e2-e546-4115-be07-9d3b0ef3bd7d@github.com>
Message-ID: <QeC3FjDZLdAn8fXDd5GqWhrZIv3O98RHwi2G6CM5ank=.7ab5fd50-cce8-45c7-acf9-f973b835bca9@github.com>

On Mon, 12 Jun 2023 09:20:09 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java line 314:
>> 
>>> 312:             String key = toJavaString(unsafe, unsafe.getLong(prop + keyOffset));
>>> 313:             long valueAddress = unsafe.getLong(prop + valueOffset);
>>> 314:             if (valueAddress != 0) {
>> 
>> Is the lazy value construction really necessary?  It seems like it requires quite a bit of extra machinery.
>
> In big apps, I image there can be quite some large system property values (e.g. `java.class.path`) so we don't want to pay memory overhead per libgraal isolate for such properties as they're ignored by libgraal.
> 
> I realized I can reduce the extra machinery based on the fact that `SystemProperties` is unmodifiable: https://github.com/openjdk/jdk/pull/14291/commits/6c346d35923402fb5d6ae0ef83214f8f0ca07b69
> The only method that still eager converts the string is `SystemProperties.values()` but that's fine as it's not used by JVMCI or Graal.
> I think the trade off is now acceptable?

Yes I like this trade off a bit better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14291#discussion_r1226857200

From mcimadamore at openjdk.org  Mon Jun 12 15:54:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 15:54:00 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v7]
In-Reply-To: <fwmQcmgtrm0n_UI4h90UTs1ZYI570asx-oKzIqeK3Kg=.0b272521-06b7-4618-845c-e538de7e6ddb@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <fwmQcmgtrm0n_UI4h90UTs1ZYI570asx-oKzIqeK3Kg=.0b272521-06b7-4618-845c-e538de7e6ddb@github.com>
Message-ID: <wGmrHJ2sImtTCROl33vLxY3yBKJsLbzP815hu6T5XUg=.920ec8a2-c1d2-4c37-b698-1590d329c818@github.com>

On Mon, 12 Jun 2023 10:33:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' into javadoc_fixes
>  - Fix implementation for byteOffsetHandle to accept ranged open paths.
>  - Merge branch 'master' into javadoc_fixes
>  - Fix issue with ArithmeticException not being wrapped in IAE for SequenceLayout::withElementCount
>    Fix issue with IAE thrown instead of UOE for ValueLayout::arrayElementVarHandle
>    Add apiNote to MemorySegment::address re. reachability
>  - Missed a review comment
>  - Use more `{@return}` tags
>  - Address review comments
>  - Fix wrong link in layout well-formedness doc
>  - Improve javadoc on supported linker layouts
>  - Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/268ec61d...78f7bd24

Re-opening - as per new policies, changes will NOT be automatically forward ported (see [1]), so we need a separate PR for 22.

[1] - https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1587608037

From asotona at openjdk.org  Mon Jun 12 15:55:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 12 Jun 2023 15:55:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> 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 38 commits:

 - Merge branch 'master' into JDK-8308899-context
 - Revert of DirectCodeBuilder.needsStackMap pre-calculation
 - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
   esolver.java
 - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
   
   This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
 - fixed StackMapsOption dispatching in DirectCodeBuilder
 - proposed semi-synchronized caching, where the map is not locked during delegate call
 - used Factory.INSTANCE for system ClassHierarchyResolver cache
 - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
   
   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
 - ClassHierarchyResolver::ofSystem is now thread-unsafe
 - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
   introduction of ClassHierarchyResolver::ofSystem factory method
   ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
 - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e

-------------

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=13
  Stats: 1681 lines in 106 files changed: 536 ins; 245 del; 900 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From mcimadamore at openjdk.org  Mon Jun 12 15:59:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 12 Jun 2023 15:59:05 GMT
Subject: Integrated: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <TkwJmXwJEKT1XD5JBoTjCmpLRkLqPspkUC1eVHAO200=.1d58d492-2adf-4c46-83ea-44769be7c5fe@github.com>

On Tue, 23 May 2023 11:48:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an overflow during ...

This pull request has now been integrated.

Changeset: a6ad42e0
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6ad42e00eaa1c1a476df9fac399f16de53a7a8b
Stats:     964 lines in 28 files changed: 357 ins; 138 del; 469 mod

8308645: Javadoc of FFM API needs to be refreshed
8309398: ValueLayout:: arrayElementVarHandle doesn't throws UnsupportedOperationException - if byteAlignment() > byteSize()
8308812: SequenceLayout::withElementCount(long elementCount) doesn't throw IllegalArgumentException - if elementCount < 0 for some cases

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/14098

From rriggs at openjdk.org  Mon Jun 12 16:02:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 16:02:41 GMT
Subject: RFR: 8295555: Primitive wrapper caches could be `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <S64hov6EWfwmY4ICCmdkXMEKwHgpt_v5k4uWsEvMaQQ=.677da9cc-2d6c-4c3c-904c-fed3d7305dcf@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14418#pullrequestreview-1475272046

From jiangli at openjdk.org  Mon Jun 12 16:25:50 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 12 Jun 2023 16:25:50 GMT
Subject: Integrated: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <LFF7yUAdSpOi9weD_xfrHJGO2ugT7R7xTV9fNsU2x5k=.c8d923ae-5bfd-474e-ab88-b5a07a4f14f8@github.com>

On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

This pull request has now been integrated.

Changeset: 45414fc2
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45414fc2dfa41cbbfc6de7fec15eb47f41cf8986
Stats:     224 lines in 10 files changed: 173 ins; 34 del; 17 mod

8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

Co-authored-by: Erik Joelsson <erikj at openjdk.org>
Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/14064

From rriggs at openjdk.org  Mon Jun 12 16:26:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 16:26:43 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

One other thing to consider...
If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced.
Eliminating `.intern90` would make creating a normalized BaseLocale faster.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587662100

From mchung at openjdk.org  Mon Jun 12 16:49:49 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Jun 2023 16:49:49 GMT
Subject: RFR: 8309763: Move tests in test/jdk/sun/misc/URLClassPath
 directory to test/jdk/jdk/internal/loader
In-Reply-To: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
References: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
Message-ID: <su-bNtt3E3M5Xszhfqy0XG9bmgYkAQ-92tXZS7n82X8=.ecffeed0-0ab1-455a-8186-307e4a2fbd70@github.com>

On Mon, 12 Jun 2023 11:30:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which moves the tests from under `test/jdk/sun/misc/URLClassPath` to `test/jdk/jdk/internal/loader/URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8309763.
> 
> As noted in that issue, in Java 9, the `sun.misc.URLClassPath` was moved to `jdk.internal.loader.URLClassPath`. These are some pre-existing tests which are now being moved to this more relevant location.
> 
> I've checked that none of the problem list files have this `sun/misc/URLClassPath` directory problem listed. Additionally, I have verified that `sun/misc/URLClassPath` and `jdk/internal/loader` both belong to the same test group (`jdk_lang` which belongs to `tier1`) and as such this refactoring won't impact the test grouping.
> 
> tier1 testing with this change has passed.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14415#pullrequestreview-1475368862

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressing comments (test grouping, synchronization), minor optimization on loop lookup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/06d199dc..fb1535ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=00-01

  Stats: 55 lines in 2 files changed: 16 ins; 14 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <lTt_W4Ue-TJX0DRm890f_iScI2Wo902VXROCVIq2VTk=.794888d9-6019-4d7c-bbe0-46d41427e8aa@github.com>
Message-ID: <g2oOmzsd58gopPKyf3NS12-XXfcX9naws8Q6_1dNj7Q=.2ded240e-49bb-4b2b-a38e-11108db25cdb@github.com>

On Mon, 12 Jun 2023 14:35:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> One thing though - WeakHashMap is not thread safe - and I don't see any locks or synchronized to protect access to CACHE. Is that going to cause trouble if two threads compete to add a locale to the map? In other words - how confident are we that the race would be benign?

Although I think the possible race is benign (it would simply overwrite the existing normalized one), I put it in a synchronization block as a safety measure, as the race would be quite rare for creating a BaseLocale instance. Tested with the microbench mark and I didn't see the number change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587759179

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale
In-Reply-To: <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
Message-ID: <pw8M2rDyrS5DSt4Hxk7poIQ5pL6c9ZJKuL49-6DaWOQ=.e11e348f-7beb-4c1a-ab03-56e819893530@github.com>

On Mon, 12 Jun 2023 16:23:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> One other thing to consider... If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced. Eliminating `.intern90` would make creating a normalized BaseLocale faster.

Some code inside the Locale still relies on `intern` and do `==` comparison. Yes, it would be faster but I think that would be out of the scope of this fix

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1587760602

From naoto at openjdk.org  Mon Jun 12 17:33:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 12 Jun 2023 17:33:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <kY1A9vDf0wGk8SfYMgmE6en_3IICLsUpeNHuZUdOyRg=.74f0261d-ab5f-4624-8815-b6f770bb6f99@github.com>
Message-ID: <7znWt-HGeAbK4ngG1xgIas71tNbe3yUHhPCz5sR42_Y=.24d27c62-2d80-4b70-b0b9-3d178902fed1@github.com>

On Mon, 12 Jun 2023 12:49:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> test/hotspot/jtreg/gc/TestAllocHumongousFragment.java line 180:
> 
>> 178:  */
>> 179: 
>> 180: /*
> 
> Could you move this block a few lines above (e.g. next to the block of `id=iu-aggressive`) so that similar tests are grouped together?

Moved the block next to `iu-aggressive`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1227009171

From kvn at openjdk.org  Mon Jun 12 17:42:43 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 12 Jun 2023 17:42:43 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v4]
In-Reply-To: <bTOmklozZb9KZQ3UGhvqINCpD45kR59QHwIGe61Yqvs=.bb62a33f-f5d2-4830-bb0d-13ee806904ad@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <bTOmklozZb9KZQ3UGhvqINCpD45kR59QHwIGe61Yqvs=.bb62a33f-f5d2-4830-bb0d-13ee806904ad@github.com>
Message-ID: <kF9Q9PU6fytI3V30TZBStIN-QpUc_l1hNmlqqCZwNCo=.558b6236-c8b1-4eb0-af11-77a19ed67e04@github.com>

On Mon, 12 Jun 2023 09:21:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
>> 
>> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
>> 
>> ## Times
>> 
>> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
>> 
>> 
>> public class Nop {
>>     public static void main(String[] args) {}
>> }
>> 
>> 
>> (1) Baseline (no options):
>> 
>>> for i in (seq 10); java Nop; end
>>         0.05 real         0.04 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.00 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>> 
>> 
>> (2) Eagerly initialize libgraal (with PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.06 real         0.04 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>> 
>> 
>> (3) Eagerly initialize libgraal (without PR):
>> 
>>> for i in (seq 10...
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduced complexity of SystemProperties based on it being unmodifiable

VM changes seems fine. They are JVMCI specific.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14291#pullrequestreview-1475480087

From duke at openjdk.org  Mon Jun 12 17:59:12 2023
From: duke at openjdk.org (duke)
Date: Mon, 12 Jun 2023 17:59:12 GMT
Subject: Withdrawn: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <B47suQ-1_XUTr22InIeSbc65c45vtVn8ZxAoALq0mdA=.0f7d7996-a97d-4931-a6b7-b02dacaea4c2@github.com>

On Thu, 10 Nov 2022 06:20:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11081

From rriggs at openjdk.org  Mon Jun 12 18:01:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 12 Jun 2023 18:01:41 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <iFgRoswGUmuBpFa2RgYwZgAq7kWZM-xqY6g8TKZWvKw=.84ffd8ee-76d6-46af-a185-2f7419440d9e@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14386#pullrequestreview-1475510244

From duke at openjdk.org  Mon Jun 12 18:30:03 2023
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 12 Jun 2023 18:30:03 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v21]
In-Reply-To: <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>
Message-ID: <z15aOf0GLkK191CxHUuMurKsg95h4D_WxIoNjm7BRnU=.177d270b-dd53-449c-840f-6aba0001b776@github.com>

On Mon, 15 May 2023 15:51:02 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick 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 remote-tracking branch 'upstream/master' into patch-1
>  - Merge remote-tracking branch 'origin/patch-1' into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' into patch-1
>  - Update copyright date in RandomNext.java
>  - Update copyright date in RandomGeneratorNext.java
>  - Update copyright date in RandomGeneratorExponentialGaussian.java
>  - Update copyright date in RandomSupport.java
>  - Optimize: move some code out of the fast path
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/97b2ca3d...1b5656d7

@turbanoff @rgiulietti  Keep open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1587859196

From dnsimon at openjdk.org  Mon Jun 12 18:55:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 12 Jun 2023 18:55:42 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v5]
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <ol8KjpE9i7qCY282NEdFMjkgB_toYB8Xxai4lJpQFYc=.d59bcf00-02c0-4474-a868-0df1d2201628@github.com>

> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
> 
> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         ...

Doug Simon has updated the pull request with a new target base 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:

 - [skip-ci] Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8309390
 - [skip-ci] remove debug code
 - fix copyright dates
 - fix reference in comments
 - reduced complexity of SystemProperties based on it being unmodifiable
 - copy system properties into libgraal more efficiently

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14291/files
  - new: https://git.openjdk.org/jdk/pull/14291/files/6c346d35..15a07e98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14291&range=03-04

  Stats: 3104 lines in 166 files changed: 1842 ins; 420 del; 842 mod
  Patch: https://git.openjdk.org/jdk/pull/14291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14291/head:pull/14291

PR: https://git.openjdk.org/jdk/pull/14291

From dfuchs at openjdk.org  Mon Jun 12 19:03:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Jun 2023 19:03:44 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <Jvmfztugmp9z0ePb3HyHZw8n4I2xnfFZK1A2JxOpEWY=.1b9b1ab5-643c-4a91-a67b-9d0b9f93f776@github.com>

On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

LGTM

FWIW I am not sure the race would have been benign - as `put` is not atomic - so I wouldn't be surprised if concurrent `put`s  could have resulted in an inconsistent internal state for the `WeakHashMap`.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1475620449

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

-------------

Commit messages:
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk21/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <-g_p5DXIJa2iFx-wYX9Fl024cy_wOxNlIN3g8TB5V1E=.84d95609-9341-4a50-afa2-e9dcb462a0bb@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540

From jlu at openjdk.org  Mon Jun 12 21:29:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:29:54 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775

From kcr at openjdk.org  Mon Jun 12 21:45:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 21:45:55 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
Message-ID: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>

On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

@justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.

See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416

From jlu at openjdk.org  Mon Jun 12 21:55:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:55:48 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
 <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
Message-ID: <ZVzi-lqSlf4r01XSuWXwqs8_Ku3uEGgB_f2BRDOqsvQ=.9c38d799-5e1e-4ec7-8f74-81a9603cde4d@github.com>

On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.
>
> @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.
> 
> See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

@kevinrushforth Thanks for the reminder, will make the change in ML first.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115

From jlu at openjdk.org  Mon Jun 12 22:07:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:07:11 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

-------------

Commit messages:
 - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk/pull/14430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Mon Jun 12 22:16:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:16:50 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <sLPcMLisa0Fflyr2kNxtrP3t6X2r7TFh7K59biOLnuw=.cb69b335-cac4-4565-9587-93d4abfae7ed@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092

From duke at openjdk.org  Mon Jun 12 22:20:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 12 Jun 2023 22:20:53 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227296089

From jlu at openjdk.org  Mon Jun 12 22:32:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Revert 'main.help.opt.any.file' value for _de

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Mon Jun 12 22:32:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:34 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
Message-ID: <QG0atcb6MH7fn3CaUG7kFAU8Z-0dx0lvt8vPPzz6fD4=.750f4a45-f895-49f6-becd-7d9e6c994207@github.com>

On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:
> 
>> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
>> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
>> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)
> 
> This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807

From mchung at openjdk.org  Mon Jun 12 22:57:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Jun 2023 22:57:52 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
In-Reply-To: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
References: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
Message-ID: <t1CAwmCNZ2PVjvjwfybAS0-cY9mtxmku6KQFXeVP9zM=.0a7b0b9a-fd99-47ce-9f61-71f32984e9f8@github.com>

On Mon, 12 Jun 2023 05:27:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes the NPE in IndirectVarHandle.isAccessModeSupported by delegating to the target var handle. In addition, simplified the MH caching in Indirect VH and removed redundant overrides (already available via var form). This was split from #13821 as suggested by Mandy Chung, which allows easy backports to release 21 if desirable.

The fix looks good.  Also nice clean up.

test/jdk/java/lang/invoke/VarHandles/IndirectVarHandleTest.java line 28:

> 26:  * @summary tests for IndirectVarHandle
> 27:  * @compile --enable-preview --release 22 IndirectVarHandleTest.java
> 28:  * @run junit/othervm --enable-preview IndirectVarHandleTest

Suggestion:

 * @enablePreview
 * @run junit IndirectVarHandleTest
 * @summary Test VarHandle::isAccessModeSupported on indirect VarHandle produced by MethodHandles.filterCoordinates


Should simply use jtreg `@enablePreview`.    Suggest to move `@summary` to the end and also can be more specific.

test/jdk/java/lang/invoke/VarHandles/IndirectVarHandleTest.java line 44:

> 42:         var lookup = MethodHandles.lookup();
> 43:         var intArrayVh = MethodHandles.arrayElementVarHandle(int[].class);
> 44:         var addOne = lookup.bind((IntUnaryOperator) a -> a + 1, "applyAsInt", MethodType.methodType(int.class, int.class));

Nit: a couple of long lines (L44, 48 and 55) can be wrapped into separate line.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14409#pullrequestreview-1475930012
PR Review Comment: https://git.openjdk.org/jdk/pull/14409#discussion_r1227316722
PR Review Comment: https://git.openjdk.org/jdk/pull/14409#discussion_r1227319788

From liach at openjdk.org  Mon Jun 12 23:13:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 23:13:10 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
 [v2]
In-Reply-To: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
References: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
Message-ID: <4REKFtwhkURIKKKt3_f-nDHomW1jsqN57dKYffj2blo=.0ea6d040-1160-452b-8479-a1102b0952a9@github.com>

> Fixes the NPE in IndirectVarHandle.isAccessModeSupported by delegating to the target var handle. In addition, simplified the MH caching in Indirect VH and removed redundant overrides (already available via var form). This was split from #13821 as suggested by Mandy Chung, which allows easy backports to release 21 if desirable.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/invoke/VarHandles/IndirectVarHandleTest.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14409/files
  - new: https://git.openjdk.org/jdk/pull/14409/files/3b35edc1..ea7b78c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14409&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14409&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14409/head:pull/14409

PR: https://git.openjdk.org/jdk/pull/14409

From liach at openjdk.org  Mon Jun 12 23:23:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 23:23:09 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
 [v3]
In-Reply-To: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
References: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
Message-ID: <i4NKs5qYT_5Cow8ViUBRdam2SwSIV8FYMRpgXKo_kx4=.ae10af58-dca9-45e9-b18f-f98dfb350b47@github.com>

> Fixes the NPE in IndirectVarHandle.isAccessModeSupported by delegating to the target var handle. In addition, simplified the MH caching in Indirect VH and removed redundant overrides (already available via var form). This was split from #13821 as suggested by Mandy Chung, which allows easy backports to release 21 if desirable.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Wrap lines that are too long

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14409/files
  - new: https://git.openjdk.org/jdk/pull/14409/files/ea7b78c8..e4719520

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14409&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14409&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14409.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14409/head:pull/14409

PR: https://git.openjdk.org/jdk/pull/14409

From liach at openjdk.org  Mon Jun 12 23:23:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 12 Jun 2023 23:23:09 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
 [v3]
In-Reply-To: <t1CAwmCNZ2PVjvjwfybAS0-cY9mtxmku6KQFXeVP9zM=.0a7b0b9a-fd99-47ce-9f61-71f32984e9f8@github.com>
References: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
 <t1CAwmCNZ2PVjvjwfybAS0-cY9mtxmku6KQFXeVP9zM=.0a7b0b9a-fd99-47ce-9f61-71f32984e9f8@github.com>
Message-ID: <0qwgpQGM_0FT53qFLFsiofycpF5YM6KQRdW8zsAZUCE=.3bc6eec1-63dd-40ec-a0f4-62b88efb5164@github.com>

On Mon, 12 Jun 2023 22:54:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap lines that are too long
>
> test/jdk/java/lang/invoke/VarHandles/IndirectVarHandleTest.java line 44:
> 
>> 42:         var lookup = MethodHandles.lookup();
>> 43:         var intArrayVh = MethodHandles.arrayElementVarHandle(int[].class);
>> 44:         var addOne = lookup.bind((IntUnaryOperator) a -> a + 1, "applyAsInt", MethodType.methodType(int.class, int.class));
> 
> Nit: a couple of long lines (L44, 48 and 55) can be wrapped into separate line.

Done in a second push. Also wrapped the summary line (which was too long) from your suggestion patch.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14409#discussion_r1227331984

From mchung at openjdk.org  Mon Jun 12 23:55:40 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 12 Jun 2023 23:55:40 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
 [v3]
In-Reply-To: <0qwgpQGM_0FT53qFLFsiofycpF5YM6KQRdW8zsAZUCE=.3bc6eec1-63dd-40ec-a0f4-62b88efb5164@github.com>
References: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
 <t1CAwmCNZ2PVjvjwfybAS0-cY9mtxmku6KQFXeVP9zM=.0a7b0b9a-fd99-47ce-9f61-71f32984e9f8@github.com>
 <0qwgpQGM_0FT53qFLFsiofycpF5YM6KQRdW8zsAZUCE=.3bc6eec1-63dd-40ec-a0f4-62b88efb5164@github.com>
Message-ID: <kPVZjdARpNuo7dOBtPy7GQ3BbOnlsLJu91Ef8vG_VcY=.5cdbab96-8076-4075-a3aa-91649baf6b51@github.com>

On Mon, 12 Jun 2023 23:17:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/VarHandles/IndirectVarHandleTest.java line 44:
>> 
>>> 42:         var lookup = MethodHandles.lookup();
>>> 43:         var intArrayVh = MethodHandles.arrayElementVarHandle(int[].class);
>>> 44:         var addOne = lookup.bind((IntUnaryOperator) a -> a + 1, "applyAsInt", MethodType.methodType(int.class, int.class));
>> 
>> Nit: a couple of long lines (L44, 48 and 55) can be wrapped into separate line.
>
> Done in a second push. Also wrapped the summary line (which was too long) from your suggestion patch.

Looks good.  thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14409#discussion_r1227349773

From smarks at openjdk.org  Tue Jun 13 00:10:03 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 00:10:03 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
Message-ID: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>

Make `putMode` be a transient field.

-------------

Commit messages:
 - 8309882: LinkedHashMap adds an errant serializable field

Changes: https://git.openjdk.org/jdk/pull/14433/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14433&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309882
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14433.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14433/head:pull/14433

PR: https://git.openjdk.org/jdk/pull/14433

From darcy at openjdk.org  Tue Jun 13 00:27:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 13 Jun 2023 00:27:56 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
References: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
Message-ID: <D1kw05vu4lGg_B_MUferMFWV8ioMeS2098NzPpgucVE=.f8ed35a3-02f8-41b1-82b5-376d7e481b74@github.com>

On Tue, 13 Jun 2023 00:03:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Make `putMode` be a transient field.

I skimmed the JDK-8266571: "Sequenced Collections" and didn't see any similar instances, but it would benefit from another look.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14433#pullrequestreview-1475997599

From bpb at openjdk.org  Tue Jun 13 00:31:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jun 2023 00:31:40 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
References: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
Message-ID: <nPXwyApRcZ07RXFxiNILOPcRmp7HLyhXeKsWp2JLKpA=.514a5e38-df06-4557-b1a9-1014a3be994f@github.com>

On Tue, 13 Jun 2023 00:03:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Make `putMode` be a transient field.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14433#pullrequestreview-1476004322

From jpai at openjdk.org  Tue Jun 13 00:58:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Jun 2023 00:58:06 GMT
Subject: RFR: 8309763: Move tests in test/jdk/sun/misc/URLClassPath
 directory to test/jdk/jdk/internal/loader
In-Reply-To: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
References: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
Message-ID: <hFSklqzND7hIEZtDQgozkNdQYbCiEj-frjQudvEJblE=.eb2a25a8-20e9-4047-8715-39f9dbd5adf1@github.com>

On Mon, 12 Jun 2023 11:30:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which moves the tests from under `test/jdk/sun/misc/URLClassPath` to `test/jdk/jdk/internal/loader/URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8309763.
> 
> As noted in that issue, in Java 9, the `sun.misc.URLClassPath` was moved to `jdk.internal.loader.URLClassPath`. These are some pre-existing tests which are now being moved to this more relevant location.
> 
> I've checked that none of the problem list files have this `sun/misc/URLClassPath` directory problem listed. Additionally, I have verified that `sun/misc/URLClassPath` and `jdk/internal/loader` both belong to the same test group (`jdk_lang` which belongs to `tier1`) and as such this refactoring won't impact the test grouping.
> 
> tier1 testing with this change has passed.

Thank you Alan and Mandy for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14415#issuecomment-1588335413

From jpai at openjdk.org  Tue Jun 13 00:58:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Jun 2023 00:58:06 GMT
Subject: Integrated: 8309763: Move tests in test/jdk/sun/misc/URLClassPath
 directory to test/jdk/jdk/internal/loader
In-Reply-To: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
References: <JlsA0sGS0oabIfSubMnzusGQJnqpTBuhq6RceXkb9lE=.31788daf-cc18-4a83-bb9f-4667d58a56c7@github.com>
Message-ID: <VPk-s0zMK0i5H32LyC-vui3mfoRmVLrCNhzzrX4hZs4=.9a15ceda-b0b5-4fe1-ab0f-f754f2c21384@github.com>

On Mon, 12 Jun 2023 11:30:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which moves the tests from under `test/jdk/sun/misc/URLClassPath` to `test/jdk/jdk/internal/loader/URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8309763.
> 
> As noted in that issue, in Java 9, the `sun.misc.URLClassPath` was moved to `jdk.internal.loader.URLClassPath`. These are some pre-existing tests which are now being moved to this more relevant location.
> 
> I've checked that none of the problem list files have this `sun/misc/URLClassPath` directory problem listed. Additionally, I have verified that `sun/misc/URLClassPath` and `jdk/internal/loader` both belong to the same test group (`jdk_lang` which belongs to `tier1`) and as such this refactoring won't impact the test grouping.
> 
> tier1 testing with this change has passed.

This pull request has now been integrated.

Changeset: 57fc9a3e
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57fc9a3e968cafe3b618a216630e703a39d5676e
Stats:     0 lines in 5 files changed: 0 ins; 0 del; 0 mod

8309763: Move tests in test/jdk/sun/misc/URLClassPath directory to test/jdk/jdk/internal/loader

Reviewed-by: alanb, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14415

From smarks at openjdk.org  Tue Jun 13 01:05:42 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 01:05:42 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
References: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
Message-ID: <sHzgIJlwWW2qvbEWNZ5KEFI4H-af9RD-7mdh1ZSrs5o=.9ed98b23-5fd9-4bd8-abaf-118f10070221@github.com>

On Tue, 13 Jun 2023 00:03:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Make `putMode` be a transient field.

I've been advised by @jddarcy to file a CSR for this, in order to track of serialization compatibility issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14433#issuecomment-1588346239

From jpai at openjdk.org  Tue Jun 13 05:43:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 13 Jun 2023 05:43:51 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
References: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
Message-ID: <8-5ce97ZsGlcOeuof1pPbRnYWZcUJsuAzbbRB7n_eT0=.66d7b063-ef4c-46b6-8f42-057b8a3b53cd@github.com>

On Tue, 13 Jun 2023 00:03:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Make `putMode` be a transient field.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14433#pullrequestreview-1476287791

From asotona at openjdk.org  Tue Jun 13 07:54:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 07:54:52 GMT
Subject: RFR: 8309838: Classfile API Util.toBinaryName and other cleanup
In-Reply-To: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
References: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
Message-ID: <YNOhegjWIMF9IRlpKGuR2kP-FKCwOtNsL9SB2_0sarg=.4c9a4ee5-8690-480d-b966-b98263b563d9@github.com>

On Mon, 12 Jun 2023 09:45:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks to @exe-boss for the reviews in #13082. This cleanup patch fixed the typos you pointed out and removed other redundancies in classfile Util as well.

It looks good ?

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14412#pullrequestreview-1476493101

From pminborg at openjdk.org  Tue Jun 13 08:41:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Jun 2023 08:41:59 GMT
Subject: RFR: 8295555: Primitive wrapper caches could be `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <cZJ4__D8IQz4CKNvwoFbMrSJbBBU7BxzsecnBLvDQIE=.c075b620-040b-41dd-bfa5-df704645c71c@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

The benchmarks I provided above does not involve constant folding so here is another set of benchmarks (Thanks @cl4es):

Before

Benchmark                     (size)  Mode  Cnt  Score   Error  Units
Integers.constantFoldInteger     500  avgt   15  0.568 ? 0.013  ns/op
Integers.constantFoldInts        500  avgt   15  0.564 ? 0.005  ns/op


After

Benchmark                     (size)  Mode  Cnt  Score   Error  Units
Integers.constantFoldInteger     500  avgt   15  0.558 ? 0.001  ns/op
Integers.constantFoldInts        500  avgt   15  0.559 ? 0.001  ns/op



    @Benchmark
    public int constantFoldInteger() {
        return Integer.valueOf(64) * Integer.valueOf(32);
    }

    @Benchmark
    public int constantFoldInts() {
        return 64 * 32;
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14418#issuecomment-1588823240

From pminborg at openjdk.org  Tue Jun 13 08:42:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Jun 2023 08:42:00 GMT
Subject: Integrated: 8295555: Primitive wrapper caches could be `@Stable`
In-Reply-To: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
References: <y0IBbmsvm7dl1bQUr9xMNxAIqzCoeTpivJ7jXEUm8Hc=.3477b4ba-b3a9-49b1-b365-0911db8f9798@github.com>
Message-ID: <2i2i_LDCzog0M62mIuQ8QTZKBu4tkd8uXJLI68b5Rqs=.ba13193a-49c7-49fa-9b1d-f14797776b68@github.com>

On Mon, 12 Jun 2023 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@Stable` to certain wrapper classes' cache arrays (e.g. `Integer` and `Long`).
> 
> Comments are welcome as to how to improve the VM's handling now that the backing cache array is `@Stable`. Are there simplifications to be made or are there other optimizations we might add?

This pull request has now been integrated.

Changeset: f7de726b
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f7de726bd37a2f1fa6f63b601cd2dab1805234e8
Stats:     16 lines in 5 files changed: 11 ins; 0 del; 5 mod

8295555: Primitive wrapper caches could be `@Stable`

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14418

From liach at openjdk.org  Tue Jun 13 09:00:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 09:00:58 GMT
Subject: Integrated: 8309838: Classfile API Util.toBinaryName and other cleanup
In-Reply-To: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
References: <OnzoqpfwhAS5JGHQmHawWnrxsIpCkqXZ5IASswr1tYA=.8d306e90-6917-48f5-bd2d-48f0b9bee490@github.com>
Message-ID: <mWJByeTDkKWfJx7xbh7BEWBabkrGnk5WpK2XU6rBwGs=.e85dba8f-2cc2-40d6-a1ea-0760d2446616@github.com>

On Mon, 12 Jun 2023 09:45:18 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks to @exe-boss for the reviews in #13082. This cleanup patch fixed the typos you pointed out and removed other redundancies in classfile Util as well.

This pull request has now been integrated.

Changeset: 1a9edb8d
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a9edb8df9c1da9eb0178aa53be748828dc7835e
Stats:     77 lines in 4 files changed: 1 ins; 62 del; 14 mod

8309838: Classfile API Util.toBinaryName and other cleanup

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/14412

From liach at openjdk.org  Tue Jun 13 09:23:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 09:23:01 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
Message-ID: <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>

On Mon, 12 Jun 2023 15:55:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> 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 38 commits:
> 
>  - Merge branch 'master' into JDK-8308899-context
>  - Revert of DirectCodeBuilder.needsStackMap pre-calculation
>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>    esolver.java
>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>    
>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
>  - fixed StackMapsOption dispatching in DirectCodeBuilder
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache
>  - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>    
>    This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
>  - ClassHierarchyResolver::ofSystem is now thread-unsafe
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e

I have found the cause of the regression: there's redundant stack map generation in DirectCodeBuilder for methods with trivial stack map table (null).

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 334:

> 332:                     maxLocals = original.maxLocals();
> 333:                     maxStack = original.maxStack();
> 334:                     stackMapAttr = original.findAttribute(Attributes.STACK_MAP_TABLE).orElse(null);

On the baseline, if a stack map table attribute can be reused but this findAttribute doesn't find an attribute (implying an implicit stack map, potentially for simple code?), we will not perform a stack map generation and simply reuse a trivial stack map (null), which should be a correct algorithm.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 349:

> 347:             }
> 348: 
> 349:             private boolean writeOriginalAttribute(BufWriterImpl buf) {

As a result (see previous comment), we will run into a redundant stack map generation when the original stack map table is trivial (absent). Maybe we want to consider user-configured selective stack map regeneration to replace this faulty logiic.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1476665044
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1227803483
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1227808744

From liach at openjdk.org  Tue Jun 13 09:36:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 09:36:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
Message-ID: <j007AqIU2A6le9fIs3atyZ7yTaUhGKVNNIJW0PJUsSk=.76ec71ae-dc4d-4615-b535-665abb68e57f@github.com>

On Mon, 12 Jun 2023 15:55:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> 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 38 commits:
> 
>  - Merge branch 'master' into JDK-8308899-context
>  - Revert of DirectCodeBuilder.needsStackMap pre-calculation
>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>    esolver.java
>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>    
>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
>  - fixed StackMapsOption dispatching in DirectCodeBuilder
>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>  - used Factory.INSTANCE for system ClassHierarchyResolver cache
>  - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>    
>    This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
>  - ClassHierarchyResolver::ofSystem is now thread-unsafe
>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>    introduction of ClassHierarchyResolver::ofSystem factory method
>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e

Since "not generating stack maps" really means to use an implicit stack map, I suggest renaming the `STACK_MAPS_NEVER` to `STACK_MAPS_IMPLICIT` to indicate such a confusing feature of StackMapTable. (In fact, the enum element names of StackMapsOption doesn't fit in with other options, they should be ALWAYS_STACK_MAPS, NEVER_STACK_MAPS, etc.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1588916612

From prappo at openjdk.org  Tue Jun 13 10:11:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Jun 2023 10:11:28 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - fix failing SourceDocTreeScannerTest
 - Merge branch 'master' into 8285368
 - feedback: use JavadocTester.out
   
   Also, trivially fixes grammar (word order) in a comment.
 - feedback: remove unduly restrictive warning
 - suggestion: vocabulary
 - feedback: DocLint terminology
 - feedback: use utils directly
 - Merge branch 'master' into 8285368
 - feedback: make warning less scary
 - Disable problematic check
   
   This check is well-intended but problematic for JDK API Documentation
   build, which errors on warnings.
 - ... and 4 more: https://git.openjdk.org/jdk/compare/e7a50303...563a8761

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/cccffa66..563a8761

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=07-08

  Stats: 11904 lines in 355 files changed: 9502 ins; 1007 del; 1395 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

PR: https://git.openjdk.org/jdk/pull/14357

From prappo at openjdk.org  Tue Jun 13 10:13:50 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 13 Jun 2023 10:13:50 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v8]
In-Reply-To: <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <s_V36_pNoxTdLaYD8EZR38Iso9Wdjm1TTh_R5-sgNJo=.a01574f0-d031-4856-9af2-7423cc45cb9d@github.com>
Message-ID: <gl2P0tzBbsQgl6CXhFtwG12d0aX_d2b4G1sIiaOepmY=.a6c0bdaa-1a47-4abb-9a0e-3fb8c8dfe4b7@github.com>

On Thu, 8 Jun 2023 14:47:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback: use JavadocTester.out
>   
>   Also, trivially fixes grammar (word order) in a comment.

core-libs, client: any reviewers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1588987444

From asotona at openjdk.org  Tue Jun 13 10:56:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 10:56:07 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v15]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <17guRBlm6Qq_d1542Vh26NjFp2nF3zkmPBuBUht6idA=.b6b523df-1d73-4448-b886-15945ebadc78@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> 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 40 commits:

 - performance fix
 - Merge branch 'master' into JDK-8308899-context
 - Merge branch 'master' into JDK-8308899-context
 - Revert of DirectCodeBuilder.needsStackMap pre-calculation
 - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
   esolver.java
 - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
   
   This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
 - fixed StackMapsOption dispatching in DirectCodeBuilder
 - proposed semi-synchronized caching, where the map is not locked during delegate call
 - used Factory.INSTANCE for system ClassHierarchyResolver cache
 - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
   
   This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
 - ... and 30 more: https://git.openjdk.org/jdk/compare/5d716121...074b60e3

-------------

Changes: https://git.openjdk.org/jdk/pull/14180/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=14
  Stats: 1668 lines in 106 files changed: 523 ins; 246 del; 899 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From alanb at openjdk.org  Tue Jun 13 11:24:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jun 2023 11:24:52 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>

On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 166:

> 164:         // can subsequently be used by the Locale instance which
> 165:         // guarantees the locale components are properly cased/interned.
> 166:         synchronized (BaseLocale.class) {

The simplification is good but I wonder if this coarse locking is going to be a problem, do we need to use some concurrent to avoid contention here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1227963571

From asotona at openjdk.org  Tue Jun 13 11:32:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 11:32:59 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v16]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <KGxZNYjrXI1EcJn6x7ILD2DyU9cOVsRYaq1UWwmJHkM=.fe575184-dd5c-45ff-889a-ce7c33c87e8b@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassHierarchyResolver.DEFAULT_RESOLVER gets info from system class loader and does not cache
  method-level caching is enabled if the provided resolver is not already cached

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/074b60e3..45c69314

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=14-15

  Stats: 23 lines in 3 files changed: 7 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Tue Jun 13 11:56:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 11:56:49 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v16]
In-Reply-To: <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
 <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
Message-ID: <9qmpHTGGm4ZoO77dehRY5ad8uYHrbMLpmUDqHZFiRus=.1f85092f-09c5-444f-86b6-96841636960d@github.com>

On Tue, 13 Jun 2023 09:15:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ClassHierarchyResolver.DEFAULT_RESOLVER gets info from system class loader and does not cache
>>   method-level caching is enabled if the provided resolver is not already cached
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 334:
> 
>> 332:                     maxLocals = original.maxLocals();
>> 333:                     maxStack = original.maxStack();
>> 334:                     stackMapAttr = original.findAttribute(Attributes.STACK_MAP_TABLE).orElse(null);
> 
> On the baseline, if a stack map table attribute can be reused but this findAttribute doesn't find an attribute (implying an implicit stack map, potentially for simple code?), we will not perform a stack map generation and simply reuse a trivial stack map (null), which should be a correct algorithm.

Yes, I caused this regression by "Revert of DirectCodeBuilder.needsStackMap pre-calculation" commit above.
The needStackMap pre-calculation on the other side caused regression in lambda performance, so one regression has been replaced with another.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1228001362

From asotona at openjdk.org  Tue Jun 13 11:56:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 11:56:53 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
 <8lNzKNox9T-4yRlTodsdBWcnCEZUYkkAn39ZySj_VyI=.915f4301-e503-42b2-b3e7-2760945d3e1b@github.com>
Message-ID: <QgGBCHJo-nKDCjRi-gbasLVuPrPq255aOXqwe76l6fw=.d714457a-6031-4e79-b17f-d29b03b31076@github.com>

On Tue, 13 Jun 2023 09:19:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
>> 
>>  - Merge branch 'master' into JDK-8308899-context
>>  - Revert of DirectCodeBuilder.needsStackMap pre-calculation
>>  - Revert "removal of ClassHierarchyImpl.DEFAULT_RESOLVER"
>>    esolver.java
>>  - Revert "proposed semi-synchronized caching, where the map is not locked during delegate call"
>>    
>>    This reverts commit ae2877512d978468743bcaa7e0f596729f12ee72.
>>  - fixed StackMapsOption dispatching in DirectCodeBuilder
>>  - proposed semi-synchronized caching, where the map is not locked during delegate call
>>  - used Factory.INSTANCE for system ClassHierarchyResolver cache
>>  - Revert "ClassHierarchyResolver::ofSystem is now thread-unsafe"
>>    
>>    This reverts commit f3099cd5b252924392995bf65edc710c27822d2b.
>>  - ClassHierarchyResolver::ofSystem is now thread-unsafe
>>  - removal of ClassHierarchyImpl.DEFAULT_RESOLVER
>>    introduction of ClassHierarchyResolver::ofSystem factory method
>>    ClassfileImpl does not pre-initialize ClassHierarchyResolverOption with default
>>  - ... and 28 more: https://git.openjdk.org/jdk/compare/5d5ae352...9e0d141e
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 349:
> 
>> 347:             }
>> 348: 
>> 349:             private boolean writeOriginalAttribute(BufWriterImpl buf) {
> 
> As a result (see previous comment), we will run into a redundant stack map generation when the original stack map table is trivial (absent). Maybe we want to consider user-configured selective stack map regeneration to replace this faulty logiic.

I've fixed the logic in the commit below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1228002306

From asotona at openjdk.org  Tue Jun 13 12:09:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 12:09:58 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v16]
In-Reply-To: <KGxZNYjrXI1EcJn6x7ILD2DyU9cOVsRYaq1UWwmJHkM=.fe575184-dd5c-45ff-889a-ce7c33c87e8b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <KGxZNYjrXI1EcJn6x7ILD2DyU9cOVsRYaq1UWwmJHkM=.fe575184-dd5c-45ff-889a-ce7c33c87e8b@github.com>
Message-ID: <6RbdrJxMLrBVPWEfRzclm42KT6MXBgLzbmGztAxPExA=.41950b62-9a94-4533-b615-92b47a579ddd@github.com>

On Tue, 13 Jun 2023 11:32:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassHierarchyResolver.DEFAULT_RESOLVER gets info from system class loader and does not cache
>   method-level caching is enabled if the provided resolver is not already cached

All the performance regressions have been found and fixed.
Stackmaps generation logic is following:
- `STACK_MAPS_WHEN_REQUIRED` is the default option and performance-critical. It keeps original stack maps if code match and generate them only when required.
- `STACK_MAPS_ALWAYS` always (re)generate stack maps no matter if exist in the original
- `STACK_MAPS_NEVER` stack maps are not generated and dropped if already exist

Naming convention can be still adjusted.

Default `ClassHierarchyResolver` now use reflection from system class loader and it is not globally cached (so no dilemma about CHM vs HM). Any CHR is cached on method level if not already cached.

Benchmarks comparison of this PR vs master now shows even slight improvement:

Benchmark                                  (transform)    master  this PR Units
AdHocAdapt.transform                              LIFT     8.704    9.629 ops/s
AdHocAdapt.transform                             LIFT1     8.622    9.275 ops/s
AdHocAdapt.transform                             LIFT2     9.257    9.378 ops/s
AdaptInjectNoop.transform                   NOP_SHARED     4.709    4.978 ops/s
AdaptNull.transform                           SHARED_1    96.686   98.027 ops/s
AdaptNull.transform                           SHARED_2    48.820   49.257 ops/s
AdaptNull.transform                           SHARED_3     9.611    9.691 ops/s
AdaptNull.transform                  SHARED_3_NO_DEBUG    12.218   12.343 ops/s
AdaptNull.transform                         UNSHARED_3     3.614    3.603 ops/s
ParseOptions.transformNoDebug                      N/A    11.169   11.084 ops/s
ParseOptions.transformNoLineNumbers                N/A    10.590   10.523 ops/s
ParseOptions.transformNoStackmap                   N/A     6.220    9.646 ops/s

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1589174024

From asotona at openjdk.org  Tue Jun 13 13:12:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 13 Jun 2023 13:12:56 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v14]
In-Reply-To: <j007AqIU2A6le9fIs3atyZ7yTaUhGKVNNIJW0PJUsSk=.76ec71ae-dc4d-4615-b535-665abb68e57f@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <GcsZJMTxJWiolQc6ZakFSLPTd9tnJt5rSAyoUER8dNs=.2538191c-9a85-45a4-95f7-99ea7f10b4bf@github.com>
 <j007AqIU2A6le9fIs3atyZ7yTaUhGKVNNIJW0PJUsSk=.76ec71ae-dc4d-4615-b535-665abb68e57f@github.com>
Message-ID: <WImBCc_ec27tlGyJeBneKoSAOotsQw8BLKSlD2HzYAY=.cb983319-2db3-4c32-9ab1-dd419efead3c@github.com>

On Tue, 13 Jun 2023 09:34:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>StackMapsOption doesn't fit in with other options, they should be ALWAYS_STACK_MAPS, NEVER_STACK_MAPS, etc.)

What about `STACK_MAPS_WHEN_REQUIRED`, `GENERATE_STACK_MAPS` and `DROP_STACK_MAPS`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1589282092

From aturbanov at openjdk.org  Tue Jun 13 13:14:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 Jun 2023 13:14:54 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
Message-ID: <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>

On Mon, 12 Jun 2023 17:33:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup

test/micro/org/openjdk/bench/java/util/LocaleCache.java line 58:

> 56:                 throw new RuntimeException("Different Locale was created");
> 57:             }
> 58:             previous =  l;

Suggestion:

            previous = l;

test/micro/org/openjdk/bench/java/util/LocaleCache.java line 70:

> 68:                 throw new RuntimeException("Different Locale was created");
> 69:             }
> 70:             previous =  l;

Suggestion:

            previous = l;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228106882
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228109502

From aturbanov at openjdk.org  Tue Jun 13 13:24:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 Jun 2023 13:24:50 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <YlTxfF8F3KBNyAGHzqemDFeAaowqatuGiuH-isei3Ik=.a2677c74-629f-4fe1-bc22-1f4cf02d790b@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 330:

> 328:         if (arg.toLowerCase(Locale.ROOT).equals("properties")) {
> 329:             printSecurityProperties();
> 330:         } else if(arg.toLowerCase(Locale.ROOT).equals("providers")) {

Suggestion:

        } else if (arg.toLowerCase(Locale.ROOT).equals("providers")) {

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 332:

> 330:         } else if(arg.toLowerCase(Locale.ROOT).equals("providers")) {
> 331:             printSecurityProviderConfig();
> 332:         } else if(arg.toLowerCase(Locale.ROOT).equals("tls")) {

Suggestion:

        } else if (arg.toLowerCase(Locale.ROOT).equals("tls")) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228125148
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228125325

From jvernee at openjdk.org  Tue Jun 13 13:53:19 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Jun 2023 13:53:19 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
Message-ID: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>

Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.

For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.

This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.

---

I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
2. run `urct64` (this is one of the shell environments that comes with MSYS2)
3. then, in the libffi repo root folder:
  3.a run `autogen.sh`
  3.b run:

bash configure \
  CC="/mnt/h/Projects-new/libffi/msvcc.sh -m64" \
  CXX="/mnt/h/Projects-new/libffi/msvcc.sh -m64" \
  CPPFLAGS="-DFFI_BUILDING_DLL" \
  --disable-docs \
  --prefix=<install dest>

(<install dest> can be whatever you like. That's what you point `--with-libffi` to).

4. run `make install`. This should create a directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
5. Manually create `.lib` file:
  5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
  5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
  5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)

---

Testing:
- manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
- Linux/x64 Zero test run of the `jdk_foreign` suite
- Linux/AArch64 Zero build

-------------

Commit messages:
 - update libffi script for mac
 - mac fixes
 - working fallback linker on Windows x64

Changes: https://git.openjdk.org/jdk/pull/14446/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14446&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309880
  Stats: 103 lines in 7 files changed: 73 ins; 9 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/14446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14446/head:pull/14446

PR: https://git.openjdk.org/jdk/pull/14446

From coffeys at openjdk.org  Tue Jun 13 13:57:13 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 13 Jun 2023 13:57:13 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v2]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <K3j_mmDet0ZES72rNs4s0Qu9c6IUReV85uV-V9l0GpI=.19a3f24f-8776-499a-ae82-a91f8ef09e7b@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request with a new target base 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 8281658-showsettings-security
 - Incorporate feedback to date
 - minor edits, copyright, descriptions etc
 - Merge branch 'master' into 8281658-showsettings-security
 - Merge branch 'master' into 8281658-showsettings-security
 - 8281658

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/a54a0921..c60a4ed4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=00-01

  Stats: 51921 lines in 852 files changed: 41802 ins; 7035 del; 3084 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From coffeys at openjdk.org  Tue Jun 13 13:57:59 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 13 Jun 2023 13:57:59 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <uNiIKO8PzPiVg22eiLB5fZ-MqLVmzJYAFUavaaaeN6I=.49a11467-ad48-4cbc-9c87-590fc6ef7387@github.com>

On Fri, 9 Jun 2023 13:54:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Thanks for the feedback to date. I've pushed new changes to reflect requested changes. I've changed the default` -XshowSettings `behaviour to only print some highlights of security settings and to also hint at how verbose security settings are shown. I think that works.

I looked at widening use of the `wrappedString `utility method Roger but there were subtle differences with how security properties arguments are wrapped. Not sure if it warrants the extra complexity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1589369063

From rriggs at openjdk.org  Tue Jun 13 14:14:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Jun 2023 14:14:40 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
References: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
Message-ID: <Mo8gf4bvRf-l-CMdPsVsqA2vBvJYSzq9X6x05d3Lhqg=.045c88ec-a387-49aa-a7cc-83d63b34e8c1@github.com>

On Tue, 13 Jun 2023 00:03:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Make `putMode` be a transient field.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14433#pullrequestreview-1477284507

From pminborg at openjdk.org  Tue Jun 13 14:21:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 13 Jun 2023 14:21:48 GMT
Subject: RFR: 8309937: Add @sealedGraph for some Panama FFM interfaces
Message-ID: <9JlPBUbaxVi-E-8kyWEfIdOrOJXEedzsO-VO6LsdjUs=.9de817af-7257-46b4-abf0-063e37db1bd1@github.com>

This PR proposes adding `@sealedGraph` to `GroupLayout` so the latter will be rendered in the javadocs the same way the other layouts that has public sub-interfaces.

-------------

Commit messages:
 - Add @sealedGraph to GroupLayout

Changes: https://git.openjdk.org/jdk/pull/14449/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14449&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309937
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14449.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14449/head:pull/14449

PR: https://git.openjdk.org/jdk/pull/14449

From aph at openjdk.org  Tue Jun 13 14:33:42 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Jun 2023 14:33:42 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v3]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <OXyiGyZA3ugRTRPDNJz_B_PtcQSrvjKa-z9JU8rtf-k=.63321fc3-eb31-4729-bdbb-3fe6c5fa8f35@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Robustify test.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/3ab613fe..6686bd48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=01-02

  Stats: 64 lines in 1 file changed: 32 ins; 11 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From dnsimon at openjdk.org  Tue Jun 13 14:47:58 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 13 Jun 2023 14:47:58 GMT
Subject: RFR: 8309390: [JVMCI] improve copying system properties into
 libgraal [v5]
In-Reply-To: <ol8KjpE9i7qCY282NEdFMjkgB_toYB8Xxai4lJpQFYc=.d59bcf00-02c0-4474-a868-0df1d2201628@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
 <ol8KjpE9i7qCY282NEdFMjkgB_toYB8Xxai4lJpQFYc=.d59bcf00-02c0-4474-a868-0df1d2201628@github.com>
Message-ID: <7A5bCVBZ26AOrKozsyEXzg_WFu_HQck6Aouw8BvyVfY=.04bb527b-0e4c-4a5e-9235-5efa9e5c0ca5@github.com>

On Mon, 12 Jun 2023 18:55:42 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
>> 
>> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
>> 
>> ## Times
>> 
>> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
>> 
>> 
>> public class Nop {
>>     public static void main(String[] args) {}
>> }
>> 
>> 
>> (1) Baseline (no options):
>> 
>>> for i in (seq 10); java Nop; end
>>         0.05 real         0.04 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.04 real         0.03 user         0.00 sys
>>         0.03 real         0.03 user         0.00 sys
>>         0.04 real         0.03 user         0.01 sys
>>         0.03 real         0.03 user         0.00 sys
>> 
>> 
>> (2) Eagerly initialize libgraal (with PR):
>> 
>>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>>         0.06 real         0.04 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>>         0.05 real         0.03 user         0.01 sys
>> 
>> 
>> (3) Eagerly initialize libgraal (without PR):
>> 
>>> for i in (seq 10...
>
> Doug Simon has updated the pull request with a new target base 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:
> 
>  - [skip-ci] Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8309390
>  - [skip-ci] remove debug code
>  - fix copyright dates
>  - fix reference in comments
>  - reduced complexity of SystemProperties based on it being unmodifiable
>  - copy system properties into libgraal more efficiently

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14291#issuecomment-1589457194

From dnsimon at openjdk.org  Tue Jun 13 14:48:01 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 13 Jun 2023 14:48:01 GMT
Subject: Integrated: 8309390: [JVMCI] improve copying system properties into
 libgraal
In-Reply-To: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
References: <9bsjzlbHK31VVyGwzyhpSBjSILWFxmAX0IfiWK6Wb_w=.197d2b45-dba5-43bc-ac4e-4f993d3e777a@github.com>
Message-ID: <lQ-ogqBX8oi-WgDdKa-3cV9d6DKAGgJYemjWpzvuwWc=.072c73f1-0c21-4db1-83b3-f28cd92e6d8a@github.com>

On Fri, 2 Jun 2023 20:32:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example, `java/util/Locale/CompatWarning.java` can fail if `sun.util.locale.provider.LocaleProviderAdapter` is initialized before the `CheckWarning` handler is registered.
> 
> Instead of serializing `VM.savedProps` via `VMSupport.serializeSavedPropertiesToByteArray`, the `jdk.vm.ci.services.Services` class now directly reads `Arguments::system_properties()` using `Unsafe`. Furthermore, the value of a system property is lazily converted to a `String` from a C string pointer.
> 
> ## Times
> 
> The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
> 
> 
> public class Nop {
>     public static void main(String[] args) {}
> }
> 
> 
> (1) Baseline (no options):
> 
>> for i in (seq 10); java Nop; end
>         0.05 real         0.04 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.04 real         0.03 user         0.00 sys
>         0.03 real         0.03 user         0.00 sys
>         0.04 real         0.03 user         0.01 sys
>         0.03 real         0.03 user         0.00 sys
> 
> 
> (2) Eagerly initialize libgraal (with PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.06 real         0.04 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
>         0.05 real         0.03 user         0.01 sys
> 
> 
> (3) Eagerly initialize libgraal (without PR):
> 
>> for i in (seq 10); /usr/bin/time java -XX:+EagerJVMCI Nop; end
>         0.11 real         0.08 user         ...

This pull request has now been integrated.

Changeset: c0aa6bf4
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0aa6bf4febb836a26941f13558d0a930e088fad
Stats:     589 lines in 19 files changed: 394 ins; 138 del; 57 mod

8309390: [JVMCI] improve copying system properties into libgraal

Reviewed-by: never, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/14291

From aph at openjdk.org  Tue Jun 13 14:54:15 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Jun 2023 14:54:15 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v4]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <f7vhrJlcn30K1J8WNvGagGtvZUeKkpNDt1WyNdhNkXY=.83863cd6-396a-4206-8d5a-1f99f9c07bca@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:

 - Remove ScopedValue/StressStackOverflow.java.
 - Cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/6686bd48..5902a70d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=02-03

  Stats: 4 lines in 3 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From aph at openjdk.org  Tue Jun 13 14:54:15 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Jun 2023 14:54:15 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v4]
In-Reply-To: <5sBVyW7eSDpFvOKHqoc6Q-PCYpaAEnT6vu_JBAy236s=.851988b1-fd21-4733-a675-b5a049923741@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <xFI2j5L-oBu7t3asNxhwHvMrn5BcrH8LKXpc2kgDi00=.9d3ac600-34de-4629-b8fd-9d9131578708@github.com>
 <5sBVyW7eSDpFvOKHqoc6Q-PCYpaAEnT6vu_JBAy236s=.851988b1-fd21-4733-a675-b5a049923741@github.com>
Message-ID: <LnQ0b803EZy6P4fHgLVYtR6SWSHvlHTX7JB_Sy00WLE=.5527558f-3adf-40b6-b7b6-a3d88909f5a0@github.com>

On Mon, 12 Jun 2023 14:26:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove ScopedValue/StressStackOverflow.java.
>>  - Cleanup
>
> test/jdk/ProblemList-Virtual.txt line 48:
> 
>> 46: 
>> 47: java/lang/ScopedValue/StressStackOverflow.java 8309646 generic-all
>> 48: 
> 
> That's the issue for the JTREG_TEST_THREAD_FACTORY=Virtual runs. I think we need to leave it excluded until that issue is diagnosed/fixed. 
> 
> However, in jdk/test/ProblemList.txt, it is excluded on linux-s390x as that platform doesn't seem to have, or use, VM continuations and so is using the fallback/alternative implementation. I think this entry can be removed now.

I think it's fixed now.

Two problems:
1. Test was not guaranteed to make forward progress. Fixed with a 3 minute timeout.
2. Test was very slow in some conditions. Likewise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14399#discussion_r1228254511

From rriggs at openjdk.org  Tue Jun 13 14:57:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Jun 2023 14:57:57 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v2]
In-Reply-To: <K3j_mmDet0ZES72rNs4s0Qu9c6IUReV85uV-V9l0GpI=.19a3f24f-8776-499a-ae82-a91f8ef09e7b@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <K3j_mmDet0ZES72rNs4s0Qu9c6IUReV85uV-V9l0GpI=.19a3f24f-8776-499a-ae82-a91f8ef09e7b@github.com>
Message-ID: <-t0j8xoVmNzjqVi2SvBGoGUUl0cot5buTNMvDZO1zig=.2fbf648f-785a-4738-b5cb-d882f0eb2eaf@github.com>

On Tue, 13 Jun 2023 13:57:13 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request with a new target base 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 8281658-showsettings-security
>  - Incorporate feedback to date
>  - minor edits, copyright, descriptions etc
>  - Merge branch 'master' into 8281658-showsettings-security
>  - Merge branch 'master' into 8281658-showsettings-security
>  - 8281658

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 189:

> 187:                 } else {
> 188:                     printSecuritySettings("all");
> 189:                 }

Perhaps a slight preference for:

            var opt = opts.length > 2 ? opts[2].trim() : "all";
            printSecuritySettings(opt);

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 342:

> 340: 
> 341:     private static void printSecuritySettings(String arg) {
> 342:         switch (arg.toLowerCase(Locale.ROOT)) {

Drop the conversion to lower case: none of the other categories allow "sloppy-case" inputs.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 422:

> 420:             ostream.println(TWOINDENT + "Provider name: " + p.getName());
> 421:             if (verbose) {
> 422:                 ostream.println(TWOINDENT + PROV_INFO_STRING + wrappedString(p.getInfo(), 80));

Wrapping the args at 80 might still produce line that is quite long.
Perhaps wrap the string after it was concatenated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228227964
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228187867
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1228270167

From smarks at openjdk.org  Tue Jun 13 15:19:57 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 15:19:57 GMT
Subject: Integrated: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
References: <VfbiD9cwCrMDYHJdqSuwJKN54bveaxF49EwLoeZlaNU=.f21e2611-56b4-4d8e-a663-8831cf19ae31@github.com>
Message-ID: <w1BZHIWV_TIfJe-1LX98OQHunEihJ7xMlZKk8rV3Xlc=.05e44cb5-e7c2-40ff-b1cb-eb78c6448fae@github.com>

On Tue, 13 Jun 2023 00:03:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Make `putMode` be a transient field.

This pull request has now been integrated.

Changeset: e1386856
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e138685648fb7a756a05f314af2883ce408abdd2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8309882: LinkedHashMap adds an errant serializable field

Reviewed-by: darcy, bpb, jpai, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14433

From aph at openjdk.org  Tue Jun 13 15:27:52 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Jun 2023 15:27:52 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v5]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <iGFHLlgvtsFvw45g6xHUc42vqEujz98CO1kdPRk3t-Y=.4a317dde-8498-4028-ac70-0708940bd581@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Remove import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/5902a70d..cb39ac52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From cwimmer at openjdk.org  Tue Jun 13 15:51:44 2023
From: cwimmer at openjdk.org (Christian Wimmer)
Date: Tue, 13 Jun 2023 15:51:44 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Hf_sb5okDsMhTxBWMGG3rCGm6d4IZQI_s7ZhvepeslY=.9b184308-6e86-4cd3-bb38-f22e0f044623@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <G9u89zgphCQ0I7pyWMV3kZACY-JzxBYmMecseqK8hFg=.7c4f8604-005c-43c0-a1fb-3d4888645e1d@github.com>
 <Hf_sb5okDsMhTxBWMGG3rCGm6d4IZQI_s7ZhvepeslY=.9b184308-6e86-4cd3-bb38-f22e0f044623@github.com>
Message-ID: <CcV5_XJBBxakoSI_clUKbeNs-skJ6bKtSpmLEKjJCB4=.817ccef1-4811-4990-b0ee-998d386f3311@github.com>

On Thu, 1 Jun 2023 12:11:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's easy to introduce a new change to this code which accidentally drags in some of those (unwanted) dependencies again.

We (as the Native Image team) are OK with this. Our testing will detect that pretty quickly, and then the new code can be fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1589582149

From aph at openjdk.org  Tue Jun 13 15:53:07 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 13 Jun 2023 15:53:07 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v6]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <AVxbiBLRheDJc_UeRWIaGoc3qyrkhiU4mQPQJGgd0WQ=.cabe90a4-9211-4921-8d85-e547e233b2b5@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  One other thing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/cb39ac52..cded1566

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From alanb at openjdk.org  Tue Jun 13 15:53:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jun 2023 15:53:21 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v6]
In-Reply-To: <AVxbiBLRheDJc_UeRWIaGoc3qyrkhiU4mQPQJGgd0WQ=.cabe90a4-9211-4921-8d85-e547e233b2b5@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <AVxbiBLRheDJc_UeRWIaGoc3qyrkhiU4mQPQJGgd0WQ=.cabe90a4-9211-4921-8d85-e547e233b2b5@github.com>
Message-ID: <Bn2pJA8m_Y5vcfNlOZEeFE8zdpsO87fgTOiQJPpkvpQ=.bca324da-663a-4188-8abe-b8a42c4fb8ee@github.com>

On Tue, 13 Jun 2023 15:53:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
>> 
>> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
>> 
>> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One other thing

The implementation changes look good.

The update to test looks okay too although I would like to see if we can do better in SVC and STS when there is a SO.  In passing, I think all usages of tlr should be replaced with ThreadLocalRandom.current().

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14399#pullrequestreview-1477540790

From alanb at openjdk.org  Tue Jun 13 16:09:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jun 2023 16:09:03 GMT
Subject: RFR: 8309853: StructuredTaskScope.join description improvements
Message-ID: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>

StructuredTaskScope's class description introduces the join method as waiting for all subtasks to finish but the API docs for join/joinUntil are phrased in terms of waiting for all threads to finish. ShutdownOnXXX join/joinUntil inherit this description but would be clearer if their description said they wait until all subtasks finished or a subtask to succeed or fail.

-------------

Commit messages:
 - Add apiNote about using shutdown directly
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14419/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14419&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309853
  Stats: 82 lines in 1 file changed: 54 ins; 3 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/14419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14419/head:pull/14419

PR: https://git.openjdk.org/jdk/pull/14419

From erikj at openjdk.org  Tue Jun 13 16:09:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 13 Jun 2023 16:09:52 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
In-Reply-To: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
Message-ID: <Ua3AaSa46nT_YKJkfkR7fOCqVMalxq9TUr8qnic-9Mw=.eae8c166-bd19-4d5a-9374-fd11dbaa6078@github.com>

On Tue, 13 Jun 2023 12:48:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
> 
> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
> 
> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.
> 
> ---
> 
> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
> 3. then, in the libffi repo root folder:
>   3.a run `autogen.sh`
>   3.b run:
> 
> bash configure \
>   CC="/path/to/libffi/msvcc.sh -m64" \
>   CXX="/path/to/libffi/msvcc.sh -m64" \
>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>   --disable-docs \
>   --prefix=<install dest>
> 
> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
> 
> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
> 5. Manually create a working `.lib` file:
>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
> 
> ---
> 
> Testing:
> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
> - Linux/x64 Zero test run of the `jdk_foreign` suite
> - Linux/AArch64 Zero build

Could you add the instructions for building libffi for Windows in a comment in createLibffiBundle.sh? I think it would be good to keep those around now that you have figured out how to do it.

make/modules/java.base/Lib.gmk line 231:

> 229:                  $(call SET_SHARED_LIBRARY_ORIGIN), \
> 230:       LIBS := $(LIBFFI_LIBS), \
> 231: 	  LIBS_windows := $(LIBFFI_LIBS) ws2_32.lib, \

Indentation looks off. Make sure you aren't mixing in tabs here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14446#pullrequestreview-1477569193
PR Review Comment: https://git.openjdk.org/jdk/pull/14446#discussion_r1228379034

From aturbanov at openjdk.org  Tue Jun 13 16:18:52 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 Jun 2023 16:18:52 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll()
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <QmZTZY1QdadtyiYnwL0kfdr9jAkfJe-k9Yh6PUnyHJg=.b3c690f3-e20b-4240-ae58-9e9c23338c52@github.com>

On Mon, 5 Jun 2023 18:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 701:

> 699:                     spins = 0;                  // don't spin
> 700:                 else if (pred.isData != isData || pred.isMatched())
> 701:                     spins =  FRONT_SPINS;

nit
Suggestion:

                    spins = FRONT_SPINS;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1228392118

From mchung at openjdk.org  Tue Jun 13 16:43:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Jun 2023 16:43:03 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
Message-ID: <eyu9Qed5I33ycSsNpTFwjcy73qNVCHLe6o5zqLLFYss=.ad3441ec-ed22-42d3-88d1-73da5a11e1ba@github.com>

This is a test-only fix.

    This pull request contains a backport of commit [679a6d89](https://github.com/openjdk/jdk/commit/679a6d89358eb36c596e3ffa9a86869402c9beb9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

    The commit being backported was authored by Mandy Chung on 9 Jun 2023 and was reviewed by Doug Simon and Alan Bateman.

    Thanks!

-------------

Commit messages:
 - Backport 679a6d89358eb36c596e3ffa9a86869402c9beb9

Changes: https://git.openjdk.org/jdk21/pull/13/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=13&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309303
  Stats: 37 lines in 1 file changed: 33 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk21/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/13/head:pull/13

PR: https://git.openjdk.org/jdk21/pull/13

From jvernee at openjdk.org  Tue Jun 13 16:44:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Jun 2023 16:44:55 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
In-Reply-To: <Ua3AaSa46nT_YKJkfkR7fOCqVMalxq9TUr8qnic-9Mw=.eae8c166-bd19-4d5a-9374-fd11dbaa6078@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
 <Ua3AaSa46nT_YKJkfkR7fOCqVMalxq9TUr8qnic-9Mw=.eae8c166-bd19-4d5a-9374-fd11dbaa6078@github.com>
Message-ID: <VfRoJrJE_LbjKkDifdZa7Vir8VabbkfJDayCb_sNK5A=.fa2253b6-197c-47ac-a114-eaeaa1460754@github.com>

On Tue, 13 Jun 2023 16:05:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
>> 
>> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
>> 
>> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.
>> 
>> ---
>> 
>> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
>> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
>> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
>> 3. then, in the libffi repo root folder:
>>   3.a run `autogen.sh`
>>   3.b run:
>> 
>> bash configure \
>>   CC="/path/to/libffi/msvcc.sh -m64" \
>>   CXX="/path/to/libffi/msvcc.sh -m64" \
>>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>>   --disable-docs \
>>   --prefix=<install dest>
>> 
>> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
>> 
>> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
>> 5. Manually create a working `.lib` file:
>>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
>> 
>> ---
>> 
>> Testing:
>> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
>> - Linux/x64 Zero test run of the `jdk_foreign` suite
>> - Linux/AArch64 Zero build
>
> make/modules/java.base/Lib.gmk line 231:
> 
>> 229:                  $(call SET_SHARED_LIBRARY_ORIGIN), \
>> 230:       LIBS := $(LIBFFI_LIBS), \
>> 231: 	  LIBS_windows := $(LIBFFI_LIBS) ws2_32.lib, \
> 
> Indentation looks off. Make sure you aren't mixing in tabs here.

Good catch, I indeed had a tab in there (I have github set to show tabs as 4 spaces, so didn't notice this).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14446#discussion_r1228422332

From alanb at openjdk.org  Tue Jun 13 16:51:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Jun 2023 16:51:56 GMT
Subject: RFR: 8309303: jdk/internal/misc/VM/RuntimeArguments test ignores
 jdk/internal/vm/options
In-Reply-To: <eyu9Qed5I33ycSsNpTFwjcy73qNVCHLe6o5zqLLFYss=.ad3441ec-ed22-42d3-88d1-73da5a11e1ba@github.com>
References: <eyu9Qed5I33ycSsNpTFwjcy73qNVCHLe6o5zqLLFYss=.ad3441ec-ed22-42d3-88d1-73da5a11e1ba@github.com>
Message-ID: <bSujU_DGfuYB76CGMAIKNXqj4q7pvhLhb8ePYe0Zf6I=.e6444747-e6a2-423a-a689-6e05e2d96c2e@github.com>

On Tue, 13 Jun 2023 16:35:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This is a test-only fix.
> 
> This pull request contains a backport of commit [679a6d89](https://github.com/openjdk/jdk/commit/679a6d89358eb36c596e3ffa9a86869402c9beb9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 9 Jun 2023 and was reviewed by Doug Simon and Alan Bateman.
> 
> Thanks!

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/13#pullrequestreview-1477651827

From mchung at openjdk.org  Tue Jun 13 16:51:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Jun 2023 16:51:57 GMT
Subject: Integrated: 8309303: jdk/internal/misc/VM/RuntimeArguments test
 ignores jdk/internal/vm/options
In-Reply-To: <eyu9Qed5I33ycSsNpTFwjcy73qNVCHLe6o5zqLLFYss=.ad3441ec-ed22-42d3-88d1-73da5a11e1ba@github.com>
References: <eyu9Qed5I33ycSsNpTFwjcy73qNVCHLe6o5zqLLFYss=.ad3441ec-ed22-42d3-88d1-73da5a11e1ba@github.com>
Message-ID: <MQ9B0_CkYzEZPSUFKuMHgyRwfe3VglyKO4pJsDwoKYk=.86b9c79b-3fe5-4882-a78e-4b18991a1630@github.com>

On Tue, 13 Jun 2023 16:35:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This is a test-only fix.
> 
> This pull request contains a backport of commit [679a6d89](https://github.com/openjdk/jdk/commit/679a6d89358eb36c596e3ffa9a86869402c9beb9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 9 Jun 2023 and was reviewed by Doug Simon and Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3363050f
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/3363050f9e24320eec2b53e196a6ff7e766fb788
Stats:     37 lines in 1 file changed: 33 ins; 1 del; 3 mod

8309303: jdk/internal/misc/VM/RuntimeArguments test ignores jdk/internal/vm/options

Reviewed-by: alanb
Backport-of: 679a6d89358eb36c596e3ffa9a86869402c9beb9

-------------

PR: https://git.openjdk.org/jdk21/pull/13

From liach at openjdk.org  Tue Jun 13 17:09:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 17:09:02 GMT
Subject: Integrated: 8307508: IndirectVarHandle.isAccessModeSupported throws
 NPE
In-Reply-To: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
References: <q_9K5WZbAXAvIwq7lH-j1dFRWzsFi69536qZkaWFA-k=.c155d1f3-f499-4707-8320-57e51bd7596d@github.com>
Message-ID: <85IjMhzMQp9YtbzF_eP8b91coXNRVhwRY6BHKzOYPmg=.a51e3c2a-78d6-42b7-9da7-4174350df079@github.com>

On Mon, 12 Jun 2023 05:27:35 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes the NPE in IndirectVarHandle.isAccessModeSupported by delegating to the target var handle. In addition, simplified the MH caching in Indirect VH and removed redundant overrides (already available via var form). This was split from #13821 as suggested by Mandy Chung, which allows easy backports to release 21 if desirable.

This pull request has now been integrated.

Changeset: 75dcc4ef
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75dcc4ef94d90e4aa7f8ca5eccc97c91492d6eed
Stats:     105 lines in 3 files changed: 69 ins; 27 del; 9 mod

8307508: IndirectVarHandle.isAccessModeSupported throws NPE

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14409

From jvernee at openjdk.org  Tue Jun 13 17:09:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Jun 2023 17:09:30 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
 [v2]
In-Reply-To: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
Message-ID: <MaFZ5W0oKcG39Ba9cULeEK09BMsd5L12Fb5Im9gVEIQ=.6156e374-bee7-4ed8-a85d-3e508428e96c@github.com>

> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
> 
> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
> 
> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.
> 
> ---
> 
> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
> 3. then, in the libffi repo root folder:
>   3.a run `autogen.sh`
>   3.b run:
> 
> bash configure \
>   CC="/path/to/libffi/msvcc.sh -m64" \
>   CXX="/path/to/libffi/msvcc.sh -m64" \
>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>   --disable-docs \
>   --prefix=<install dest>
> 
> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
> 
> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
> 5. Manually create a working `.lib` file:
>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
> 
> ---
> 
> Testing:
> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
> - Linux/x64 Zero test run of the `jdk_foreign` suite
> - Linux/AArch64 Zero build

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - missing changes
 - Address review comments:
   - Tab to spaces in java.base/Lib.gmk
   - Add comment with Windows build instructions to createLibffiBundle.sh

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14446/files
  - new: https://git.openjdk.org/jdk/pull/14446/files/17d4d914..0e454db9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14446&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14446&range=00-01

  Stats: 33 lines in 2 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14446.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14446/head:pull/14446

PR: https://git.openjdk.org/jdk/pull/14446

From jvernee at openjdk.org  Tue Jun 13 17:09:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Jun 2023 17:09:31 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
In-Reply-To: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
Message-ID: <fQvMLD7zvtben4d8bMoIhqWWn5WFd_cEAklNbq2Wzho=.3bb25dea-15e7-419f-b832-3ce9fdf63404@github.com>

On Tue, 13 Jun 2023 12:48:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
> 
> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
> 
> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.
> 
> ---
> 
> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
> 3. then, in the libffi repo root folder:
>   3.a run `autogen.sh`
>   3.b run:
> 
> bash configure \
>   CC="/path/to/libffi/msvcc.sh -m64" \
>   CXX="/path/to/libffi/msvcc.sh -m64" \
>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>   --disable-docs \
>   --prefix=<install dest>
> 
> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
> 
> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
> 5. Manually create a working `.lib` file:
>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
> 
> ---
> 
> Testing:
> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
> - Linux/x64 Zero test run of the `jdk_foreign` suite
> - Linux/AArch64 Zero build

I've fixed the tab, and added the instructions for Windows to `createLibffiBundle.sh`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14446#issuecomment-1589703092

From erikj at openjdk.org  Tue Jun 13 17:22:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 13 Jun 2023 17:22:54 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
 [v2]
In-Reply-To: <MaFZ5W0oKcG39Ba9cULeEK09BMsd5L12Fb5Im9gVEIQ=.6156e374-bee7-4ed8-a85d-3e508428e96c@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
 <MaFZ5W0oKcG39Ba9cULeEK09BMsd5L12Fb5Im9gVEIQ=.6156e374-bee7-4ed8-a85d-3e508428e96c@github.com>
Message-ID: <RVHS68sjoTX5p3Qivknfz2ycDNquT9k151CSbWqkrV0=.a37ee974-8c1c-4408-b972-20d392863b7a@github.com>

On Tue, 13 Jun 2023 17:09:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
>> 
>> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
>> 
>> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.
>> 
>> ---
>> 
>> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
>> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
>> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
>> 3. then, in the libffi repo root folder:
>>   3.a run `autogen.sh`
>>   3.b run:
>> 
>> bash configure \
>>   CC="/path/to/libffi/msvcc.sh -m64" \
>>   CXX="/path/to/libffi/msvcc.sh -m64" \
>>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>>   --disable-docs \
>>   --prefix=<install dest>
>> 
>> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
>> 
>> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
>> 5. Manually create a working `.lib` file:
>>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
>> 
>> ---
>> 
>> Testing:
>> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
>> - Linux/x64 Zero test run of the `jdk_foreign` suite
>> - Linux/AArch64 Zero build
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing changes
>  - Address review comments:
>    - Tab to spaces in java.base/Lib.gmk
>    - Add comment with Windows build instructions to createLibffiBundle.sh

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14446#pullrequestreview-1477706215

From jvernee at openjdk.org  Tue Jun 13 17:38:51 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 13 Jun 2023 17:38:51 GMT
Subject: RFR: 8309880: Add support for linking libffi on Windows and Mac
 [v2]
In-Reply-To: <MaFZ5W0oKcG39Ba9cULeEK09BMsd5L12Fb5Im9gVEIQ=.6156e374-bee7-4ed8-a85d-3e508428e96c@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
 <MaFZ5W0oKcG39Ba9cULeEK09BMsd5L12Fb5Im9gVEIQ=.6156e374-bee7-4ed8-a85d-3e508428e96c@github.com>
Message-ID: <txB4fNFNcGwRU5jdmDRDzOF9UbnpUzIQsvYlfai3G2g=.fc2fada2-7139-497a-809c-6631d15e7401@github.com>

On Tue, 13 Jun 2023 17:09:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
>> 
>> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
>> 
>> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 failing tests in the jdk_foreign suite on that platform.
>> 
>> ---
>> 
>> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
>> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
>> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
>> 3. then, in the libffi repo root folder:
>>   3.a run `autogen.sh`
>>   3.b run:
>> 
>> bash configure \
>>   CC="/path/to/libffi/msvcc.sh -m64" \
>>   CXX="/path/to/libffi/msvcc.sh -m64" \
>>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>>   --disable-docs \
>>   --prefix=<install dest>
>> 
>> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
>> 
>> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
>> 5. Manually create a working `.lib` file:
>>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
>> 
>> ---
>> 
>> Testing:
>> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
>> - Linux/x64 Zero test run of the `jdk_foreign` suite
>> - Linux/AArch64 Zero build
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - missing changes
>  - Address review comments:
>    - Tab to spaces in java.base/Lib.gmk
>    - Add comment with Windows build instructions to createLibffiBundle.sh

I've also filed: https://bugs.openjdk.org/browse/JDK-8309954 as documentation of why the tests are disabled.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14446#issuecomment-1589747083

From naoto at openjdk.org  Tue Jun 13 17:56:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 17:56:57 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/fb1535ff..ac6ea421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=01-02

  Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From naoto at openjdk.org  Tue Jun 13 18:00:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:00:53 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
Message-ID: <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>

On Tue, 13 Jun 2023 11:22:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 166:
> 
>> 164:         // can subsequently be used by the Locale instance which
>> 165:         // guarantees the locale components are properly cased/interned.
>> 166:         synchronized (BaseLocale.class) {
> 
> The simplification is good but I wonder if this coarse locking is going to be a problem, do we need to use some concurrent to avoid contention here?

Replaced it with a ReentrantLock

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228504526

From naoto at openjdk.org  Tue Jun 13 18:00:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:00:57 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <MivX2vJkygO5loJYR6IttGKuD9z5K0zOFgn_pfhUAB4=.25630661-8ee7-484d-b3e9-39212fb22a8f@github.com>
Message-ID: <FgaAVqdLpB3Raw_J5LTFCFKjrapHhgOuR6_LoDcFx94=.c7246736-c8cb-4959-9830-3b071ebef54a@github.com>

On Tue, 13 Jun 2023 13:09:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing comments (test grouping, synchronization), minor optimization on loop lookup
>
> test/micro/org/openjdk/bench/java/util/LocaleCache.java line 58:
> 
>> 56:                 throw new RuntimeException("Different Locale was created");
>> 57:             }
>> 58:             previous =  l;
> 
> Suggestion:
> 
>             previous = l;

Fixed

> test/micro/org/openjdk/bench/java/util/LocaleCache.java line 70:
> 
>> 68:                 throw new RuntimeException("Different Locale was created");
>> 69:             }
>> 70:             previous =  l;
> 
> Suggestion:
> 
>             previous = l;

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228504659
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1228504936

From rgiulietti at openjdk.org  Tue Jun 13 18:15:00 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 Jun 2023 18:15:00 GMT
Subject: RFR: 8309955: Matcher uses @since {@inheritDoc}
Message-ID: <kWAANnitKfykD1UtKZjQwsBrYFkIim13GWM1GtUceCI=.d702aff7-0780-4297-b97b-6ad726381e05@github.com>

Trivial fix to working but unsupported use of {@inheritDoc}

-------------

Commit messages:
 - 8309955: Matcher uses @since {@inheritDoc}

Changes: https://git.openjdk.org/jdk/pull/14452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309955
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14452/head:pull/14452

PR: https://git.openjdk.org/jdk/pull/14452

From lancea at openjdk.org  Tue Jun 13 18:25:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 13 Jun 2023 18:25:39 GMT
Subject: RFR: 8309955: Matcher uses @since {@inheritDoc}
In-Reply-To: <kWAANnitKfykD1UtKZjQwsBrYFkIim13GWM1GtUceCI=.d702aff7-0780-4297-b97b-6ad726381e05@github.com>
References: <kWAANnitKfykD1UtKZjQwsBrYFkIim13GWM1GtUceCI=.d702aff7-0780-4297-b97b-6ad726381e05@github.com>
Message-ID: <NmcB3RaWBnT4ePiBpffRfF2Bmo7-ogbI5pIiuqBh6Zk=.de1d388b-d3c5-4227-a355-fea8f9b8ba66@github.com>

On Tue, 13 Jun 2023 18:08:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Trivial fix to working but unsupported use of {@inheritDoc}

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14452#pullrequestreview-1477810928

From naoto at openjdk.org  Tue Jun 13 18:41:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:41:52 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

The translation seems wrong. It means to *add* the selected file, which is not the same meaning as in English file

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:

> 138: 
> 139: # 0: type, 1: name
> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf

Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 505:

> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
> 505: 

These translations are very cryptic. Cannot understand it at first hand.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:

> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 959: 

The translation of "well-formed" is incorrect. It is not ???

-------------

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769

From rgiulietti at openjdk.org  Tue Jun 13 18:43:54 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 Jun 2023 18:43:54 GMT
Subject: Integrated: 8309955: Matcher uses @since {@inheritDoc}
In-Reply-To: <kWAANnitKfykD1UtKZjQwsBrYFkIim13GWM1GtUceCI=.d702aff7-0780-4297-b97b-6ad726381e05@github.com>
References: <kWAANnitKfykD1UtKZjQwsBrYFkIim13GWM1GtUceCI=.d702aff7-0780-4297-b97b-6ad726381e05@github.com>
Message-ID: <VXBl4P9nuouaAJf5501_nhjITxeWQg5x01iyoTXcXsU=.871d80fa-4995-4979-9996-6a9f21dd5848@github.com>

On Tue, 13 Jun 2023 18:08:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Trivial fix to working but unsupported use of {@inheritDoc}

This pull request has now been integrated.

Changeset: bfef3c3e
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfef3c3e80d4df98bdb0d853c2e2711cdd8252ce
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8309955: Matcher uses @since {@inheritDoc}

Reviewed-by: lancea

-------------

PR: https://git.openjdk.org/jdk/pull/14452

From rriggs at openjdk.org  Tue Jun 13 18:43:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Jun 2023 18:43:54 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <G-5lUrL5o1mHBF518jX21fRDl9mfxMVsTU07-gS2piA=.d9caf34d-c126-4168-a6c1-5748f3ba9c74@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6992bbe1...563a8761

Look ok for core-libs classes

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1477840678

From jlu at openjdk.org  Tue Jun 13 18:56:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 18:56:44 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>

On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
> 
>> 138: 
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
> 
> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let ask about this specific instance.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:
> 
>> 957: 
>> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959: 
> 
> The translation of "well-formed" is incorrect. It is not ???

For translations that are incorrect, I can file a bug against the tool. Such a fix would probably not happen soon, can you suggest an alternative for now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665

From rgiulietti at openjdk.org  Tue Jun 13 19:01:57 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 Jun 2023 19:01:57 GMT
Subject: RFR: 8309955: Matcher uses @since {@inheritDoc}
Message-ID: <dFeXajeSynqHzFCzQnDNiDaxeeWZUmI1tYiAwC74g1U=.cabbc568-8118-420e-85d2-e2066e8a4e0a@github.com>

Hi all,

This pull request contains a backport of commit [bfef3c3e](https://github.com/openjdk/jdk/commit/bfef3c3e80d4df98bdb0d853c2e2711cdd8252ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Raffaello Giulietti on 13 Jun 2023 and was reviewed by Lance Andersen.

Thanks!

-------------

Commit messages:
 - Backport bfef3c3e80d4df98bdb0d853c2e2711cdd8252ce

Changes: https://git.openjdk.org/jdk21/pull/14/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309955
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk21/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/14/head:pull/14

PR: https://git.openjdk.org/jdk21/pull/14

From bpb at openjdk.org  Tue Jun 13 19:05:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Jun 2023 19:05:56 GMT
Subject: RFR: 8309955: Matcher uses @since {@inheritDoc}
In-Reply-To: <dFeXajeSynqHzFCzQnDNiDaxeeWZUmI1tYiAwC74g1U=.cabbc568-8118-420e-85d2-e2066e8a4e0a@github.com>
References: <dFeXajeSynqHzFCzQnDNiDaxeeWZUmI1tYiAwC74g1U=.cabbc568-8118-420e-85d2-e2066e8a4e0a@github.com>
Message-ID: <uWcos6UVBAZNfjfAhUnSpyFA6C_gT53QFSL_ASJzviw=.f1aed82b-7b8d-4cb5-ab46-76ea19569e3d@github.com>

On Tue, 13 Jun 2023 18:55:20 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bfef3c3e](https://github.com/openjdk/jdk/commit/bfef3c3e80d4df98bdb0d853c2e2711cdd8252ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Raffaello Giulietti on 13 Jun 2023 and was reviewed by Lance Andersen.
> 
> Thanks!

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/14#pullrequestreview-1477880089

From rgiulietti at openjdk.org  Tue Jun 13 19:09:59 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 13 Jun 2023 19:09:59 GMT
Subject: Integrated: 8309955: Matcher uses @since {@inheritDoc}
In-Reply-To: <dFeXajeSynqHzFCzQnDNiDaxeeWZUmI1tYiAwC74g1U=.cabbc568-8118-420e-85d2-e2066e8a4e0a@github.com>
References: <dFeXajeSynqHzFCzQnDNiDaxeeWZUmI1tYiAwC74g1U=.cabbc568-8118-420e-85d2-e2066e8a4e0a@github.com>
Message-ID: <c1ppPhJS0EzrmFOEUcuYFThAb-p7TTzLqJzcz-66b4o=.01386146-d160-4ff4-b519-8983f2b953e6@github.com>

On Tue, 13 Jun 2023 18:55:20 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [bfef3c3e](https://github.com/openjdk/jdk/commit/bfef3c3e80d4df98bdb0d853c2e2711cdd8252ce) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Raffaello Giulietti on 13 Jun 2023 and was reviewed by Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: e18993c0
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/e18993c00609008ab1326da65ab479494f9914cb
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8309955: Matcher uses @since {@inheritDoc}

Reviewed-by: bpb
Backport-of: bfef3c3e80d4df98bdb0d853c2e2711cdd8252ce

-------------

PR: https://git.openjdk.org/jdk21/pull/14

From manc at openjdk.org  Tue Jun 13 19:24:08 2023
From: manc at openjdk.org (Man Cao)
Date: Tue, 13 Jun 2023 19:24:08 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v2]
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <uo-d_qVfs1JUZ4DdpBsTYlqKulW58uc8ZgRimwNxg2A=.445093ff-c80f-47a6-9a91-ff717222b3f0@github.com>

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK8309688
 - 8309688: Data race on java.io.ClassCache.strongReferent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14386/files
  - new: https://git.openjdk.org/jdk/pull/14386/files/daef2b22..3b6d0baf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=00-01

  Stats: 6835 lines in 318 files changed: 3989 ins; 1447 del; 1399 mod
  Patch: https://git.openjdk.org/jdk/pull/14386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14386/head:pull/14386

PR: https://git.openjdk.org/jdk/pull/14386

From aivanov at openjdk.org  Tue Jun 13 19:31:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Jun 2023 19:31:59 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v7]
In-Reply-To: <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <2DpBE46Rn1mY3i9T1oOMwpxJ3ye0taYJJm2rh-2ZlAw=.10043f50-5c41-4d09-bc3c-53f0c490c5ba@github.com>
 <g4jJ1D5ePMUrfccY52Wimk_89wW_cq2Y_hJne9lDBk4=.9843ffd6-32d0-421d-8e6a-0832e1ac9cee@github.com>
 <XloSCZcMe4T2bzU9MgqeV8yWVhMItpNJUt_amvUQ5gQ=.4e116a3f-8cb6-48da-979d-1fedea32b987@github.com>
 <gjrTtcVgBrDr6_c1EzDT3nZX97GFat59UQPNL41dK1o=.d5ea7d53-a4ce-4123-80aa-f7cd62139dee@github.com>
 <vAPGsOJrrIGbLR7KOgxD2QHEiola1Uh64TK1hmGXcnk=.ef3bfa76-883a-4659-988d-1f13f4739636@github.com>
 <iVcMmg2r9UXBrsTQBU7X2Y1GDvrCeTg-1l1Vc-uZOhQ=.6f272612-b970-41b0-b36d-b03204291b59@github.com>
Message-ID: <XryojXZM0ga3TLZZDfzG85pI_XAwPs7ZY4uNgb3PahM=.fa4efe54-e45d-4567-af0a-f1f431321c14@github.com>

On Thu, 8 Jun 2023 15:51:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Copying an individual doc element using `{@inheritDoc}` never adds meta information on the generated HTML page to indicate where that doc element was copied from. It so happens in this particular case that the doc element's contents are the same in both possible supertypes (BlockingDeque and Queue) and look like this:
>> 
>>     @param e the element to add
>> 
>> If the end result _on the HTML page_ will look identical no mater if I add `@param e {@inheritDoc BlockingDeque}` or not, I will not add it in _this_ PR. This PR's goal is not restructuring the doc comment; in fact, such restructuring would be an anti-goal. It might be a goal for subsequent, area-specific PRs.
>> 
>> Above I said that "`{@inheritDoc}` never adds meta information on the generated HTML page". You might have immediately thought about cases where you saw the "Description copied from interface/class" headings. However, those do not come from `{@inheritDoc}`; those come from empty comments (which inherit their content by omission, if you wish). So those headings DO indicate the source of the complete doc comment.
>> 
>> Now about FileCacheImageOutputStream.java. If I hand't added directed inheritance there, the updated algorithm would've picked a different comment, which wouldn't have been identical to what was picked before:
>> 
>>  - javax.imageio.stream.ImageInputStream#flushBefore
>>     ```
>>      * @param pos a {@code long} containing the length of the
>>      * stream prefix that may be flushed.
>>     ```
>> 
>>  - javax.imageio.stream.ImageOutputStream#flushBefore:
>>     ```
>>      * @param pos a {@code long} containing the length of the
>>      * stream prefix that may be flushed to the destination.
>>     ```
>> Hence, the correction. Does it clarify the matter?
>
> Also, for better or worse, a lone `{@inheritDoc}` never inherits "everything" from a supertype:
> 
> /** {@inheritDoc} */
> 
> It merely inherits the main description of a method. Other elements such as parameter, exception or return information are inherited individually.

Thank you, it helps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1228577519

From aivanov at openjdk.org  Tue Jun 13 19:31:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 Jun 2023 19:31:58 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <YN_XIXW4Pky8-d7C7JXyQiDrT5B98PQjkKd3EhgKoVs=.d8fe969f-d5be-48d6-8814-31e951becf84@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/79d4fbab...563a8761

Looks good to me for client changes.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1477876414

From mchung at openjdk.org  Tue Jun 13 19:44:49 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Jun 2023 19:44:49 GMT
Subject: Integrated: 8305104: Remove the old core reflection implementation
In-Reply-To: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
References: <rww7gOLZN9p8H4yDnqyi_wK8XkxAx6hUZewWewweAXQ=.6d73855e-3040-476c-90ad-c44f3989d592@github.com>
Message-ID: <eXetf8gVFWVXFPPfQBaw5aUkvwNPA4F78CPEH6JP-_o=.e4ea1d47-acfe-42e5-94da-03d15f5223fb@github.com>

On Wed, 7 Jun 2023 21:29:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> JEP 416 integrated in JDK 18 and since then, only a couple minor issues has been reported.  Those issues were related with exception being thrown with invalid arguments.   We propose to remove the old core reflection implementation in JDK 22.  The `-Djdk.reflect.useDirectMethodHandle=false` workaround to revert to the old implementation will stop to work.

This pull request has now been integrated.

Changeset: 9bfe415f
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9bfe415f66cc169249d83fc161c9c4496fe239f6
Stats:     6360 lines in 79 files changed: 24 ins; 6261 del; 75 mod

8305104: Remove the old core reflection implementation

Reviewed-by: dholmes, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14371

From shade at openjdk.org  Tue Jun 13 19:47:51 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Jun 2023 19:47:51 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v2]
In-Reply-To: <uo-d_qVfs1JUZ4DdpBsTYlqKulW58uc8ZgRimwNxg2A=.445093ff-c80f-47a6-9a91-ff717222b3f0@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <uo-d_qVfs1JUZ4DdpBsTYlqKulW58uc8ZgRimwNxg2A=.445093ff-c80f-47a6-9a91-ff717222b3f0@github.com>
Message-ID: <WM2xwTd_wkLBvfzVrQsNKfJoq1qBpjoMHIL8-Lcmb2Y=.9ba60aa4-a96a-4362-9a15-01f00d80714a@github.com>

On Tue, 13 Jun 2023 19:24:08 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK8309688
>  - 8309688: Data race on java.io.ClassCache.strongReferent

I think this data race is benign, because `ClassValue` gives us the required memory semantics. Introducing additional performance hogs seems weird in this case, see below.

Since TSAN complains about the unsynchronized conflicting accesses in `getStrong()` and `clearStrong()`, maybe the better solution would be marking `strong` as `volatile`? It would still be awkward, but we would "only" pay a price of volatile load on a hot path.

src/java.base/share/classes/java/io/ClassCache.java line 43:

> 41:     private static class CacheRef<T> extends SoftReference<T> {
> 42:         private final Class<?> type;
> 43:         private final AtomicReference<T> strongReferent;

This introduces a dereference and additional `AR` instance per `CacheRef`. Maybe it should be `AtomicReferenceFieldUpdater` or a `VarHandle`, assuming there are no bootstrapping issues with this code.

src/java.base/share/classes/java/io/ClassCache.java line 87:

> 85:             // This guarantees progress for at least one thread on every CacheRef.
> 86:             // Clear the strong referent before returning to make the cache soft.
> 87:             T strongVal = ref.getAndClearStrong();

This is a cache, so IIRC, the prevailing case is when CacheRef already exists in the map, and its `strong` is already `null`. So this change introduces an atomic op, which is mostly useless on this path. So we pay a latency price on most `get()`-s without much benefit.

-------------

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14386#pullrequestreview-1477926122
PR Review Comment: https://git.openjdk.org/jdk/pull/14386#discussion_r1228605313
PR Review Comment: https://git.openjdk.org/jdk/pull/14386#discussion_r1228607613

From naoto at openjdk.org  Tue Jun 13 20:24:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 20:24:46 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some suggestions. Should be looked at by translators later.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

Suggestion:

FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 502:

> 500: compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F
> 501: 
> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 504:

> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 956:

> 954: compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF
> 955: 
> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 958:

> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

-------------

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384

From smarks at openjdk.org  Tue Jun 13 20:28:52 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 20:28:52 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
Message-ID: <Vv3t9kOVbqUj1LY4MYaHEAGBuDTr4j-KVb0uz1jKhqE=.d0604d92-ba1e-4a96-a26b-26caefc351b8@github.com>

Hi all,

This pull request contains a backport of commit [e1386856](https://github.com/openjdk/jdk/commit/e138685648fb7a756a05f314af2883ce408abdd2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Stuart Marks on 13 Jun 2023 and was reviewed by Joe Darcy, Brian Burkhalter, Jaikiran Pai and Roger Riggs.

Thanks!

-------------

Commit messages:
 - Backport e138685648fb7a756a05f314af2883ce408abdd2

Changes: https://git.openjdk.org/jdk21/pull/15/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=15&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309882
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/15/head:pull/15

PR: https://git.openjdk.org/jdk21/pull/15

From manc at openjdk.org  Tue Jun 13 20:42:49 2023
From: manc at openjdk.org (Man Cao)
Date: Tue, 13 Jun 2023 20:42:49 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v3]
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <jhmGiatlX5PI5dvXQGTimYD38loE0uXU0-nYA_yO7pM=.8deb0ddf-2366-44eb-996d-50c0316f86bc@github.com>

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Switch to using volatile instead of AtomicReference

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14386/files
  - new: https://git.openjdk.org/jdk/pull/14386/files/3b6d0baf..6270b98e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=01-02

  Stats: 11 lines in 1 file changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14386/head:pull/14386

PR: https://git.openjdk.org/jdk/pull/14386

From rriggs at openjdk.org  Tue Jun 13 20:46:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 13 Jun 2023 20:46:51 GMT
Subject: RFR: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <Vv3t9kOVbqUj1LY4MYaHEAGBuDTr4j-KVb0uz1jKhqE=.d0604d92-ba1e-4a96-a26b-26caefc351b8@github.com>
References: <Vv3t9kOVbqUj1LY4MYaHEAGBuDTr4j-KVb0uz1jKhqE=.d0604d92-ba1e-4a96-a26b-26caefc351b8@github.com>
Message-ID: <KJpVntbWjDs9uthJpdX5rjlBlZ2QlZwhCx8Xj9VhrwM=.0b155040-9dde-4bfd-9be3-af161bd3e952@github.com>

On Tue, 13 Jun 2023 20:20:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1386856](https://github.com/openjdk/jdk/commit/e138685648fb7a756a05f314af2883ce408abdd2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 13 Jun 2023 and was reviewed by Joe Darcy, Brian Burkhalter, Jaikiran Pai and Roger Riggs.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/15#pullrequestreview-1478014485

From weijun at openjdk.org  Tue Jun 13 20:58:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jun 2023 20:58:51 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Some comments:

- `src/java.base/share/classes/sun/launcher/resources/launcher`

`? private`. "private" should be translated, just like the "static" in the 2nd box.

- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`

`compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?

`compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.

`compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".


- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:

`javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.

- `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`

I don't think the new translation is better than the old one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825

From jlu at openjdk.org  Tue Jun 13 21:06:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:25 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <geYM5H0XN5NNvVmRzx5TxgqMaD17xbb7-DCnO_oFVbw=.d00caade-f19d-466e-a71d-7f7cbba183cc@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: use Naoto's recommended ja values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Tue Jun 13 21:06:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:28 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
Message-ID: <Kj4eUHsEVJoYJLTG7eTiBVFd68yRljmoagn0pAEqPdI=.0c0cf9b7-9710-4802-9cce-aad8c0f35a71@github.com>

On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:
> 
>> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
>> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
>> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
> 
> Suggestion:
> 
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234

From smarks at openjdk.org  Tue Jun 13 21:12:34 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 21:12:34 GMT
Subject: Integrated: 8309882: LinkedHashMap adds an errant serializable field
In-Reply-To: <Vv3t9kOVbqUj1LY4MYaHEAGBuDTr4j-KVb0uz1jKhqE=.d0604d92-ba1e-4a96-a26b-26caefc351b8@github.com>
References: <Vv3t9kOVbqUj1LY4MYaHEAGBuDTr4j-KVb0uz1jKhqE=.d0604d92-ba1e-4a96-a26b-26caefc351b8@github.com>
Message-ID: <Ov_EsZg_kiy08b46GEmXBZjDKl82Z7tymdKnqnoZjRs=.aea81e8c-3f28-41d3-9515-cd9814df6ea5@github.com>

On Tue, 13 Jun 2023 20:20:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e1386856](https://github.com/openjdk/jdk/commit/e138685648fb7a756a05f314af2883ce408abdd2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Stuart Marks on 13 Jun 2023 and was reviewed by Joe Darcy, Brian Burkhalter, Jaikiran Pai and Roger Riggs.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f7cd0aec
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/f7cd0aec925d28d0e225017ede372ca7623033ca
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8309882: LinkedHashMap adds an errant serializable field

Reviewed-by: rriggs
Backport-of: e138685648fb7a756a05f314af2883ce408abdd2

-------------

PR: https://git.openjdk.org/jdk21/pull/15

From manc at openjdk.org  Tue Jun 13 21:21:01 2023
From: manc at openjdk.org (Man Cao)
Date: Tue, 13 Jun 2023 21:21:01 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v2]
In-Reply-To: <WM2xwTd_wkLBvfzVrQsNKfJoq1qBpjoMHIL8-Lcmb2Y=.9ba60aa4-a96a-4362-9a15-01f00d80714a@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <uo-d_qVfs1JUZ4DdpBsTYlqKulW58uc8ZgRimwNxg2A=.445093ff-c80f-47a6-9a91-ff717222b3f0@github.com>
 <WM2xwTd_wkLBvfzVrQsNKfJoq1qBpjoMHIL8-Lcmb2Y=.9ba60aa4-a96a-4362-9a15-01f00d80714a@github.com>
Message-ID: <bpJuRDWcPZWGjugaTzvTJ_C65rGnToUxiR4t_OL0zog=.82935d58-0dd2-41fc-8dd7-4952f4d4d85a@github.com>

On Tue, 13 Jun 2023 19:42:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK8309688
>>  - 8309688: Data race on java.io.ClassCache.strongReferent
>
> I think this data race is benign, because `ClassValue` gives us the required memory semantics. Introducing additional performance hogs seems weird in this case, see below.
> 
> Since TSAN complains about the unsynchronized conflicting accesses in `getStrong()` and `clearStrong()`, maybe the better solution would be marking `strong` as `volatile`? It would still be awkward, but we would "only" pay a price of volatile load on a hot path.

Thank you @shipilev! Good point about the cost of extra AtomicReference instance, and slowing down the fast path with a CAS.
Agree that making `strongReferent` `volatile` is better and simpler.

For `AtomicReferenceFieldUpdater` or `VarHandle`, they are more complicated and I don't see much benefit over a simple `volatile` in this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1590038988

From mchung at openjdk.org  Tue Jun 13 21:59:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Jun 2023 21:59:03 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <h9kOxt8HoqLe_MijTo3EcC2t_AlimGfRCso42jvqKIM=.fc39eadd-63e7-4e9c-b364-ea533b0ddc65@github.com>

On Mon, 12 Jun 2023 07:58:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/invoke/MethodType.html

Looks good with minor suggestion.

src/java.base/share/classes/java/lang/Class.java line 930:

> 928:      * distinct classes may share a common name but have different class loaders.
> 929:      * In addition, {@linkplain #isHidden() hidden} classes cannot be discovered
> 930:      * by {@code forName}.

Suggestion:

     * This is not a strict inverse of {@link #forName(String) forName}.
     * For normal classes, distinct classes which share a common name but
     * have different class loaders will have the identical name.
     * In addition, {@linkplain #isHidden() hidden} classes cannot be
     * discovered by {@code forName}.

src/java.base/share/classes/java/lang/Class.java line 4551:

> 4549:      *
> 4550:      * @apiNote
> 4551:      * Distinct classes which share a common name but have different class loaders

I think this apiNote can be dropped.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1233:

> 1231:      * will appear identical when viewed within descriptor strings.
> 1232:      * In addition, the result string is not a bytecode descriptor if this
> 1233:      * method type cannot be {@linkplain ##descriptor described nominally}.

This method is equivalent to `MethodType::descriptorString` which specifies the result descriptor string if a method type descriptor not.  So I think this  sentence may not be needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14411#pullrequestreview-1478104654
PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228733587
PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228732913
PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228732670

From jlu at openjdk.org  Tue Jun 13 22:09:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:40 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Tue Jun 13 22:09:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:43 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
Message-ID: <eUpEuDxtBW4zFIazvfci4moBpPFzPDXyAkpgYNd4F9E=.61170e21-43a3-40d7-a5cc-fc9685a8a2e2@github.com>

On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> Some comments:
> 
> - `src/java.base/share/classes/sun/launcher/resources/launcher`
> 
> `? private`. "private" should be translated, just like the "static" in the 2nd box.
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`
> 
> `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?
> 
> `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.
> 
> `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".
> 
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
> - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> I don't think the new translation is better than the old one.

Thank you for the review @wangweij,

I have addressed these recommendations

>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
>     * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> 
> I don't think the new translation is better than the old one.

For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. 

I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839

From liach at openjdk.org  Tue Jun 13 23:21:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 Jun 2023 23:21:29 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
Message-ID: <eji7FamSMayQY1bMpVRrbwnZqqnTSzpwBGU4pU4S6eo=.845b27a4-cffa-49c1-9234-a9e17938ecf4@github.com>

Hello,

This pull request contains a git cherry-pick of commit openjdk/jdk at 75dcc4ef94d90e4aa7f8ca5eccc97c91492d6eed, which fixed an NPE in IndirectVarHandle.isAccessModeSupported, reproducible via the return value of MethodHandles.filterCoordinates.

The commit being backported was reviewed by Mandy Chung, who also recommended backport of this fix.

Thanks!

-------------

Commit messages:
 - 8307508: IndirectVarHandle.isAccessModeSupported throws NPE

Changes: https://git.openjdk.org/jdk21/pull/16/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=16&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307508
  Stats: 105 lines in 3 files changed: 69 ins; 27 del; 9 mod
  Patch: https://git.openjdk.org/jdk21/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/16/head:pull/16

PR: https://git.openjdk.org/jdk21/pull/16

From smarks at openjdk.org  Tue Jun 13 23:28:06 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 13 Jun 2023 23:28:06 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/332eaf7c...563a8761

I reviewed the changes in java.base. They look fine. I support the notion of keeping these changes minimal, with the narrow goal of keeping the resulting javadoc output the same. There are many opportunities for improving the actual docs, but those should be handled separately.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1478203733

From mchung at openjdk.org  Tue Jun 13 23:51:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 13 Jun 2023 23:51:54 GMT
Subject: RFR: 8307508: IndirectVarHandle.isAccessModeSupported throws NPE
In-Reply-To: <eji7FamSMayQY1bMpVRrbwnZqqnTSzpwBGU4pU4S6eo=.845b27a4-cffa-49c1-9234-a9e17938ecf4@github.com>
References: <eji7FamSMayQY1bMpVRrbwnZqqnTSzpwBGU4pU4S6eo=.845b27a4-cffa-49c1-9234-a9e17938ecf4@github.com>
Message-ID: <I01FWIwDq_1z-D6W8VfOAZh1E5oThSYa3ZH9_4JoYt0=.1e02c757-8478-464b-9413-38b978eb68aa@github.com>

On Tue, 13 Jun 2023 23:14:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hello,
> 
> This pull request contains a git cherry-pick of commit openjdk/jdk at 75dcc4ef94d90e4aa7f8ca5eccc97c91492d6eed, which fixed an NPE in IndirectVarHandle.isAccessModeSupported, reproducible via the return value of MethodHandles.filterCoordinates.
> 
> The commit being backported was reviewed by Mandy Chung, who also recommended backport of this fix.
> 
> Thanks!

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/16#pullrequestreview-1478224229

From liach at openjdk.org  Wed Jun 14 00:05:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 00:05:11 GMT
Subject: Integrated: 8307508: IndirectVarHandle.isAccessModeSupported throws
 NPE
In-Reply-To: <eji7FamSMayQY1bMpVRrbwnZqqnTSzpwBGU4pU4S6eo=.845b27a4-cffa-49c1-9234-a9e17938ecf4@github.com>
References: <eji7FamSMayQY1bMpVRrbwnZqqnTSzpwBGU4pU4S6eo=.845b27a4-cffa-49c1-9234-a9e17938ecf4@github.com>
Message-ID: <nPiBCyb4NUTz0DbRImswnF44LOQ-sqes3GGWUAwRWM0=.71f1538e-519d-464a-9957-e249edb2d638@github.com>

On Tue, 13 Jun 2023 23:14:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hello,
> 
> This pull request contains a git cherry-pick of commit openjdk/jdk at 75dcc4ef94d90e4aa7f8ca5eccc97c91492d6eed, which fixed an NPE in IndirectVarHandle.isAccessModeSupported, reproducible via the return value of MethodHandles.filterCoordinates.
> 
> The commit being backported was reviewed by Mandy Chung, who also recommended backport of this fix.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6711041f
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6711041f55a52e3198f63c53cc165efbb5a27588
Stats:     105 lines in 3 files changed: 69 ins; 27 del; 9 mod

8307508: IndirectVarHandle.isAccessModeSupported throws NPE

Reviewed-by: mchung
Backport-of: 75dcc4ef94d90e4aa7f8ca5eccc97c91492d6eed

-------------

PR: https://git.openjdk.org/jdk21/pull/16

From naoto at openjdk.org  Wed Jun 14 00:09:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 00:09:03 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
Message-ID: <sGkMLbM6Iyp04SnzPdG_CLR9wMlzypOQwrpdy_9iheM=.1f136a3d-f264-42a2-85e5-c4506564eb74@github.com>

On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value

Looks good, Justin

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336

From liach at openjdk.org  Wed Jun 14 00:11:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 00:11:28 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v2]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <YQcpSTVgEOdteUO3hvIKsitr4w2ingSNpWe7yefDFAo=.0d19d0b7-2cf1-4b78-bd67-f28c814a60bf@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/invoke/MethodType.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/Class.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/dd95244d..d30bb237

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Wed Jun 14 00:12:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 00:12:57 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v2]
In-Reply-To: <h9kOxt8HoqLe_MijTo3EcC2t_AlimGfRCso42jvqKIM=.fc39eadd-63e7-4e9c-b364-ea533b0ddc65@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <h9kOxt8HoqLe_MijTo3EcC2t_AlimGfRCso42jvqKIM=.fc39eadd-63e7-4e9c-b364-ea533b0ddc65@github.com>
Message-ID: <h2A8uf91DVnQnyTNsSJYTKq2__YgMb87X5ykrnyxbZY=.7b92fe87-bd3c-4aae-b848-91674cd11693@github.com>

On Tue, 13 Jun 2023 21:54:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/lang/Class.java
>>   
>>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1233:
> 
>> 1231:      * will appear identical when viewed within descriptor strings.
>> 1232:      * In addition, the result string is not a bytecode descriptor if this
>> 1233:      * method type cannot be {@linkplain ##descriptor described nominally}.
> 
> This method is equivalent to `MethodType::descriptorString` which specifies the result descriptor string if a method type descriptor not.  So I think this  sentence may not be needed.

Should we consolidate this distinct class loader note into `descriptorString` too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228827595

From duke at openjdk.org  Wed Jun 14 00:26:10 2023
From: duke at openjdk.org (duke)
Date: Wed, 14 Jun 2023 00:26:10 GMT
Subject: Withdrawn: 8303866: Allow ZipInputStream.readEnd to parse small Zip64
 ZIP files
In-Reply-To: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
References: <crC-fsKgGVQJDCFztDrSLVpCnzs0dOaNbMRfGpC-U7c=.8abd1d6b-f772-4f3d-8b74-ceea9a805384@github.com>
Message-ID: <PHJcr00_rQ-29gsMpQfguuXx1D5MaI65ca-srpPIfEU=.7b55c822-e8aa-487d-a8aa-9e03ab315062@github.com>

On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the number of compressed or uncompressed bytes read from the inflater is larger than the Zip64 magic value.
> 
> While the ZIP format  mandates that the data descriptor `SHOULD be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF`, it also states that `ZIP64 format MAY be used regardless of the size of a file`. For such small entries, the above assumption does not hold.
> 
> This PR augments ZipInputStream.readEnd to also assume 8-byte sizes if the ZipEntry includes a Zip64 extra information field. This brings ZipInputStream into alignment with the APPNOTE format spec:
> 
> 
> When extracting, if the zip64 extended information extra 
> field is present for the file the compressed and 
> uncompressed sizes will be 8 byte values.
> 
> 
> While small Zip64 files with 8-byte data descriptors are not commonly found in the wild, it is possible to create one using the Info-ZIP command line `-fd` flag:
> 
> `echo hello | zip -fd > hello.zip`
> 
> The PR also adds a test verifying that such a small Zip64 file can be parsed by ZipInputStream.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12524

From martin at openjdk.org  Wed Jun 14 00:53:08 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 14 Jun 2023 00:53:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <QnkmxlgG_SEw_psGvx_Dk8XdtnkX5pMLzR3fV70R67A=.406d338a-7b88-435d-8e07-0ab4775d52f2@github.com>
Message-ID: <exFXZi0DI28DB807MgElHWkyA2xeAEybsLjwb3Vm7GI=.c0d93736-d6cb-4a97-bead-cc817b24c2dc@github.com>

On Tue, 13 Jun 2023 23:24:46 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I reviewed the changes in java.base. They look fine. I support the notion of keeping these changes minimal, with the narrow goal of keeping the resulting javadoc output the same. There are many opportunities for improving the actual docs, but those should be handled separately.

I agree with stuart-marks@

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1590262295

From mchung at openjdk.org  Wed Jun 14 01:12:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 01:12:15 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v2]
In-Reply-To: <h2A8uf91DVnQnyTNsSJYTKq2__YgMb87X5ykrnyxbZY=.7b92fe87-bd3c-4aae-b848-91674cd11693@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <h9kOxt8HoqLe_MijTo3EcC2t_AlimGfRCso42jvqKIM=.fc39eadd-63e7-4e9c-b364-ea533b0ddc65@github.com>
 <h2A8uf91DVnQnyTNsSJYTKq2__YgMb87X5ykrnyxbZY=.7b92fe87-bd3c-4aae-b848-91674cd11693@github.com>
Message-ID: <FLSrQY5aJ9RA_qQ3L_1We4CpTrkUD5yNT4vJR55cYHk=.41660236-adbd-4389-810a-6864beddcc2d@github.com>

On Wed, 14 Jun 2023 00:10:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1233:
>> 
>>> 1231:      * will appear identical when viewed within descriptor strings.
>>> 1232:      * In addition, the result string is not a bytecode descriptor if this
>>> 1233:      * method type cannot be {@linkplain ##descriptor described nominally}.
>> 
>> This method is equivalent to `MethodType::descriptorString` which specifies the result descriptor string if a method type descriptor not.  So I think this  sentence may not be needed.
>
> Should we consolidate this distinct class loader note into `descriptorString` too?

This method was added prior to `MethodTypeDesc`.    MethodTypeDesc::ofDescriptor` and `MethodTypeDesc::resolveConstantDesc` would be the alternative way to get back the method type.  I tend to think that `descriptorString` would not need that distinct class loader note (as it would use the Lookup class to resolve instead).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228858321

From martin at openjdk.org  Wed Jun 14 01:23:20 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Wed, 14 Jun 2023 01:23:20 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
Message-ID: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>

On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this long-awaited change to documentation inheritance.
>> 
>> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
>> 
>> ?{@inheritDoc S}
>> 
>> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - fix failing SourceDocTreeScannerTest
>  - Merge branch 'master' into 8285368
>  - feedback: use JavadocTester.out
>    
>    Also, trivially fixes grammar (word order) in a comment.
>  - feedback: remove unduly restrictive warning
>  - suggestion: vocabulary
>  - feedback: DocLint terminology
>  - feedback: use utils directly
>  - Merge branch 'master' into 8285368
>  - feedback: make warning less scary
>  - Disable problematic check
>    
>    This check is well-intended but problematic for JDK API Documentation
>    build, which errors on warnings.
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/0db0007a...563a8761

We don't currently have a way to diff rendered javadoc, like my ancient BlenderRev hack?

src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1534:

> 1532: 
> 1533:     /**
> 1534:      * {@inheritDoc ConcurrentMap}

This clarifies the authors' intent, so is clear progress. 

Semantic difficulties remain:
- it would be nice to somehow declare that we never ever want to inherit doc from AbstractMap (or even at the module level, declare that AbstractFoo classes are specified only for subclass writers, not users).  Private inheritance?
- we never want to inherit AbstractFoo @implNotes
- ConcurrentMap does *not* have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should *not* be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.

-------------

Marked as reviewed by martin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14357#pullrequestreview-1478285774
PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1228861243

From liach at openjdk.org  Wed Jun 14 01:34:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 01:34:40 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v3]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <cV7b1Cp601LZ7OBNrSn4sUtJPZ57jDH6qfbXKPOQb2g=.e868b50b-5f62-40b4-845c-03d2e18e8e65@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/00/java.base/java/lang/invoke/MethodType.html

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:

 - Address the other two review comments
 - Merge branch 'fix/descstring-spec' of https://github.com/liachmodded/jdk into fix/descstring-spec
 - Update src/java.base/share/classes/java/lang/Class.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Merge branch 'master' into fix/descstring-spec
 - 8309819: Fix specification about descriptor inverses in Class and MethodTypeDesc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/d30bb237..c49c809b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=01-02

  Stats: 10995 lines in 323 files changed: 2578 ins; 7312 del; 1105 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Wed Jun 14 01:34:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 01:34:42 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v3]
In-Reply-To: <FLSrQY5aJ9RA_qQ3L_1We4CpTrkUD5yNT4vJR55cYHk=.41660236-adbd-4389-810a-6864beddcc2d@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <h9kOxt8HoqLe_MijTo3EcC2t_AlimGfRCso42jvqKIM=.fc39eadd-63e7-4e9c-b364-ea533b0ddc65@github.com>
 <h2A8uf91DVnQnyTNsSJYTKq2__YgMb87X5ykrnyxbZY=.7b92fe87-bd3c-4aae-b848-91674cd11693@github.com>
 <FLSrQY5aJ9RA_qQ3L_1We4CpTrkUD5yNT4vJR55cYHk=.41660236-adbd-4389-810a-6864beddcc2d@github.com>
Message-ID: <LUZCExkPd9eWmahGqyGHSJGt57diGUEO35bbpxsME2o=.f2e14696-7445-476a-9afb-7d9c919c6f76@github.com>

On Wed, 14 Jun 2023 01:08:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Should we consolidate this distinct class loader note into `descriptorString` too?
>
> This method was added prior to `MethodTypeDesc`.    MethodTypeDesc::ofDescriptor` and `MethodTypeDesc::resolveConstantDesc` would be the alternative way to get back the method type.  I tend to think that `descriptorString` would not need that distinct class loader note (as it would use the Lookup class to resolve instead).

Since the method type descriptor info is available in `descriptorString` but it's a reason `toMethodDescriptorString` is not a strict inverse of `fromMethodDescriptorString`, I propose to reword the notes sections to the following:

     * @apiNote
     * This is not a strict inverse of {@link #fromMethodDescriptorString
     * fromMethodDescriptorString} which requires a method type descriptor
     * (JVMS {@jvms 4.3.3}) and a suitable class loader argument. Two distinct
     * classes which share a common name but have different class loaders will
     * appear identical when viewed within descriptor strings.
     * <p>
     * This method is included for the benefit of applications that must
     * generate bytecodes that process method handles and {@code invokedynamic}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228866290

From mchung at openjdk.org  Wed Jun 14 02:02:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 02:02:11 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v3]
In-Reply-To: <cV7b1Cp601LZ7OBNrSn4sUtJPZ57jDH6qfbXKPOQb2g=.e868b50b-5f62-40b4-845c-03d2e18e8e65@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <cV7b1Cp601LZ7OBNrSn4sUtJPZ57jDH6qfbXKPOQb2g=.e868b50b-5f62-40b4-845c-03d2e18e8e65@github.com>
Message-ID: <qi4YKogoDpoWMkhfn0fcyEE4mJur9ImfXWij9tbAxMI=.b1be6940-5ad0-4367-9900-45c54b2d3fd3@github.com>

On Wed, 14 Jun 2023 01:34:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/02/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/02/java.base/java/lang/invoke/MethodType.html
>
> 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:
> 
>  - Address the other two review comments
>  - Merge branch 'fix/descstring-spec' of https://github.com/liachmodded/jdk into fix/descstring-spec
>  - Update src/java.base/share/classes/java/lang/Class.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Merge branch 'master' into fix/descstring-spec
>  - 8309819: Fix specification about descriptor inverses in Class and MethodTypeDesc

Marked as reviewed by mchung (Reviewer).

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1169:

> 1167:      * resolved by the given loader (or if it is null, on the system class loader).
> 1168:      * <p>
> 1169:      * Note that it is possible to encounter method types which cannot be

BTW this can be converted to `@apiNote` as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14411#pullrequestreview-1478319920
PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228884111

From mchung at openjdk.org  Wed Jun 14 02:02:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 02:02:12 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v3]
In-Reply-To: <LUZCExkPd9eWmahGqyGHSJGt57diGUEO35bbpxsME2o=.f2e14696-7445-476a-9afb-7d9c919c6f76@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <h9kOxt8HoqLe_MijTo3EcC2t_AlimGfRCso42jvqKIM=.fc39eadd-63e7-4e9c-b364-ea533b0ddc65@github.com>
 <h2A8uf91DVnQnyTNsSJYTKq2__YgMb87X5ykrnyxbZY=.7b92fe87-bd3c-4aae-b848-91674cd11693@github.com>
 <FLSrQY5aJ9RA_qQ3L_1We4CpTrkUD5yNT4vJR55cYHk=.41660236-adbd-4389-810a-6864beddcc2d@github.com>
 <LUZCExkPd9eWmahGqyGHSJGt57diGUEO35bbpxsME2o=.f2e14696-7445-476a-9afb-7d9c919c6f76@github.com>
Message-ID: <5-az51TD2ySUSNLU78V2bJk7G6ZJiT4RIkiibwD64rc=.f982872c-2f18-4eaf-93f2-dbab6c04cf13@github.com>

On Wed, 14 Jun 2023 01:26:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This method was added prior to `MethodTypeDesc`.    MethodTypeDesc::ofDescriptor` and `MethodTypeDesc::resolveConstantDesc` would be the alternative way to get back the method type.  I tend to think that `descriptorString` would not need that distinct class loader note (as it would use the Lookup class to resolve instead).
>
> Since the method type descriptor info is available in `descriptorString` but it's a reason `toMethodDescriptorString` is not a strict inverse of `fromMethodDescriptorString`, I propose to reword the notes sections to the following:
> 
>      * @apiNote
>      * This is not a strict inverse of {@link #fromMethodDescriptorString
>      * fromMethodDescriptorString} which requires a method type descriptor
>      * (JVMS {@jvms 4.3.3}) and a suitable class loader argument. Two distinct
>      * classes which share a common name but have different class loaders will
>      * appear identical when viewed within descriptor strings.
>      * <p>
>      * This method is included for the benefit of applications that must
>      * generate bytecodes that process method handles and {@code invokedynamic}.

That's good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228884412

From liach at openjdk.org  Wed Jun 14 02:13:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 02:13:23 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v4]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/02/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/02/java.base/java/lang/invoke/MethodType.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Convert the note in fromDescriptorString to apiNote

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/c49c809b..6950d2ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Wed Jun 14 02:14:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 02:14:58 GMT
Subject: RFR: 8309819: Fix specification about descriptor inverses in Class
 and MethodType [v3]
In-Reply-To: <qi4YKogoDpoWMkhfn0fcyEE4mJur9ImfXWij9tbAxMI=.b1be6940-5ad0-4367-9900-45c54b2d3fd3@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <cV7b1Cp601LZ7OBNrSn4sUtJPZ57jDH6qfbXKPOQb2g=.e868b50b-5f62-40b4-845c-03d2e18e8e65@github.com>
 <qi4YKogoDpoWMkhfn0fcyEE4mJur9ImfXWij9tbAxMI=.b1be6940-5ad0-4367-9900-45c54b2d3fd3@github.com>
Message-ID: <YRQ1DJGzIUftgouPYcFx70FNzTg9ncqK5wUaNSn82T4=.1a28ee62-c747-4205-90e8-d17f84359443@github.com>

On Wed, 14 Jun 2023 01:57:53 GMT, Mandy Chung <mchung 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 five additional commits since the last revision:
>> 
>>  - Address the other two review comments
>>  - Merge branch 'fix/descstring-spec' of https://github.com/liachmodded/jdk into fix/descstring-spec
>>  - Update src/java.base/share/classes/java/lang/Class.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Merge branch 'master' into fix/descstring-spec
>>  - 8309819: Fix specification about descriptor inverses in Class and MethodTypeDesc
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1169:
> 
>> 1167:      * resolved by the given loader (or if it is null, on the system class loader).
>> 1168:      * <p>
>> 1169:      * Note that it is possible to encounter method types which cannot be
> 
> BTW this can be converted to `@apiNote` as well.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1228890193

From dholmes at openjdk.org  Wed Jun 14 05:22:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 05:22:19 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
Message-ID: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>

Updated the version to 22-ea and year to 2024.

The following unpublished changes will also be included in this update:
- [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
- [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
- [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option

The following changes were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
- [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
- [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor

Thanks.

-------------

Commit messages:
 - 8304478: Initial nroff manpage generation for JDK 22

Changes: https://git.openjdk.org/jdk/pull/14462/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304478
  Stats: 140 lines in 28 files changed: 1 ins; 105 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462

PR: https://git.openjdk.org/jdk/pull/14462

From alanb at openjdk.org  Wed Jun 14 06:06:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 06:06:56 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
Message-ID: <xA-WJ6ltYE_xNEGJKXZ2BxIiWrTXbUJGTb1BvSAN97M=.9e3273c6-99ab-4962-9ff2-70769fb00ae0@github.com>

On Wed, 14 Jun 2023 02:13:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert the note in fromDescriptorString to apiNote

src/java.base/share/classes/java/lang/Class.java line 928:

> 926:      * @apiNote
> 927:      * This is not a strict inverse of {@link #forName(String) forName}.
> 928:      * For normal classes, distinct classes which share a common name but

Readers may wonder what "normal classes" means here, it might be simpler to just drop introducing that term and just use the structure from the note removed from descriptorString.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1229028888

From alanb at openjdk.org  Wed Jun 14 06:11:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 06:11:55 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Looks fine.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478549017

From dholmes at openjdk.org  Wed Jun 14 06:11:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 06:11:55 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>
Message-ID: <W9Zscls7-cKxv0kjUNUgbwnOWOEWCiCfaXX9xsXjOug=.3406ce3f-a12c-40b0-aeeb-a2598dcf299e@github.com>

On Wed, 14 Jun 2023 06:08:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updated the version to 22-ea and year to 2024.
>> 
>> The following unpublished changes will also be included in this update:
>> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
>> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
>> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
>> 
>> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
>> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
>> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
>> 
>> Thanks.
>
> Looks fine.

Thanks @AlanBateman !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1590531861

From liach at openjdk.org  Wed Jun 14 07:15:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 07:15:05 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
Message-ID: <_7DsBen6wIz9GOxcP3ZMhDLh_TZBgga5wGMvShqoQx0=.becd5598-a4aa-492e-960a-c6dc8a5db6bb@github.com>

On Wed, 14 Jun 2023 02:13:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert the note in fromDescriptorString to apiNote

In addition, `MethodType` has a section about "nominal descriptor" while that for `Class` resides in `descriptorString`. Should I add additional links there for occurrences of "described nominally" to `Class::descriptorString`, such as to `Class::describeConstable`, like the links in `MethodType`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1590607131

From liach at openjdk.org  Wed Jun 14 07:15:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 07:15:09 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <xA-WJ6ltYE_xNEGJKXZ2BxIiWrTXbUJGTb1BvSAN97M=.9e3273c6-99ab-4962-9ff2-70769fb00ae0@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
 <xA-WJ6ltYE_xNEGJKXZ2BxIiWrTXbUJGTb1BvSAN97M=.9e3273c6-99ab-4962-9ff2-70769fb00ae0@github.com>
Message-ID: <_ntNOVS9mU53IF86I1gOFDqaD4P2yCAxoSY9ZZ2WrE4=.e87396c4-98b4-4fec-bf64-7ecede4813a7@github.com>

On Wed, 14 Jun 2023 06:03:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert the note in fromDescriptorString to apiNote
>
> src/java.base/share/classes/java/lang/Class.java line 928:
> 
>> 926:      * @apiNote
>> 927:      * This is not a strict inverse of {@link #forName(String) forName}.
>> 928:      * For normal classes, distinct classes which share a common name but
> 
> Readers may wonder what "normal classes" means here, it might be simpler to just drop introducing that term and just use the structure from the note removed from descriptorString.

This might wish to refer to "classes that can be described nominally", but same might be said for hidden classes as well. So your suggestion is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1229124490

From asotona at openjdk.org  Wed Jun 14 07:53:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Jun 2023 07:53:41 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v17]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <QHXgQ6QFat4MMVc6C89Fbp7qh4ybxkGmgDJon_V7jD8=.918095e2-94c8-43c3-97df-f91eb5f651f6@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Classfile.StackMapsOption names change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/45c69314..b5fa9ed0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=15-16

  Stats: 15 lines in 10 files changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Wed Jun 14 08:06:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Jun 2023 08:06:34 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v18]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <gnJKz6XSLLLFgvGQKpxpxgA1Jz40gtewmfzp_3Hopq0=.55c096fa-1b43-43bf-bd12-1730a899c291@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  static instance of default Classfile context

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/b5fa9ed0..df432763

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=16-17

  Stats: 19 lines in 2 files changed: 0 ins; 2 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Wed Jun 14 08:06:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 14 Jun 2023 08:06:34 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v18]
In-Reply-To: <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nUmS65qYl7A_fhUuXH-gltqNSzyYEIchSiFe2kkhkrs=.e18d867b-d71c-40f9-91fd-08532f857190@github.com>
 <VTAx6nLQ8RNZcN_2dslIiOD5lUL_ZNEK8PeVO_POknE=.a8a4778d-92e1-4716-80f7-b9987b96506e@github.com>
 <_QQg36e2Gem1E01bN6A6jJXC9x3AfInwMOF3j2kknqQ=.0ebd8190-306f-4e5d-9f32-4c37196e5aec@github.com>
Message-ID: <RYmdOSx5gMTe-SdyDhFkYXWuf4L_RkFIz44DlbYQAEY=.071e3800-2e45-4116-86c5-0b8e66e6e6cb@github.com>

On Thu, 1 Jun 2023 19:25:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 55:
>> 
>>> 53: 
>>> 54:     static Classfile of() {
>>> 55:         return new ClassfileImpl();
>> 
>> We can create a static final field in `ClassfileImpl` holding a default instance equivalent to that created by `new ClassfileImpl()` and have the `of()` factory return that instance instead.
>
> Global static default context will hold global shared cached class hierarchy resolver and that we want to avoid.

As the default CHR stays static instance and it is no more cached, we can have also static holder for the default Classfile instance now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1229182694

From prappo at openjdk.org  Wed Jun 14 09:02:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Jun 2023 09:02:08 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
Message-ID: <1l4rCRZlweJ91CBc-cVcKLnqMAfXZtLThPK2EQ_hk-Y=.e7349c38-3bf7-46c9-95a6-3127959488d3@github.com>

On Wed, 14 Jun 2023 01:19:57 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> We don't currently have a way to diff rendered javadoc, like my ancient BlenderRev hack?

I've generated something you might find helpful: https://cr.openjdk.org/~prappo/8285368/specdiff/overview-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14357#issuecomment-1590779943

From sspitsyn at openjdk.org  Wed Jun 14 09:28:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Jun 2023 09:28:11 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The Serviceability changes look good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478940868

From vladimir.petko at canonical.com  Wed Jun 14 09:36:52 2023
From: vladimir.petko at canonical.com (Vladimir Petko)
Date: Wed, 14 Jun 2023 21:36:52 +1200
Subject: OpenJDK fails to build on mips and mips64el after JDK-8304913
Message-ID: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>

Dear Maintainers,

After JDK-8304913, OpenJDK fails to build on mips[1] and mips64el[2].
Would it be possible to consider adding those architectures to the
Architecture enumeration (see attached patch)/

Best Regards,
 Vladimir.

[1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-21&arch=mips64el&ver=21%7E26ea-2&stamp=1686605119&raw=0
[2] https://buildd.debian.org/status/fetch.php?pkg=openjdk-21&arch=mipsel&ver=21%7E26ea-2&stamp=1686722920&raw=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mipsel.diff
Type: text/x-patch
Size: 2144 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230614/0cbe0bcd/mipsel.diff>

From shade at openjdk.org  Wed Jun 14 09:54:03 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 09:54:03 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v3]
In-Reply-To: <jhmGiatlX5PI5dvXQGTimYD38loE0uXU0-nYA_yO7pM=.8deb0ddf-2366-44eb-996d-50c0316f86bc@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <jhmGiatlX5PI5dvXQGTimYD38loE0uXU0-nYA_yO7pM=.8deb0ddf-2366-44eb-996d-50c0316f86bc@github.com>
Message-ID: <zuZFTPYx41CQQvtEiOGhhrj-7rp7VJVPwP4q4RM3J-Q=.9a4cc0e7-6152-44dc-b922-1b8378e518f6@github.com>

On Tue, 13 Jun 2023 20:42:49 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch to using volatile instead of AtomicReference

Unfortunately, even the single `volatile` on that fast path seems to cost quite a bit :(

On M1:


# CONF=macosx-aarch64-server-release make images test TEST=micro:java.io.ObjectStreamClasses

Benchmark                       Mode  Cnt    Score   Error  Units

# Before
ObjectStreamClasses.testLookup  avgt    8  106,946 ? 0,691  ns/op

# After
ObjectStreamClasses.testLookup  avgt    8  119,984 ? 0,588  ns/op


So again, this looks like a benign data race, and we are penalizing the serialization a bit even with the lightweight fix. This is only to make TSAN happy, right? If so, I would rather keep the code as is.

There are plenty of benign data races in JDK, we should be able to somehow tell TSAN which are actually fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1590869101

From prappo at openjdk.org  Wed Jun 14 10:10:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 14 Jun 2023 10:10:02 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
Message-ID: <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>

On Wed, 14 Jun 2023 01:15:51 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> * we never want to inherit AbstractFoo @implNotes

`@implNote`, `@apiNote` and `@implSpec` can only be inherited via explicit `{@inheritDoc}`:

    @implSpec {@inheritDoc}

> * ConcurrentMap does _not_ have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should _not_ be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.

That state of affairs predates this PR and is merely highlighted by it. Sadly, I'm not sure how JavaDoc can help here. Annotations, contracts, inspections, and doc tests come to mind; but none of these are supported by JavaDoc at the moment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1229354100

From shipilev at amazon.de  Wed Jun 14 11:17:57 2023
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 13:17:57 +0200
Subject: OpenJDK fails to build on mips and mips64el after JDK-8304913
In-Reply-To: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
References: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
Message-ID: <c7189f8a-a427-c0cd-47ca-725f9f0ffef8@amazon.de>

On 14.06.23 11:36, Vladimir Petko wrote
> After JDK-8304913, OpenJDK fails to build on mips[1] and mips64el[2].
> Would it be possible to consider adding those architectures to the
> Architecture enumeration (see attached patch)/

Submitted:
   https://bugs.openjdk.org/browse/JDK-8310019

Are you able to submit a PR against JDK mainline?
Are you able to test the build with the fix on MIPS?

I think you need to model a fix after this one:
   https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb

-- 
Thanks,
-Aleksey




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From shipilev at amazon.de  Wed Jun 14 11:20:18 2023
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 13:20:18 +0200
Subject: OpenJDK fails to build on mips and mips64el after JDK-8304913
In-Reply-To: <c7189f8a-a427-c0cd-47ca-725f9f0ffef8@amazon.de>
References: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
 <c7189f8a-a427-c0cd-47ca-725f9f0ffef8@amazon.de>
Message-ID: <258c76c4-22e3-92d0-a2d6-77bece48c39b@amazon.de>


On 14.06.23 13:17, Aleksey Shipilev wrote:
> On 14.06.23 11:36, Vladimir Petko wrote
>> After JDK-8304913, OpenJDK fails to build on mips[1] and mips64el[2].
>> Would it be possible to consider adding those architectures to the
>> Architecture enumeration (see attached patch)/
>
> Submitted:
> ? https://bugs.openjdk.org/browse/JDK-8310019
>
> Are you able to submit a PR against JDK mainline?
>
Note that you would need the OCA (Oracle Contributor Agreement) in place 
to contribute a fix. If you do not have it and cannot have it in a 
reasonable time, it would be better to leave the PR to someone else, and 
support them with testing.

-- 
Thanks,
-Aleksey




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From coffeys at openjdk.org  Wed Jun 14 11:39:14 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Jun 2023 11:39:14 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate review comments from Roger and tweak some code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/c60a4ed4..55a85e38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 3 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From coffeys at openjdk.org  Wed Jun 14 11:39:17 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Jun 2023 11:39:17 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v2]
In-Reply-To: <K3j_mmDet0ZES72rNs4s0Qu9c6IUReV85uV-V9l0GpI=.19a3f24f-8776-499a-ae82-a91f8ef09e7b@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <K3j_mmDet0ZES72rNs4s0Qu9c6IUReV85uV-V9l0GpI=.19a3f24f-8776-499a-ae82-a91f8ef09e7b@github.com>
Message-ID: <VmqLTwP1Zcs2eX6x6UKcHbkrBsN2QC6BwGgJzbAyexI=.bc16d17d-e503-4e9a-97b4-4dd7b16acf6a@github.com>

On Tue, 13 Jun 2023 13:57:13 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request with a new target base 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 8281658-showsettings-security
>  - Incorporate feedback to date
>  - minor edits, copyright, descriptions etc
>  - Merge branch 'master' into 8281658-showsettings-security
>  - Merge branch 'master' into 8281658-showsettings-security
>  - 8281658

Thanks for the comments Roger. Changes pushed. Some other minor issues corrected also while passing through code.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14394#pullrequestreview-1479167051

From coffeys at openjdk.org  Wed Jun 14 11:39:23 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 14 Jun 2023 11:39:23 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v2]
In-Reply-To: <-t0j8xoVmNzjqVi2SvBGoGUUl0cot5buTNMvDZO1zig=.2fbf648f-785a-4738-b5cb-d882f0eb2eaf@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <K3j_mmDet0ZES72rNs4s0Qu9c6IUReV85uV-V9l0GpI=.19a3f24f-8776-499a-ae82-a91f8ef09e7b@github.com>
 <-t0j8xoVmNzjqVi2SvBGoGUUl0cot5buTNMvDZO1zig=.2fbf648f-785a-4738-b5cb-d882f0eb2eaf@github.com>
Message-ID: <sJYbHCr5yDvVgg9mal1zBnd4HyPLZZ5TO0NqDh029P4=.9b9cb3ea-0f86-45fc-86ff-42d86a182857@github.com>

On Tue, 13 Jun 2023 14:30:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request with a new target base 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 8281658-showsettings-security
>>  - Incorporate feedback to date
>>  - minor edits, copyright, descriptions etc
>>  - Merge branch 'master' into 8281658-showsettings-security
>>  - Merge branch 'master' into 8281658-showsettings-security
>>  - 8281658
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 189:
> 
>> 187:                 } else {
>> 188:                     printSecuritySettings("all");
>> 189:                 }
> 
> Perhaps a slight preference for:
> 
>             var opt = opts.length > 2 ? opts[2].trim() : "all";
>             printSecuritySettings(opt);

fair point. done

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 422:
> 
>> 420:             ostream.println(TWOINDENT + "Provider name: " + p.getName());
>> 421:             if (verbose) {
>> 422:                 ostream.println(TWOINDENT + PROV_INFO_STRING + wrappedString(p.getInfo(), 80));
> 
> Wrapping the args at 80 might still produce line that is quite long.
> Perhaps wrap the string after it was concatenated.

logic updated. I think that's what you were hinting at Roger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229446518
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229447236

From weijun at openjdk.org  Wed Jun 14 11:51:00 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jun 2023 11:51:00 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <QrPZ8A4jabZE1CUMOsCKmEqSWydLDTEkNJTN3zdkF2Y=.efa964f5-3105-43fe-91ff-39173c715a4c@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 378:

> 376:                 ostream.println(TWOINDENT + key + "=");
> 377:                 List.of(val.split(",")).forEach(
> 378:                         s -> ostream.println(THREEINDENT + s.trim() + ","));

Will this print a comma for the last line?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229466419

From weijun at openjdk.org  Wed Jun 14 11:54:59 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jun 2023 11:54:59 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <vVEzRBIPmHe5JZfEUjImT7ehnbBR5mq1H8s8ACIF_ys=.d9b69bc9-79f3-480d-a0b8-80960fb96dd7@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 424:

> 422:                if (!services.isEmpty()) {
> 423:                    services.stream()
> 424:                            .sorted(Comparator.comparing(Provider.Service::getType))

How about sorting by algorithm within the same type?

Another suggestion: adding aliases to output, for example: `Signature: Ed25519 (1.3.101.112, OID.1.3.101.112)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229473561

From jvernee at openjdk.org  Wed Jun 14 12:07:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 12:07:07 GMT
Subject: Integrated: 8309880: Add support for linking libffi on Windows and Mac
In-Reply-To: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
References: <qc0op1z9MLWJ4AcbkPuuTrQZpcQTrxuGilReidZ2JK4=.d2091271-37c5-48f4-b8c9-e72143f79c3a@github.com>
Message-ID: <CGv1RF-JfTJn8aWyiy2Azt4a8SU5fOfv_05N8pNghlo=.9287b9d6-3ebe-49fc-b9ec-6ef1beab06ce@github.com>

On Tue, 13 Jun 2023 12:48:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Update the make/autoconf/lib-ffi.m4 script to support using libffi on Windows and Mac.
> 
> For Windows I had to tweak `fallbackLinker.c` to be able to build: there was an import of `stdint.h` missing, and since it was using `WSAGetLastError` it needed to link against `ws2_32.lib`.
> 
> This PR also contains a fix originally made by @shipilev as part  of: https://github.com/openjdk/jdk/pull/13827 (with a minor tweak), in order to be able to build the fallback linker on mac correctly. I also disabled 3 tests that were failing when using the (libffi-based) fallback linker on that platform.
> 
> ---
> 
> I've updated the `createLibffiBundle.sh` script for Mac, since I got it to work with a devkit, but I didn't manage to do the same for Windows. The steps I took to make my Windows libffi bundle were as follows:
> 1. run 'x64 Native Tools Command Prompt for VS 2022'. cl.exe and link.exe should be on path
> 2. run `ucrt64` (this is one of the shell environments that comes with MSYS2). This should carry over the environment set up by the VS dev prompt.
> 3. then, in the libffi repo root folder:
>   3.a run `autogen.sh`
>   3.b run:
> 
> bash configure \
>   CC="/path/to/libffi/msvcc.sh -m64" \
>   CXX="/path/to/libffi/msvcc.sh -m64" \
>   CPPFLAGS="-DFFI_BUILDING_DLL" \
>   --disable-docs \
>   --prefix=<install dest>
> 
> (`<install dest>` can be whatever you like. That's what you point `--with-libffi` to).
> 
> 4. run `make install`. This should create the `<intstall dest>` directory with the files: `include/ffi.h`, `include/ffitarget.h`, `lib/libffi.dll`. It also creates a `lib/libffi.lib` file, but it is of the wrong file type, `DLL` rather than `LIBRARY`.
> 5. Manually create a working `.lib` file:
>   5.a use `dumpbin /exports libffi.dll` to get a list of exported symbols
>   5.b put them in a `libffi.def` file: `EXPORTS` on the first line, then a symbol on each line following
>   5.c run `lib /def:libffi.def /machine:x64 /out:libffi.lib` to create the right `.lib` file (`lib` is a visual studio tool)
> 
> ---
> 
> Testing:
> - manual testing on Windows/x64 and Mac/AArch64, by running the `jdk_foreign` test suite with `-Djdk.internal.foreign.CABI=FALLBACK` (i.e. using the fallback linker).
> - Linux/x64 Zero test run of the `jdk_foreign` suite
> - Linux/AArch64 Zero build

This pull request has now been integrated.

Changeset: 4c18b9e1
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c18b9e1faba32bd54a5d8b0b3c21b07f694c71b
Stats:     135 lines in 7 files changed: 105 ins; 9 del; 21 mod

8309880: Add support for linking libffi on Windows and Mac

Co-authored-by: Aleksey Shipilev <shade at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/jdk/pull/14446

From weijun at openjdk.org  Wed Jun 14 12:49:09 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 14 Jun 2023 12:49:09 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <GB27jUi0roXw0cNa0MmzEAvmbi89ROVQnLz-hPxdEmE=.ed30bc04-b422-4ea2-ac35-70afe079d979@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 357:

> 355:     private static void printSecuritySummarySettings() {
> 356:         ostream.println("Security settings summary: " + "\n" +
> 357:                 INDENT + "Use \"-XshowSettings:security\" for verbose details\n");

Is it helpful to list sub-options here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229560168

From alanb at openjdk.org  Wed Jun 14 13:17:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 13:17:04 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
Message-ID: <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>

On Tue, 13 Jun 2023 17:57:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replaced it with a ReentrantLock

The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.

On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229601286

From dfuchs at openjdk.org  Wed Jun 14 13:34:59 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Jun 2023 13:34:59 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
 <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
Message-ID: <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>

On Wed, 14 Jun 2023 13:13:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Replaced it with a ReentrantLock
>
>> Replaced it with a ReentrantLock
> 
> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
> 
> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.

One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229625153

From mullan at openjdk.org  Wed Jun 14 14:10:05 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 14 Jun 2023 14:10:05 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <vVEzRBIPmHe5JZfEUjImT7ehnbBR5mq1H8s8ACIF_ys=.d9b69bc9-79f3-480d-a0b8-80960fb96dd7@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
 <vVEzRBIPmHe5JZfEUjImT7ehnbBR5mq1H8s8ACIF_ys=.d9b69bc9-79f3-480d-a0b8-80960fb96dd7@github.com>
Message-ID: <PaALInMcudG6eoVORUxKPBtIAz3Au3_y_MxPc8CKm6U=.424b7902-6bb2-415c-bf3e-b359e9ef114a@github.com>

On Wed, 14 Jun 2023 11:52:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporate review comments from Roger and tweak some code
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 424:
> 
>> 422:                if (!services.isEmpty()) {
>> 423:                    services.stream()
>> 424:                            .sorted(Comparator.comparing(Provider.Service::getType))
> 
> How about sorting by algorithm within the same type?
> 
> Another suggestion: adding aliases to output, for example: `Signature: Ed25519 (1.3.101.112, OID.1.3.101.112)`.

+1 to sorting by algorithm name within same type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1229680104

From roger.riggs at oracle.com  Wed Jun 14 14:25:18 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 14 Jun 2023 10:25:18 -0400
Subject: OpenJDK fails to build on mips and mips64el after JDK-8304913
In-Reply-To: <258c76c4-22e3-92d0-a2d6-77bece48c39b@amazon.de>
References: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
 <c7189f8a-a427-c0cd-47ca-725f9f0ffef8@amazon.de>
 <258c76c4-22e3-92d0-a2d6-77bece48c39b@amazon.de>
Message-ID: <ce5f6d5a-f77e-09b2-0ce2-20054628247b@oracle.com>

Hi,

I can propose a PR with the patch using the issue 8304913; but am unable 
to test it.

Regards, Roger


On 6/14/23 7:20 AM, Aleksey Shipilev wrote:
>
> On 14.06.23 13:17, Aleksey Shipilev wrote:
>> On 14.06.23 11:36, Vladimir Petko wrote
>>> After JDK-8304913, OpenJDK fails to build on mips[1] and mips64el[2].
>>> Would it be possible to consider adding those architectures to the
>>> Architecture enumeration (see attached patch)/
>>
>> Submitted:
>> ? https://bugs.openjdk.org/browse/JDK-8310019
>>
>> Are you able to submit a PR against JDK mainline?
>>
> Note that you would need the OCA (Oracle Contributor Agreement) in 
> place to contribute a fix. If you do not have it and cannot have it in 
> a reasonable time, it would be better to leave the PR to someone else, 
> and support them with testing.
>


From roger.riggs at oracle.com  Wed Jun 14 15:07:04 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 14 Jun 2023 11:07:04 -0400
Subject: OpenJDK fails to build on mips and mips64el after JDK-8304913
In-Reply-To: <ce5f6d5a-f77e-09b2-0ce2-20054628247b@oracle.com>
References: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
 <c7189f8a-a427-c0cd-47ca-725f9f0ffef8@amazon.de>
 <258c76c4-22e3-92d0-a2d6-77bece48c39b@amazon.de>
 <ce5f6d5a-f77e-09b2-0ce2-20054628247b@oracle.com>
Message-ID: <a42e56bc-9fde-f72a-98a5-c980fb9c5a8f@oracle.com>

Please review and test PR 14471.
https://github.com/openjdk/jdk/pull/14471/

Confirm that the Architecture.isLittleEndian() method returns the 
expected values for big and little endian builds.

Regards, Roger

On 6/14/23 10:25 AM, Roger Riggs wrote:
> Hi,
>
> I can propose a PR with the patch using the issue 8304913; but am 
> unable to test it.
>
> Regards, Roger
>
>
> On 6/14/23 7:20 AM, Aleksey Shipilev wrote:
>>
>> On 14.06.23 13:17, Aleksey Shipilev wrote:
>>> On 14.06.23 11:36, Vladimir Petko wrote
>>>> After JDK-8304913, OpenJDK fails to build on mips[1] and mips64el[2].
>>>> Would it be possible to consider adding those architectures to the
>>>> Architecture enumeration (see attached patch)/
>>>
>>> Submitted:
>>> ? https://bugs.openjdk.org/browse/JDK-8310019
>>>
>>> Are you able to submit a PR against JDK mainline?
>>>
>> Note that you would need the OCA (Oracle Contributor Agreement) in 
>> place to contribute a fix. If you do not have it and cannot have it 
>> in a reasonable time, it would be better to leave the PR to someone 
>> else, and support them with testing.
>>
>


From rriggs at openjdk.org  Wed Jun 14 15:11:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 Jun 2023 15:11:28 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913
Message-ID: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>

Add mipsel and mips64el to the Architecture enum.
(Later to be backported to JDK 21)

-------------

Commit messages:
 - Corrected return values of isMIPSEL() and isMIPS64EL().
 - 8310019: MIPS builds are broken after JDK-8304913

Changes: https://git.openjdk.org/jdk/pull/14471/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14471&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310019
  Stats: 20 lines in 2 files changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14471/head:pull/14471

PR: https://git.openjdk.org/jdk/pull/14471

From phh at openjdk.org  Wed Jun 14 15:14:58 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 14 Jun 2023 15:14:58 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913
In-Reply-To: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
Message-ID: <Qf4bdzPDlfHlxtpbZaCzaHDtPx5mvnMaoOrniWLPgZU=.f2eaf4d3-bab4-43fa-8fe1-b2d587dc59d6@github.com>

On Wed, 14 Jun 2023 15:04:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add mipsel and mips64el to the Architecture enum.
> (Later to be backported to JDK 21)

Lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14471#pullrequestreview-1479721055

From liach at openjdk.org  Wed Jun 14 15:23:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 14 Jun 2023 15:23:06 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v11]
In-Reply-To: <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
 <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>
Message-ID: <3_RVLgpKUsTk5lMvUjOATQGf6K3avoh7UkfrZyJww4E=.289c983b-514a-4791-ac45-a68a82f80829@github.com>

On Fri, 9 Jun 2023 18:59:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove meaningless target calls and clear outdated cache as needed
>
> Something was bothering me about the current complexity with method handles and the potential interactions with indirect var handles. Its hard to reason about all the interactions so i needed to take a deeper dive, which i really should have done earlier on. Apologies if we are circling around this many times.
> 
> Since we are now leaning on `LazyInitializingVarHandle::target` to initialize I think we can just do this:
> 
>     private void initialize() {
>         UNSAFE.ensureClassInitialized(refc);
>         this.initialized = true;
>     }
> 
>     @Override
>     public MethodHandle toMethodHandle(AccessMode accessMode) {
>         if (initialized) {
>             return target.toMethodHandle(accessMode);
>         } else {
>             if (isAccessModeSupported(accessMode)) {
>                 MethodHandle mh = target.getMethodHandle(accessMode.ordinal());
>                 // Ensure target on this VH is called to initialize the class
>                 return mh.bindTo(this);
>             }
>             else {
>                 // Ensure an UnsupportedOperationException is thrown
>                 return MethodHandles.varHandleInvoker(accessMode, accessModeType(accessMode)).
>                         bindTo(this);
>             }
>         }
>     }
> 
> 
> However, construction of an indirect VH will result in initialization:
> 
>     private IndirectVarHandle(VarHandle target, Class<?> value, Class<?>[] coordinates,
>                       BiFunction<AccessMode, MethodHandle, MethodHandle> handleFactory, VarForm form, boolean exact) {
>         super(form, exact);
>         this.handleFactory = handleFactory;
>         this.target = target;
>         this.directTarget = target.target();
>         this.value = value;
>         this.coordinates = coordinates;
>     }
> 
> 
> Since this is not performance sensitive code we could check if target is an instance of `LazyInitializingVarHandle` then conditionally get it's target if initialized e.g.,
> 
>    this.directTarget = target instanceof LazyInitializingVarHandle lazyTarget ? lazyTarget.lazyTarget() : target.target();
> 
> ?

@PaulSandoz I have thought about VarHandle a bit more. Why does getMethodHandle accept the direct target of a VarHandle when getMethodHandle itself is already specific to each VarHandle instance? I thought maybe the method handle cache can be elevated to var form so it requires a known receiver VH to be passed, but the MH is not erased, so it doesn't belong to the var form. If we can remove the VarHandle parameter to getMethodHandle, we can simplify the implementations of getMethodHandleUncached and toMethodHandle significantly.

If such a getMethodHandle refactor is desirable, I can accomplish it in a separate patch and make this patch dependent on it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1591461653

From shade at openjdk.org  Wed Jun 14 15:25:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 15:25:55 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913
In-Reply-To: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
Message-ID: <TthqS4wFkVhO5xMOiQtfL5s5TcPmrlKA7Y8ziYLqkD4=.afa5bb89-228a-4109-964e-eb7bd06ed0a4@github.com>

On Wed, 14 Jun 2023 15:04:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add mipsel and mips64el to the Architecture enum.
> (Later to be backported to JDK 21)

Looking at how other platforms do it, I think this patch is incomplete. See e.g. ARM32 patch: https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb

-------------

PR Review: https://git.openjdk.org/jdk/pull/14471#pullrequestreview-1479747976

From rriggs at openjdk.org  Wed Jun 14 15:50:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 14 Jun 2023 15:50:19 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v2]
In-Reply-To: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
Message-ID: <103FVTgM5APhM8RQElJU7KmU3wyvAXrFFqOvBEmokMw=.f33e5aac-5b51-4494-ae10-fa1013836cf7@github.com>

> Add mipsel and mips64el to the Architecture enum.
> (Later to be backported to JDK 21)

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add tests for MIPSEL and MIPS64EL

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14471/files
  - new: https://git.openjdk.org/jdk/pull/14471/files/4c18377a..ce8d31fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14471&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14471&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14471/head:pull/14471

PR: https://git.openjdk.org/jdk/pull/14471

From shade at openjdk.org  Wed Jun 14 16:00:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Jun 2023 16:00:12 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v2]
In-Reply-To: <103FVTgM5APhM8RQElJU7KmU3wyvAXrFFqOvBEmokMw=.f33e5aac-5b51-4494-ae10-fa1013836cf7@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <103FVTgM5APhM8RQElJU7KmU3wyvAXrFFqOvBEmokMw=.f33e5aac-5b51-4494-ae10-fa1013836cf7@github.com>
Message-ID: <z4M_Y9NZ4ab-9KKLv-K5I96MKiKiOmvcXu7KN2kxAg0=.e8c02b13-61b3-42c6-9352-72eb6c8ae6aa@github.com>

On Wed, 14 Jun 2023 15:50:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add mipsel and mips64el to the Architecture enum.
>> (Later to be backported to JDK 21)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add tests for MIPSEL and MIPS64EL

Looks fine. We want/need the original reporter to confirm it works now?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14471#pullrequestreview-1479818113

From naoto at openjdk.org  Wed Jun 14 16:07:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 16:07:59 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v2]
In-Reply-To: <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <I1w5uzuRAmk1eTqIwe1IMrxz5J39yZN3YYuMjHkYFTU=.cfe0ec7c-edd7-46e2-8444-0192d88022c8@github.com>
 <hGqRm8mQ8Fit1yhFhVVJt2UnUMq1d2U3BgEUhXYJlWI=.ebe2f332-86b1-4e08-8e25-c39dba2dd87d@github.com>
 <ECgM_b7fO1Hcxcfv79KxBGH6Q8ooCSS-NFZCjNUTCDs=.e6a92f6c-2e6c-4fda-88d3-570f04e98df7@github.com>
 <IRgvtRmbZ7SoAby8TV4ARmi5K1022K24tc1v85RBexs=.f09c4d0e-1f50-4f6c-8001-d2c687848c78@github.com>
 <_xpukvI9UxxknHQYdoBKxkt98mUJu1FCli6BdnxJylE=.a8c63915-2ae4-4ce6-ad73-e6ee42f5db0a@github.com>
Message-ID: <95kv6OUnZpcUEpnvAyZZYgeA7JTMmuau8NMBlb62u0Y=.a47b5d21-669c-4633-93f9-eaaf27657109@github.com>

On Wed, 14 Jun 2023 13:29:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Replaced it with a ReentrantLock
>> 
>> The concern is that this is a system-wide lock and so creates the potential for contention when many threads are bashing on Locale.of and other methods. Moving to use the JDK's ReferenceKeyMap with a CHM, or roll something similar, would avoid that but I can't helping feeling that the lookup is already a bit complicated. Right now, obtaining a Locale will create a non-normalized BaseLocale to use as a key, use the key to get (or compute) the normalized BaseLocale, then the normalized BaseLocale as a key for the Locale cache. Since it's early in JDK 22 it makes me wonder if we should step back and re-think this.
>> 
>> On the WHM, then it is a bit surprising that a Locales don't keep the non-normalized BaseLocale reachable. I assume this means that entries will be expunged from the CACHE if there is a reference processing between lookups. Also using weak refs makes it harder to reason about when the other part of the caching (in LocaleObjectCache) is used soft refs. I think this is another reason to think about a larger overhaul.
>
> One possibility would be to have the whole cache be soft-referenced, instead of individually weak-referencing the keys.
> Something like Reference<Map<BaseLocale, BaseLocale>> where Reference is a SoftReference and Map is a ConcurrentHashMap. 
> But then you'd have to deal with a non-final field for the reference to the cache, and creating a new map and a new cache (and new SoftReference) when the reference to the cache gets cleared, and dealing with potential race conditions at that time.

Jim's `java.lang.runtime.ReferenceKeyMap` would be a possible solution for it, although it is currently package private. But I will need to think about it more as Alan suggests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1229857996

From jlu at openjdk.org  Wed Jun 14 16:25:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Jun 2023 16:25:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
Message-ID: <i2xpAM4Cbkg3wxLwU6xXUsAerpA3w3n1wHE9BFFtI0Q=.49a5cd2b-b201-4322-af3a-dd198470a544@github.com>

On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
>> 
>>> 138: 
>>> 139: # 0: type, 1: name
>>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
>> 
>> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.
>
> I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let me ask about this specific instance.

The language specialist confirmed the double quotes are locale specific for de.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212

From mchung at openjdk.org  Wed Jun 14 16:30:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 16:30:57 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
Message-ID: <WdtYgLXKm4iCvBKsiKNNW9UTuHCoqk4kvxANpUnQ2kg=.ff0df4c7-3eb0-4e8f-b29d-297b66f7b31c@github.com>

On Wed, 14 Jun 2023 02:13:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert the note in fromDescriptorString to apiNote

`Class::descriptorString` specifies clearly whether the result string is a field descriptor and whether it can be used to produce `ClassDesc` for all cases.   I feel that "described nominally" is quite clear what it means.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1591606018

From mchung at openjdk.org  Wed Jun 14 16:30:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 16:30:59 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <_ntNOVS9mU53IF86I1gOFDqaD4P2yCAxoSY9ZZ2WrE4=.e87396c4-98b4-4fec-bf64-7ecede4813a7@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
 <xA-WJ6ltYE_xNEGJKXZ2BxIiWrTXbUJGTb1BvSAN97M=.9e3273c6-99ab-4962-9ff2-70769fb00ae0@github.com>
 <_ntNOVS9mU53IF86I1gOFDqaD4P2yCAxoSY9ZZ2WrE4=.e87396c4-98b4-4fec-bf64-7ecede4813a7@github.com>
Message-ID: <eC_l0ZU3W00hK2suUgAeLFbjNI50A9OIU3_N4sv_yCw=.a3f03f7a-d8b1-4ba3-99f0-b54c62bdeb6f@github.com>

On Wed, 14 Jun 2023 07:12:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 928:
>> 
>>> 926:      * @apiNote
>>> 927:      * This is not a strict inverse of {@link #forName(String) forName}.
>>> 928:      * For normal classes, distinct classes which share a common name but
>> 
>> Readers may wonder what "normal classes" means here, it might be simpler to just drop introducing that term and just use the structure from the note removed from descriptorString.
>
> This might wish to refer to "classes that can be described nominally", but same might be said for hidden classes as well. So your suggestion is better.

What about:


     * This is not a strict inverse of {@link #forName(String) forName}.
     * Distinct classes which share a common name but have different class
     * loaders will have the identical name. {@linkplain #isHidden() Hidden}
     * classes cannot be discovered by {@code forName}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1229888943

From aph at openjdk.org  Wed Jun 14 16:58:17 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 14 Jun 2023 16:58:17 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v6]
In-Reply-To: <Bn2pJA8m_Y5vcfNlOZEeFE8zdpsO87fgTOiQJPpkvpQ=.bca324da-663a-4188-8abe-b8a42c4fb8ee@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <AVxbiBLRheDJc_UeRWIaGoc3qyrkhiU4mQPQJGgd0WQ=.cabe90a4-9211-4921-8d85-e547e233b2b5@github.com>
 <Bn2pJA8m_Y5vcfNlOZEeFE8zdpsO87fgTOiQJPpkvpQ=.bca324da-663a-4188-8abe-b8a42c4fb8ee@github.com>
Message-ID: <Y7YbetYlUcOQVcz0F4v5TKldlJr_JnjVl_Mhi-IUOZs=.91765ef2-33ad-4ed1-a497-96c5be43e9a0@github.com>

On Tue, 13 Jun 2023 15:50:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation changes look good.
> 
> The update to test looks okay too although I would like to see if we can do better in SVC and STS when there is a SO.

That would be nice, but it's something of a can of worms. 

> In passing, I think all usages of tlr should be replaced with ThreadLocalRandom.current().

OK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1591652458

From mchung at openjdk.org  Wed Jun 14 18:43:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 18:43:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <K4hEuZ0tOGwmXOhjV3akufh4EWm7Ssj9tehW3-UV3uc=.804e1b1b-c860-4529-ae56-ada4ce326c95@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480088199

From lancea at openjdk.org  Wed Jun 14 18:51:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Jun 2023 18:51:10 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <pun50s0fljjG983cJ983N7coIJWbOdKdcT6LhkbOdK4=.bad2c612-56ee-45c9-a6c3-89203e19aa4d@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480097706

From acobbs at openjdk.org  Wed Jun 14 19:23:59 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 Jun 2023 19:23:59 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The following changes, to javac.1, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22

Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?

To be clear, I'm not blaming you for this situation - the problem is that there exist "closed sources" at all (why??) - but that doesn't seem like a good excuse for deleting work without a clear path to ensuring it is preserved (and the simplest way to do that is to do it yourself). Obviously I'd do it myself if I could.

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1591849483

From duke at openjdk.org  Wed Jun 14 20:16:18 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 14 Jun 2023 20:16:18 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v3]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <fuLc6ceE3EZi6OngbRXYl_rtbvVzAGmWCqqZRWc2zPQ=.5e00db4f-d9e7-4e71-a55e-0d337d2fbb98@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

Oliver Kopp has updated the pull request with a new target base 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 fix-8240567
 - Remove "final" at "enabled" - not part of the point of this PR
 - Remove comments
 - 8240567: MethodTooLargeException thrown while creating a jlink image
   
   Co-authored-by: Christoph Schwentker <siedlerkiller at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/9d4142cc..e158a2c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=01-02

  Stats: 11376 lines in 386 files changed: 2834 ins; 7354 del; 1188 mod
  Patch: https://git.openjdk.org/jdk/pull/14408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14408/head:pull/14408

PR: https://git.openjdk.org/jdk/pull/14408

From duke at openjdk.org  Wed Jun 14 20:16:20 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 14 Jun 2023 20:16:20 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v2]
In-Reply-To: <bfpF0d9eG0aNmZzhZfrU0meK5O9O36KVKcSPtwck3p0=.c0617ed7-dc36-49a2-bad7-1ac42acf5551@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <bfpF0d9eG0aNmZzhZfrU0meK5O9O36KVKcSPtwck3p0=.c0617ed7-dc36-49a2-bad7-1ac42acf5551@github.com>
Message-ID: <QwgvmnMJ5wQsu-2XfShIPIlUD1OyJ67coyWPCj0XMPk=.7ae71b88-512d-4736-be95-476384e5b701@github.com>

On Mon, 12 Jun 2023 05:47:41 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>> 
>> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.
>
> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove "final" at "enabled" - not part of the point of this PR
>  - Remove comments

@asotona At https://bugs.openjdk.org/browse/JDK-8240567?focusedCommentId=14588425&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14588425 you asked the following:
    
> Did you consider also constant pool 65k entries size limit? 
When module descriptors are split into multiple methods due to their code size, the system modules plugin may soon hit the class constant pool limit of 65k unique entries

I don't have a bugs.openjdk.org account; thus I reply here.

The constant pool is also an "interesting" limitation. We did not address it (yet) because the current patch is IMHO a major step forward: It unblocks feature development of our software: We can add new external libraries ?

Looking more close to that limit and the implications to the patch: I understand that this limit affects the number of methods in a class. If this is correct, let's assume that a project requires thousands of modules and would use half of the limit for the generation of the module descriptors. That would result in roughly 32,000 methods. The patch puts 50 module descriptors in one method. Assuming 32,000 methods leads to ~1.6 million modules for a Java program.

Currently, our project [JabRef](https://github.com/jabref/jabref/) has a total number of ~130 modules. We cannot move forward with our release as we cannot add new dependencies. We hope that other projects with many modules will benefit from this patch as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1591903575

From ascarpino at openjdk.org  Wed Jun 14 21:27:00 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 14 Jun 2023 21:27:00 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <QWPtSM0PND0RZu4w59JJiGvyIT8AB7bI4BvShgxQbmw=.8fde569b-823b-47fa-ba23-dab87b8fa6e5@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

I would recommend using the service syntax that is similar to Preferred Provider and is also similar to a [services control](https://mail.openjdk.org/pipermail/security-dev/2023-May/035819.html) on the security mailing list that is not yet approved.  `Signature.SHA1withRSA` instead of `Signature : SHA1withRSA`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1592008732

From dholmes at openjdk.org  Wed Jun 14 21:31:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 21:31:00 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
Message-ID: <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>

On Wed, 14 Jun 2023 19:21:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?

@archiecobbs  we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. It should have been handled when the original PRs were done. It needs to be handled as a separate issue and PR though - whether that were to happen before or after this PR is somewhat immaterial.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014026

From dholmes at openjdk.org  Wed Jun 14 21:31:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 21:31:03 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>
Message-ID: <RN3gF2SqClnHGc2V8rBkDumSLXd4Tab0-oCaO3rQ0TA=.d59d4324-c7b6-44e8-8be6-088e7c0b3a52@github.com>

On Wed, 14 Jun 2023 09:25:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Updated the version to 22-ea and year to 2024.
>> 
>> The following unpublished changes will also be included in this update:
>> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
>> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
>> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
>> 
>> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
>> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
>> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
>> 
>> Thanks.
>
> The Serviceability changes look good.
> Thanks,
> Serguei

Thanks for the additional reviews @sspitsyn , @LanceAndersen  and @mlchung !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014943

From acobbs at openjdk.org  Wed Jun 14 21:40:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 Jun 2023 21:40:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
 <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>
Message-ID: <okk5G3GqQV8MOBuFOOfytJMRx9WMoL0s19P8GBKXnUE=.ad36d5f6-ec18-4e0e-824a-bef478f66bd5@github.com>

On Wed, 14 Jun 2023 21:28:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?
> 
> @archiecobbs we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. 

OK thanks. Putting my trust in you :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592023452

From jvernee at openjdk.org  Wed Jun 14 22:03:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 22:03:01 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check
Message-ID: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>

Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.

Testing: `jdk_foreign` test suite

-------------

Commit messages:
 - Add root layout alignment check to varHandle and sliceHandle

Changes: https://git.openjdk.org/jdk/pull/14475/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310053
  Stats: 71 lines in 3 files changed: 55 ins; 7 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14475/head:pull/14475

PR: https://git.openjdk.org/jdk/pull/14475

From dholmes at openjdk.org  Wed Jun 14 22:11:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 22:11:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <KXanlp-XRQ3wM7NK9pRkfFdQdHZB6UzXYETEpBqd2J4=.08b3dc2b-34df-481f-b99a-9a14b715e6de@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

I've filed https://bugs.openjdk.org/browse/JDK-8310067 for the javac manpage fixup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592056009

From jvernee at openjdk.org  Wed Jun 14 22:20:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 22:20:00 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v2]
In-Reply-To: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
Message-ID: <jmxVLC9SG6I8fvbaA5qhM9E7uBSdt_OlcOxl-_E82D8=.e5ad17b6-72df-4c83-beb3-cf497753597c@github.com>

> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
> 
> Testing: `jdk_foreign` test suite

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  add note to sliceHandle too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14475/files
  - new: https://git.openjdk.org/jdk/pull/14475/files/f9845749..1abe7581

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14475/head:pull/14475

PR: https://git.openjdk.org/jdk/pull/14475

From jvernee at openjdk.org  Wed Jun 14 22:28:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 22:28:38 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v3]
In-Reply-To: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
Message-ID: <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>

> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
> 
> Testing: `jdk_foreign` test suite

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  formatting

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14475/files
  - new: https://git.openjdk.org/jdk/pull/14475/files/1abe7581..668e9c37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14475/head:pull/14475

PR: https://git.openjdk.org/jdk/pull/14475

From mcimadamore at openjdk.org  Wed Jun 14 22:52:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 14 Jun 2023 22:52:59 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v3]
In-Reply-To: <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
Message-ID: <TQ8v-pCidb1BURVPJzkHJUr4t5095a3Ln_tNRPvGt1U=.62d4adc7-c3db-47f4-b6c6-87ce161bf2a6@github.com>

On Wed, 14 Jun 2023 22:28:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting

Marked as reviewed by mcimadamore (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 200:

> 198: 
> 199:         VarHandle handle = Utils.makeSegmentViewVarHandle(valueLayout);
> 200:         handle = MethodHandles.collectCoordinates(handle, 1, offsetHandle());

nice simplification!

test/jdk/java/foreign/TestLayoutPaths.java line 152:

> 150:             String expectedMessage = "Target offset incompatible with alignment constraints: " + struct.byteAlignment();
> 151: 
> 152:             try {

Can assertThrows be used to simplify this pattern?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14475#pullrequestreview-1480416811
PR Review Comment: https://git.openjdk.org/jdk/pull/14475#discussion_r1230245077
PR Review Comment: https://git.openjdk.org/jdk/pull/14475#discussion_r1230246478

From mcimadamore at openjdk.org  Wed Jun 14 23:19:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 14 Jun 2023 23:19:55 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v3]
In-Reply-To: <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
Message-ID: <q5smiQE2YLdw0XzxL4EXuno-OXug9qqOP1hIOAoauGM=.41aa8300-5c8e-4e8d-9cbe-ab5382ec0d79@github.com>

On Wed, 14 Jun 2023 22:28:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 383:

> 381:      * {@code 0 <= x_i < b_i}, where {@code 1 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.
> 382:      * <p>
> 383:      * The accessed address must be <a href="MemorySegment.html#segment-alignment">aligned</a> according to the {@linkplain

Very nice and clear!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14475#discussion_r1230261542

From jvernee at openjdk.org  Wed Jun 14 23:30:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 23:30:56 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v3]
In-Reply-To: <TQ8v-pCidb1BURVPJzkHJUr4t5095a3Ln_tNRPvGt1U=.62d4adc7-c3db-47f4-b6c6-87ce161bf2a6@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
 <TQ8v-pCidb1BURVPJzkHJUr4t5095a3Ln_tNRPvGt1U=.62d4adc7-c3db-47f4-b6c6-87ce161bf2a6@github.com>
Message-ID: <-fmv8_HnFXQZEyr-eE8-emy6oKPPc4KZS5gXHpC0AqQ=.8157e908-12dc-4c77-886b-3277b3bed9f5@github.com>

On Wed, 14 Jun 2023 22:48:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting
>
> test/jdk/java/foreign/TestLayoutPaths.java line 152:
> 
>> 150:             String expectedMessage = "Target offset incompatible with alignment constraints: " + struct.byteAlignment();
>> 151: 
>> 152:             try {
> 
> Can assertThrows be used to simplify this pattern?

Yeah. I thought `assertThrows` was only a junit thing, but it looks like TestNG also has an `expectThrows` which does the same and returns the thrown exception so that we can check the message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14475#discussion_r1230267718

From jvernee at openjdk.org  Wed Jun 14 23:38:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 23:38:01 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v4]
In-Reply-To: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
Message-ID: <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>

> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
> 
> Testing: `jdk_foreign` test suite

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Drop alignment checks from accessed elements
  Use expectThrows

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14475/files
  - new: https://git.openjdk.org/jdk/pull/14475/files/668e9c37..99076262

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=02-03

  Stats: 31 lines in 2 files changed: 13 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14475/head:pull/14475

PR: https://git.openjdk.org/jdk/pull/14475

From jvernee at openjdk.org  Wed Jun 14 23:38:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 14 Jun 2023 23:38:03 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v3]
In-Reply-To: <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <nJdvgzunFfMV_uuvRAKnBTTH7FV6sPZUyq4SZinbItI=.c5793238-4581-465f-827d-0077336c60d6@github.com>
Message-ID: <CtR39LIZOBZGL6IIE2dbb-V4BUsfvevfvEdvy9vAlJU=.dc67221f-56bc-4661-8ca3-5c0e17431b44@github.com>

On Wed, 14 Jun 2023 22:28:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting

I've switched to `expectThrows`. As discussed offline, I've also dropped the alignment check from the inner accessed element, as this is redundant due to layouts enforcing alignment of nested elements already. So, if the root layout is aligned, so is the element. (this turned out to be simper than I initially thought)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14475#issuecomment-1592124134

From mcimadamore at openjdk.org  Wed Jun 14 23:52:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 14 Jun 2023 23:52:56 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v4]
In-Reply-To: <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
Message-ID: <k0po5TcvlcSbkh0WUqGjkIquF8SgwefHTDhRewgG8TI=.decc3851-8e63-497d-bbbd-100974f31882@github.com>

On Wed, 14 Jun 2023 23:38:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop alignment checks from accessed elements
>   Use expectThrows

Bonus points!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14475#pullrequestreview-1480461139

From manc at openjdk.org  Thu Jun 15 00:05:32 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 00:05:32 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v4]
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <5gSALQFwQ_s1cFqDJ8qnazOp2Qsekj0jrY-mqc-KWdQ=.24453c4b-7fa7-456d-9fdb-5237fa15dbda@github.com>

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Removed volatile and comment about the benign race

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14386/files
  - new: https://git.openjdk.org/jdk/pull/14386/files/6270b98e..e9b2e0f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=02-03

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14386/head:pull/14386

PR: https://git.openjdk.org/jdk/pull/14386

From manc at openjdk.org  Thu Jun 15 00:10:57 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 00:10:57 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v4]
In-Reply-To: <5gSALQFwQ_s1cFqDJ8qnazOp2Qsekj0jrY-mqc-KWdQ=.24453c4b-7fa7-456d-9fdb-5237fa15dbda@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <5gSALQFwQ_s1cFqDJ8qnazOp2Qsekj0jrY-mqc-KWdQ=.24453c4b-7fa7-456d-9fdb-5237fa15dbda@github.com>
Message-ID: <R1fpgCZ009TPuHFILvkPQhuxoTSt_kIAkK6tM95uEzM=.19ac3d4c-27e6-4854-b49c-7b2fc3e603fd@github.com>

On Thu, 15 Jun 2023 00:05:32 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed volatile and comment about the benign race

Thanks for the benchmarking. I was unaware of the microbenchmark `java.io.ObjectStreamClasses`.
The performance penalty is likely related to aarch64 being slower on volatile load. I see no observable difference on x86-64:

Benchmark                       Mode  Cnt    Score    Error  Units
# Before
ObjectStreamClasses.testLookup  avgt    8  230.255 ? 10.540  ns/op

# After
ObjectStreamClasses.testLookup  avgt    8  230.291 ? 19.369  ns/op


Anyway, this race does look benign and I'm OK with just documenting this benign race, and suppress it in TSAN. Updated this PR to a comment-only change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1592147495

From manc at openjdk.org  Thu Jun 15 00:16:15 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 00:16:15 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v5]
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <73JNCEqvi2dImWjWk71KRB6gQr0vigHz4RebqahvSWo=.c8cb1742-9fa4-41c6-a63b-78ea3ee97682@github.com>

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK8309688
 - Removed volatile and comment about the benign race
 - Switch to using volatile instead of AtomicReference
 - Merge branch 'master' into JDK8309688
 - 8309688: Data race on java.io.ClassCache.strongReferent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14386/files
  - new: https://git.openjdk.org/jdk/pull/14386/files/e9b2e0f2..6da51c22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=03-04

  Stats: 7016 lines in 163 files changed: 465 ins; 6313 del; 238 mod
  Patch: https://git.openjdk.org/jdk/pull/14386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14386/head:pull/14386

PR: https://git.openjdk.org/jdk/pull/14386

From mcimadamore at openjdk.org  Thu Jun 15 00:26:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 Jun 2023 00:26:11 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v4]
In-Reply-To: <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
Message-ID: <sUgum0-fxWEc-V2hxJIZrBhwtrLAvEJQSRXxOCSAOTc=.beb85d19-ea2f-42b4-a7c7-28f705b1ad8a@github.com>

On Wed, 14 Jun 2023 23:38:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop alignment checks from accessed elements
>   Use expectThrows

I'm wondering... for dereference path elements, we already perform a root layout check as part of the memory segment expansion - e.g. we use the target layout to resize the segment (and perform an alignment check). So in that case there would still be duplicate alignment checks.

In such cases, we need to make sure that either (a) only the first var handle in the dereference chain gets the proper alignment adaptation on the input segment or that (b) they all do, but then we omit the alignment checks that are generated as part of calling VH::get on the address layout (but that might be harder to do, as that logic is shared). I think (a) is probably simplest - just have a boolean in the path which says whether a path is nested into some other path using a dereference and, if so, omit the alignment adaptation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14475#issuecomment-1592156216

From liach at openjdk.org  Thu Jun 15 02:04:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 Jun 2023 02:04:12 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <eC_l0ZU3W00hK2suUgAeLFbjNI50A9OIU3_N4sv_yCw=.a3f03f7a-d8b1-4ba3-99f0-b54c62bdeb6f@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
 <xA-WJ6ltYE_xNEGJKXZ2BxIiWrTXbUJGTb1BvSAN97M=.9e3273c6-99ab-4962-9ff2-70769fb00ae0@github.com>
 <_ntNOVS9mU53IF86I1gOFDqaD4P2yCAxoSY9ZZ2WrE4=.e87396c4-98b4-4fec-bf64-7ecede4813a7@github.com>
 <eC_l0ZU3W00hK2suUgAeLFbjNI50A9OIU3_N4sv_yCw=.a3f03f7a-d8b1-4ba3-99f0-b54c62bdeb6f@github.com>
Message-ID: <SPtd9clYTdTjRymeAb9wBWlMLXBe--M7n4M5JsYY-iA=.a69eb901-47b2-4538-ab40-92133b19e8fd@github.com>

On Wed, 14 Jun 2023 16:28:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This might wish to refer to "classes that can be described nominally", but same might be said for hidden classes as well. So your suggestion is better.
>
> What about:
> 
> 
>      * This is not a strict inverse of {@link #forName(String) forName}.
>      * Distinct classes which share a common name but have different class
>      * loaders will have the identical name. {@linkplain #isHidden() Hidden}
>      * classes cannot be discovered by {@code forName}.

On a second thought, these are all `getName` results that cannot be parsed by `forName`:
 - Primitive type names
 - Hidden class names
 - Arrays whose component types are hidden classes

I suggest:

     * This is not a strict inverse of {@link #forName(String) forName(String)}.
     * Distinct classes which share a common name but have different class
     * loaders will have the identical name. {@linkplain #isPrimitive()
     * Primitive types}, {@linkplain #isHidden() hidden} classes, and arrays
     * with hidden class as element types cannot be discovered by {@code forName}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1230335235

From mchung at openjdk.org  Thu Jun 15 02:16:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 15 Jun 2023 02:16:59 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v4]
In-Reply-To: <SPtd9clYTdTjRymeAb9wBWlMLXBe--M7n4M5JsYY-iA=.a69eb901-47b2-4538-ab40-92133b19e8fd@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <-iFqJnlmI1a0fdCJ_j3sX2EKFDE27CaRR8LIt9_mYlI=.89481525-5764-4f41-91ce-ecafc1f16624@github.com>
 <xA-WJ6ltYE_xNEGJKXZ2BxIiWrTXbUJGTb1BvSAN97M=.9e3273c6-99ab-4962-9ff2-70769fb00ae0@github.com>
 <_ntNOVS9mU53IF86I1gOFDqaD4P2yCAxoSY9ZZ2WrE4=.e87396c4-98b4-4fec-bf64-7ecede4813a7@github.com>
 <eC_l0ZU3W00hK2suUgAeLFbjNI50A9OIU3_N4sv_yCw=.a3f03f7a-d8b1-4ba3-99f0-b54c62bdeb6f@github.com>
 <SPtd9clYTdTjRymeAb9wBWlMLXBe--M7n4M5JsYY-iA=.a69eb901-47b2-4538-ab40-92133b19e8fd@github.com>
Message-ID: <xY9VpdhZ_WuJdZk5cB835GAClRmi2J3Mbus4VmZ6gbc=.3fd5b72b-5845-4031-b410-d44890dcd745@github.com>

On Thu, 15 Jun 2023 02:01:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> What about:
>> 
>> 
>>      * This is not a strict inverse of {@link #forName(String) forName}.
>>      * Distinct classes which share a common name but have different class
>>      * loaders will have the identical name. {@linkplain #isHidden() Hidden}
>>      * classes cannot be discovered by {@code forName}.
>
> On a second thought, these are all `getName` results that cannot be parsed by `forName`:
>  - Primitive type names
>  - Hidden class names
>  - Arrays whose component types are hidden classes
> 
> I suggest:
> 
>      * This is not a strict inverse of {@link #forName(String) forName(String)}.
>      * Distinct classes which share a common name but have different class
>      * loaders will have the identical name. {@linkplain #isPrimitive()
>      * Primitive types}, {@linkplain #isHidden() hidden} classes, and arrays
>      * with hidden class as element types cannot be discovered by {@code forName}.

That reads fine with one minor tweak:

... and array classes whose element type is a hidden class or interface cannot be discovered by {@code forName}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1230341410

From liach at openjdk.org  Thu Jun 15 02:38:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 Jun 2023 02:38:08 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/03/java.base/java/lang/invoke/MethodType.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Update the note for getName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/6950d2ed..ff26c099

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=03-04

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Thu Jun 15 02:55:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 Jun 2023 02:55:09 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
Message-ID: <kY_a0EyZm7ntFX8Ui_n2BlP0xCUDfzuc8JslZcIVdc8=.16709083-9f3f-440d-8607-cb79301b93d0@github.com>

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the note for getName

If this version looks good, I will re-finalize the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1592262944

From aoqi at openjdk.org  Thu Jun 15 04:47:21 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Jun 2023 04:47:21 GMT
Subject: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913
Message-ID: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>

LoongArch64 Zero builds are broken after [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913):

jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
Error: jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64


Builds tested: LoongArch64 Zero, both release and fastdebug.

If this patch conflicts with #14471, I will rebase after #14471 is integrated.

-------------

Commit messages:
 - 8310105: LoongArch64 builds are broken after JDK-8304913

Changes: https://git.openjdk.org/jdk/pull/14482/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14482&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310105
  Stats: 13 lines in 3 files changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14482/head:pull/14482

PR: https://git.openjdk.org/jdk/pull/14482

From jwaters at openjdk.org  Thu Jun 15 06:04:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 15 Jun 2023 06:04:59 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <oXroh-ZQ9Vi9soyH4FRvoOrAvfLdFgW_OPu4TuRrdJM=.431e64a6-321e-49dc-9796-0ee38eedfcf2@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1592418574

From alanb at openjdk.org  Thu Jun 15 06:31:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 06:31:59 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <jetA7idd-bsxLPc2EoqKZrDsCMK5xqEkJdyTUI7di9w=.89907da9-0c04-453b-a9d4-7f609a196212@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 183:

> 181:             case "locale":
> 182:                 printLocale();
> 183:                 break;

printLocale might need the same treatment to avoid printing the list of all locales by default.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1230497367

From alanb at openjdk.org  Thu Jun 15 06:35:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 06:35:01 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <jetA7idd-bsxLPc2EoqKZrDsCMK5xqEkJdyTUI7di9w=.89907da9-0c04-453b-a9d4-7f609a196212@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
 <jetA7idd-bsxLPc2EoqKZrDsCMK5xqEkJdyTUI7di9w=.89907da9-0c04-453b-a9d4-7f609a196212@github.com>
Message-ID: <xNjtXaxdTgE_Sfb1bq_3mzqmgygsDu9saCAzWjklx5A=.fd891696-ea6c-4977-9a3a-d9308c87b8e7@github.com>

On Thu, 15 Jun 2023 06:29:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporate review comments from Roger and tweak some code
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 183:
> 
>> 181:             case "locale":
>> 182:                 printLocale();
>> 183:                 break;
> 
> printLocale might need the same treatment to avoid printing the list of all locales by default.

Have you tried putting the new code into say sun.launcher.SecuritySettings to avoid adding so much security conf code into LauncherHelper? Maybe eventually this will need to a more pluggable as -XshowSettings has grown a bit beyond what it was originally for.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1230499915

From alanb at openjdk.org  Thu Jun 15 07:16:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 07:16:59 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <MYT2jZZfh3gpAf3ovevvUHF4b1UhCnZfHdrJ7bmuBxk=.d0671acf-8f9d-4913-903a-8f5dde98a981@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>
 <MYT2jZZfh3gpAf3ovevvUHF4b1UhCnZfHdrJ7bmuBxk=.d0671acf-8f9d-4913-903a-8f5dde98a981@github.com>
Message-ID: <y4FlQ6RdSd_MkhySJ7vu_8ISbFgzHOXGrnfElMBqo0Q=.8b6911c7-eb9f-4192-bd7e-aa71392dd879@github.com>

On Mon, 5 Jun 2023 19:44:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think we need to delay this until [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in case we would like to revert [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).
> 
> Okay, I won't integrate this until we see what the issue is. That said, if the sub-mills support needs to be reverted then I think we should keep the interface as nanos on the boundary between the VM and the libraries. The reason is that it's mostly nanos at the Java level now, meaning 2 out of the 3 sleep methods support sub-mills, and the virtual thread sleep and the JFR event are in nanos too.

JDK-8309361 doesn't have a conclusion yet but doesn't look like it's a JDK implementation issue or heading toward removing the support for sub-mills precision.  So I think we should integrate this cleanup and get it out of the way. Even if there are changes then I think it's better for the precision at the interface to be nanos.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14303#issuecomment-1592491455

From alanb at openjdk.org  Thu Jun 15 07:30:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 07:30:59 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <TA_iNETiydKGo7yvOHparYFDWJo1KvnTduWmkcrUN_Q=.c6386241-379e-4a84-a3b1-b41c43ba1f54@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

The output from -XshowSettings vs. the large dump from -XshowSettings:security look good, I think the default vs. all split is quite good.  The format/style of the output is a bit different to the other sections in the -XshowSettings output. The other sections are more like name = value. What you have is okay, it just looks a bit different.  There are a few blank lines in the the "Security settings summary" output that you might want to cull. Also "Use -XshowSettings:security for verbose details" might be better as "... for security details". 

Also what would you think about the earlier suggesting to do the same for the locale output? The dump of all available locales seems excessive to print out by default.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1592507948

From shade at openjdk.org  Thu Jun 15 08:15:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Jun 2023 08:15:59 GMT
Subject: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913
In-Reply-To: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
References: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
Message-ID: <AoJwGmq_jXUjSzfxT_ESEq3jfmSwL1q8CeLsxVIH7Qg=.d2804cda-1b12-4240-8355-c8bd99cdd3a0@github.com>

On Thu, 15 Jun 2023 04:40:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch64 Zero builds are broken after [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913):
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Error: jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> 
> 
> Builds tested: LoongArch64 Zero, both release and fastdebug.
> 
> If this patch conflicts with #14471, I will rebase after #14471 is integrated.

Looks okay, thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14482#pullrequestreview-1480966009

From shade at openjdk.org  Thu Jun 15 08:30:02 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Jun 2023 08:30:02 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v5]
In-Reply-To: <73JNCEqvi2dImWjWk71KRB6gQr0vigHz4RebqahvSWo=.c8cb1742-9fa4-41c6-a63b-78ea3ee97682@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <73JNCEqvi2dImWjWk71KRB6gQr0vigHz4RebqahvSWo=.c8cb1742-9fa4-41c6-a63b-78ea3ee97682@github.com>
Message-ID: <zt644uAONugB_C6bcZGI3zb7_NC9-HbRnxgTNFtpIyU=.4bf0ab81-a206-4967-8bb1-9a1e9db511f8@github.com>

On Thu, 15 Jun 2023 00:16:15 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK8309688
>  - Removed volatile and comment about the benign race
>  - Switch to using volatile instead of AtomicReference
>  - Merge branch 'master' into JDK8309688
>  - 8309688: Data race on java.io.ClassCache.strongReferent

Right. I have suggestions about the comment.

src/java.base/share/classes/java/io/ClassCache.java line 93:

> 91:             // multiple threads calls get() with the same Class parameter.
> 92:             // Fixing this race could introduce noticeable performance penalty.
> 93:             // See the review thread for JDK-8309688 for details.

Feels like this comment belongs near `strongReferent` declaration. I suggest:


// This field is deliberately accessed without sychronization. ClassValue
// provides synchronization when CacheRef is published. However, when
// a thread reads this field, while another thread is clearing the field, it 
// would formally constitute a data race. But that data race is benign, and
// fixing it could introduce noticeable performance penalty, see JDK-8309688.
private T strongReferent;

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14386#pullrequestreview-1480988146
PR Review Comment: https://git.openjdk.org/jdk/pull/14386#discussion_r1230633686

From lbourges at openjdk.org  Thu Jun 15 09:21:13 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 15 Jun 2023 09:21:13 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>

> * 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 two additional commits since the last revision:

 - Merge branch 'dpqs23' of github.com:bourgesl/jdk-official into dpqs23
 - simplified test to enable radix sort (improved sorting on period and shuffle data) + updated version to 22

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/391bb3bd..f7f7e11a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=05-06

  Stats: 19 lines in 2 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From prappo at openjdk.org  Thu Jun 15 09:22:32 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 09:22:32 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v10]
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <RTK5UMJBqQsB7k4QpgCptUAEC16Mu_K4D-zPYyAghNI=.cf02b6f1-dc02-44fe-a880-a4b2635eff90@github.com>

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge branch 'master' into 8285368
 - Update @since tags
 - Add a test
 - fix failing SourceDocTreeScannerTest
 - Merge branch 'master' into 8285368
 - feedback: use JavadocTester.out
   
   Also, trivially fixes grammar (word order) in a comment.
 - feedback: remove unduly restrictive warning
 - suggestion: vocabulary
 - feedback: DocLint terminology
 - feedback: use utils directly
 - ... and 7 more: https://git.openjdk.org/jdk/compare/5a217d2b...5b6af244

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14357/files
  - new: https://git.openjdk.org/jdk/pull/14357/files/563a8761..5b6af244

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14357&range=08-09

  Stats: 8391 lines in 228 files changed: 1225 ins; 6803 del; 363 mod
  Patch: https://git.openjdk.org/jdk/pull/14357.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14357/head:pull/14357

PR: https://git.openjdk.org/jdk/pull/14357

From alanb at openjdk.org  Thu Jun 15 10:04:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 10:04:05 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
Message-ID: <NAiKaSRp9x6W1wdPLG5ylvB584Su1cCjEQp_zLeSU_s=.400931f3-6c80-4961-8f68-fde17e9dedf6@github.com>

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the note for getName

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1172:

> 1170:      * It is possible to encounter method types which cannot be
> 1171:      * constructed by this method, because their component types are
> 1172:      * not all reachable from a common class loader, or some component types

"reachable from a common class loader" pre-dates your change but I think it should say visible to the given class loader.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1233:

> 1231:      * (JVMS {@jvms 4.3.3}) and a suitable class loader argument. Two distinct
> 1232:      * classes which share a common name but have different class loaders will
> 1233:      * appear identical when viewed within descriptor strings.

"will appear identical when viewed within descriptor strings".  Would it be clearer to say that have equal descriptor strings?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1230764171
PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1230766963

From alanb at openjdk.org  Thu Jun 15 10:08:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 10:08:02 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
Message-ID: <IucIgyK8zrYS0xvV0n3TN9cUufdxEwz7vXvH3D9PyY0=.8d3054a8-6f49-4e37-87f2-0fe0ea2283f7@github.com>

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the note for getName

src/java.base/share/classes/java/lang/Class.java line 933:

> 931:      * classes whose element type is a hidden class or interface cannot be
> 932:      * discovered by {@code forName}.
> 933:      *

This is an API note in Class::getName. It seems excessive to be saying that primitive types, hidden classes, ... can't be discovered with Class.forName. It might be better to just drop the second half of this note.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1230770627

From alanb at openjdk.org  Thu Jun 15 10:30:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 10:30:34 GMT
Subject: RFR: 8309408: Thread.sleep cleanup [v2]
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <2AS77yfkB1xFobWQFaRarRplDgyT_VobybDkP3jdzxU=.031e3d04-df14-4c5f-8404-5a45b96d35f4@github.com>

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge
 - Merge
 - Add beforeSleep/afterSleep to list of expected methods
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14303/files
  - new: https://git.openjdk.org/jdk/pull/14303/files/ae6b531f..593f2a53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14303&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14303&range=00-01

  Stats: 55233 lines in 963 files changed: 39216 ins; 12904 del; 3113 mod
  Patch: https://git.openjdk.org/jdk/pull/14303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14303/head:pull/14303

PR: https://git.openjdk.org/jdk/pull/14303

From aph at openjdk.org  Thu Jun 15 11:11:18 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Jun 2023 11:11:18 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v7]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <-XdS4MaaaKJI3IZfO_2WeqCgKvm7KpRvVBFF3f-FSbI=.d0907827-d995-4357-88b9-c96450d05b4b@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Don't share ThreadLocalRandom instance, cleanup.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/cded1566..b2663471

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=05-06

  Stats: 18 lines in 1 file changed: 0 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From alanb at openjdk.org  Thu Jun 15 11:18:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 11:18:00 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v7]
In-Reply-To: <-XdS4MaaaKJI3IZfO_2WeqCgKvm7KpRvVBFF3f-FSbI=.d0907827-d995-4357-88b9-c96450d05b4b@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <-XdS4MaaaKJI3IZfO_2WeqCgKvm7KpRvVBFF3f-FSbI=.d0907827-d995-4357-88b9-c96450d05b4b@github.com>
Message-ID: <286JuXm0BTtoAwKGL87FCdwTrGTPBeivQxayAQviBCA=.ca7b3e52-5814-409f-9647-ed0154ae7275@github.com>

On Thu, 15 Jun 2023 11:11:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
>> 
>> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
>> 
>> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't share ThreadLocalRandom instance, cleanup.

I'd probably go further and drop the TLR parameter from the choose method too but what you have is fine, let's go with that.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14399#pullrequestreview-1481324158

From aph at openjdk.org  Thu Jun 15 11:45:04 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 15 Jun 2023 11:45:04 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v8]
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <TMS1EGwlpd8aSg7JNX7yT5QgR4UHxI1ZP57woPdb5MI=.339bb710-2e74-4a25-9966-fc0347e6c96c@github.com>

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Correct catch a top level.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14399/files
  - new: https://git.openjdk.org/jdk/pull/14399/files/b2663471..787398ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14399&range=06-07

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14399/head:pull/14399

PR: https://git.openjdk.org/jdk/pull/14399

From jvernee at openjdk.org  Thu Jun 15 11:52:11 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 15 Jun 2023 11:52:11 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v4]
In-Reply-To: <sUgum0-fxWEc-V2hxJIZrBhwtrLAvEJQSRXxOCSAOTc=.beb85d19-ea2f-42b4-a7c7-28f705b1ad8a@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
 <sUgum0-fxWEc-V2hxJIZrBhwtrLAvEJQSRXxOCSAOTc=.beb85d19-ea2f-42b4-a7c7-28f705b1ad8a@github.com>
Message-ID: <cuJMI-Qw2F9fzKg9H32W08Sj4BigXGymnQo5kKbTljE=.ff184ccb-74d7-45d5-a0d9-ce0f2a91b24a@github.com>

On Thu, 15 Jun 2023 00:22:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> only the first var handle in the dereference chain gets the proper alignment adaptation on the input segment

That would be easy enough to do, we just check for `derefAdapters.length == 0`. I'll add this too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14475#issuecomment-1592894033

From aoqi at openjdk.org  Thu Jun 15 12:36:58 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Jun 2023 12:36:58 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v2]
In-Reply-To: <z4M_Y9NZ4ab-9KKLv-K5I96MKiKiOmvcXu7KN2kxAg0=.e8c02b13-61b3-42c6-9352-72eb6c8ae6aa@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <103FVTgM5APhM8RQElJU7KmU3wyvAXrFFqOvBEmokMw=.f33e5aac-5b51-4494-ae10-fa1013836cf7@github.com>
 <z4M_Y9NZ4ab-9KKLv-K5I96MKiKiOmvcXu7KN2kxAg0=.e8c02b13-61b3-42c6-9352-72eb6c8ae6aa@github.com>
Message-ID: <UeuSXE-7lenc_SEo-nWAfCTLFVwJzeAnegPyGOUsXZE=.eb4fe37a-df34-4b2c-b6cf-694340a1575d@github.com>

On Wed, 14 Jun 2023 15:56:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine. We want/need the original reporter to confirm it works now?

Native build `linux-mips64el-zero-release` passed after the fix. I'm not the original reporter.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14471#issuecomment-1592961148

From aoqi at openjdk.org  Thu Jun 15 12:52:00 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Jun 2023 12:52:00 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v2]
In-Reply-To: <103FVTgM5APhM8RQElJU7KmU3wyvAXrFFqOvBEmokMw=.f33e5aac-5b51-4494-ae10-fa1013836cf7@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <103FVTgM5APhM8RQElJU7KmU3wyvAXrFFqOvBEmokMw=.f33e5aac-5b51-4494-ae10-fa1013836cf7@github.com>
Message-ID: <n-NZTEcLfNu1nO8DAiqpoOPL1K61A4N7EyOhY_3LPzA=.79604f38-309a-457b-928b-19ea0ecb15dd@github.com>

On Wed, 14 Jun 2023 15:50:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add mipsel and mips64el to the Architecture enum.
>> (Later to be backported to JDK 21)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add tests for MIPSEL and MIPS64EL

test/jdk/jdk/internal/util/ArchTest.java line 78:

> 76:             case "ppc64", "ppc64le" -> PPC64;
> 77:             case "mipsel" -> MIPSEL;
> 78:             case "mip64sel" -> MIPS64EL;

"mip64sel" -> "mips64el"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14471#discussion_r1230959560

From jvernee at openjdk.org  Thu Jun 15 13:08:45 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 15 Jun 2023 13:08:45 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v5]
In-Reply-To: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
Message-ID: <-gFnNTT5q3FaHqtkg93vwu6LB18CGus94MADsazF-1I=.138eaa16-568b-4bb7-86df-ccd616ec1122@github.com>

> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
> 
> Testing: `jdk_foreign` test suite

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  only check alignment of root for the first deref in a chain
  minor javadoc fix
  add test for misaligned deref

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14475/files
  - new: https://git.openjdk.org/jdk/pull/14475/files/99076262..b486d46e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14475&range=03-04

  Stats: 18 lines in 3 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14475/head:pull/14475

PR: https://git.openjdk.org/jdk/pull/14475

From jvernee at openjdk.org  Thu Jun 15 13:08:49 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 15 Jun 2023 13:08:49 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v4]
In-Reply-To: <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <fNxr-Z9KVRSwnBpvzAx8S0a6emHciwZabm5oB0ZpXHw=.65a55de7-ed3b-45a1-8073-e09a5855c791@github.com>
Message-ID: <e1N5EhZXterC4p6pWmvC8uHSu-mx2rPakKWQdsjeHE4=.89ec4cdd-1e7d-46e0-a0c1-71b1cd373564@github.com>

On Wed, 14 Jun 2023 23:38:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop alignment checks from accessed elements
>   Use expectThrows

I've gone ahead and implemented this. I also added a test to make sure that alignment checks still happen when using deref path elements.

I also fixed a minor javadoc issue, in the doc for varHandle. It said that we checked the alignment of the accessed address, but we check the alignment of the base address (a term which is defined earlier).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14475#issuecomment-1593004135

From mcimadamore at openjdk.org  Thu Jun 15 13:14:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 15 Jun 2023 13:14:01 GMT
Subject: RFR: 8310053: VarHandle and slice handle derived from layout are
 lacking alignment check [v5]
In-Reply-To: <-gFnNTT5q3FaHqtkg93vwu6LB18CGus94MADsazF-1I=.138eaa16-568b-4bb7-86df-ccd616ec1122@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
 <-gFnNTT5q3FaHqtkg93vwu6LB18CGus94MADsazF-1I=.138eaa16-568b-4bb7-86df-ccd616ec1122@github.com>
Message-ID: <XJtggXHchNwmPTGWWYgq9NemXFmQueMRapAh_rD_Wvs=.7e76fffd-5154-404c-a17f-8dc510153365@github.com>

On Thu, 15 Jun 2023 13:08:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
>> 
>> Testing: `jdk_foreign` test suite
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   only check alignment of root for the first deref in a chain
>   minor javadoc fix
>   add test for misaligned deref

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14475#pullrequestreview-1481537466

From duke at openjdk.org  Thu Jun 15 15:40:14 2023
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 15 Jun 2023 15:40:14 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v21]
In-Reply-To: <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>
Message-ID: <ek96itBRvM1yLJFzbFcye9CpKGvud6Qd84ci1i0mUWc=.1d4bb960-4674-4dfe-8653-666ef94a8190@github.com>

On Mon, 15 May 2023 15:51:02 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick 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 remote-tracking branch 'upstream/master' into patch-1
>  - Merge remote-tracking branch 'origin/patch-1' into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' into patch-1
>  - Update copyright date in RandomNext.java
>  - Update copyright date in RandomGeneratorNext.java
>  - Update copyright date in RandomGeneratorExponentialGaussian.java
>  - Update copyright date in RandomSupport.java
>  - Optimize: move some code out of the fast path
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/97b2ca3d...1b5656d7

@JimLaskey @jddarcy I believe this can now be merged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1593307471

From asotona at openjdk.org  Thu Jun 15 16:25:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Jun 2023 16:25:32 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v19]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <WRdo5OQBZKeH0YuiLoSzAtYG6YviBCkmDvxFvzQR_FM=.7f06a07f-a7c8-4644-874b-019dd20d00c7@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added new ClassfileBenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/df432763..a45246db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=17-18

  Stats: 106 lines in 1 file changed: 106 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Thu Jun 15 16:34:18 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Jun 2023 16:34:18 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v20]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <eL-zGzL8Bhq0U05IoY1xdwZ92ncPyL7U6Y-pOAB8eYQ=.12ce1fdf-9955-45f5-abfe-0c95761c3d64@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassfileBenchmark minor fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/a45246db..6e53057c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=18-19

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From mchung at openjdk.org  Thu Jun 15 16:35:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 15 Jun 2023 16:35:10 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <IucIgyK8zrYS0xvV0n3TN9cUufdxEwz7vXvH3D9PyY0=.8d3054a8-6f49-4e37-87f2-0fe0ea2283f7@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
 <IucIgyK8zrYS0xvV0n3TN9cUufdxEwz7vXvH3D9PyY0=.8d3054a8-6f49-4e37-87f2-0fe0ea2283f7@github.com>
Message-ID: <V2Xj9fsaeWwzEYH4VXQcQ8Xh8df5GuxPdC9dCU2p3KE=.62667bc9-fbdb-4343-bcfa-921158994005@github.com>

On Thu, 15 Jun 2023 10:04:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the note for getName
>
> src/java.base/share/classes/java/lang/Class.java line 933:
> 
>> 931:      * classes whose element type is a hidden class or interface cannot be
>> 932:      * discovered by {@code forName}.
>> 933:      *
> 
> This is an API note in Class::getName. It seems excessive to be saying that primitive types, hidden classes, ... can't be discovered with Class.forName. It might be better to just drop the second half of this note.

I think so too.  The spec describes the result of a hidden class is of the form: `{@code N + '/' + <suffix>}`.  If really needed, we can add in that bullet saying "The result is not a binary name."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1231278882

From asotona at openjdk.org  Thu Jun 15 17:22:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 15 Jun 2023 17:22:32 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/6e53057c..baa01584

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=19-20

  Stats: 17 lines in 1 file changed: 13 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From rriggs at openjdk.org  Thu Jun 15 17:44:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 15 Jun 2023 17:44:01 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]
In-Reply-To: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
Message-ID: <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>

> Add mipsel and mips64el to the Architecture enum.
> (Later to be backported to JDK 21)

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct mps64el test case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14471/files
  - new: https://git.openjdk.org/jdk/pull/14471/files/ce8d31fa..19541bfc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14471&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14471&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14471/head:pull/14471

PR: https://git.openjdk.org/jdk/pull/14471

From aoqi at openjdk.org  Thu Jun 15 17:47:26 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Jun 2023 17:47:26 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]
In-Reply-To: <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
Message-ID: <fXyooEg3pZPrJh_Ehf6SrLhJWlAS2LzwL9Bdv--3pTg=.00ddecf8-dd15-446b-9a59-983c0f129344@github.com>

On Thu, 15 Jun 2023 17:44:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add mipsel and mips64el to the Architecture enum.
>> (Later to be backported to JDK 21)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mps64el test case

Thanks, the test passed.

-------------

Marked as reviewed by aoqi (Author).

PR Review: https://git.openjdk.org/jdk/pull/14471#pullrequestreview-1482111164

From prappo at openjdk.org  Thu Jun 15 17:58:25 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 15 Jun 2023 17:58:25 GMT
Subject: Integrated: 8285368: Overhaul doc-comment inheritance
In-Reply-To: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
Message-ID: <kmzmr-8-gt-5ci-p2iA9RDGNokxRQBmVXqBIfjvc_4M=.45624b22-f898-4fc2-b244-a97279663743@github.com>

On Wed, 7 Jun 2023 14:19:16 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this long-awaited change to documentation inheritance.
> 
> This change improves "methods comment algorithm" and introduces directed documentation inheritance. While "methods comment algorithm" -- automatic search for inheritable documentation -- has been improved, it still cannot read an author's mind so as to always find the documentation they intended. From now on, an author can state their intention, by providing an FQN of the superclass or superinterface from which to inherit documentation:
> 
> ?{@inheritDoc S}
> 
> Which is exactly what I did to counterbalance some of the JDK API Documentation changes caused by the change to "methods comment algorithm".

This pull request has now been integrated.

Changeset: 3e0bbd29
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e0bbd290c534b0f9729c54cd45308d505907797
Stats:     1768 lines in 32 files changed: 1634 ins; 32 del; 102 mod

8285368: Overhaul doc-comment inheritance
6376959: Algorithm for Inheriting Method Comments seems to go not as documented
6934301: Support directed inheriting of class comments with @inheritDoc

Reviewed-by: jjg, rriggs, aivanov, smarks, martin

-------------

PR: https://git.openjdk.org/jdk/pull/14357

From rriggs at openjdk.org  Thu Jun 15 18:10:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 15 Jun 2023 18:10:44 GMT
Subject: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913
In-Reply-To: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
References: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
Message-ID: <Qu8-9hQJqUp-gs67h1bA4oPJEAGBUtVCQHOYnyLzv18=.00339d43-89bf-44b5-9cd2-6ea6dd4d07da@github.com>

On Thu, 15 Jun 2023 04:40:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch64 Zero builds are broken after [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913):
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Error: jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> 
> 
> Builds tested: LoongArch64 Zero, both release and fastdebug.
> 
> If this patch conflicts with #14471, I will rebase after #14471 is integrated.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14482#pullrequestreview-1482141501

From aoqi at openjdk.org  Thu Jun 15 18:17:50 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Jun 2023 18:17:50 GMT
Subject: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913
In-Reply-To: <AoJwGmq_jXUjSzfxT_ESEq3jfmSwL1q8CeLsxVIH7Qg=.d2804cda-1b12-4240-8355-c8bd99cdd3a0@github.com>
References: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
 <AoJwGmq_jXUjSzfxT_ESEq3jfmSwL1q8CeLsxVIH7Qg=.d2804cda-1b12-4240-8355-c8bd99cdd3a0@github.com>
Message-ID: <ImywRuCW-ykNYwGwbudiuiqTC1lWXtjXta9J0ZmfRNs=.b9d2dbd1-1df8-46e4-9f15-94618930343e@github.com>

On Thu, 15 Jun 2023 08:12:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> LoongArch64 Zero builds are broken after [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913):
>> 
>> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
>> at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
>> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
>> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
>> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>> at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
>> Error: jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
>> 
>> 
>> Builds tested: LoongArch64 Zero, both release and fastdebug.
>> 
>> If this patch conflicts with #14471, I will rebase after #14471 is integrated.
>
> Looks okay, thanks!

Thanks, @shipilev and @RogerRiggs! I plan to wait for #14471 to be integrated before applying for integration of this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14482#issuecomment-1593524743

From roger.riggs at oracle.com  Thu Jun 15 18:19:02 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 15 Jun 2023 14:19:02 -0400
Subject: OpenJDK fails to build on mips and mips64el after JDK-8304913
In-Reply-To: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
References: <CALFf3kebLJ8unBaz_=e69y1v84YYgSrye9wOs6dmrpqoaF=GZw@mail.gmail.com>
Message-ID: <4d8d3951-7a4a-a93d-11ce-472b5ce80920@oracle.com>

Hi Vladimir,

Can you confirm that the requested changes in PR 14471 
<https://github.com/openjdk/jdk/pull/14471> address the issue with mips 
and mips64el.

Thanks, Roger

On 6/14/23 5:36 AM, Vladimir Petko wrote:
> Dear Maintainers,
>
> After JDK-8304913, OpenJDK fails to build on mips[1] and mips64el[2].
> Would it be possible to consider adding those architectures to the
> Architecture enumeration (see attached patch)/
>
> Best Regards,
>   Vladimir.
>
> [1]https://buildd.debian.org/status/fetch.php?pkg=openjdk-21&arch=mips64el&ver=21%7E26ea-2&stamp=1686605119&raw=0
> [2]https://buildd.debian.org/status/fetch.php?pkg=openjdk-21&arch=mipsel&ver=21%7E26ea-2&stamp=1686722920&raw=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230615/690ddf65/attachment-0001.htm>

From manc at openjdk.org  Thu Jun 15 18:22:46 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 18:22:46 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v6]
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14386/files
  - new: https://git.openjdk.org/jdk/pull/14386/files/6da51c22..83facfa5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14386&range=04-05

  Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14386.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14386/head:pull/14386

PR: https://git.openjdk.org/jdk/pull/14386

From shade at openjdk.org  Thu Jun 15 18:22:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Jun 2023 18:22:47 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v6]
In-Reply-To: <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>
Message-ID: <KlGFBAO-3TQ4d5S8-yzL9XmDiArCwBBfqQlaPqvaaZI=.3bc5896f-d8df-41b2-8fe7-b5cf9bd8df59@github.com>

On Thu, 15 Jun 2023 18:17:17 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

I am okay with it. Since this is my comment, I'd like someone else to re-review :)

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14386#pullrequestreview-1482155576

From manc at openjdk.org  Thu Jun 15 18:22:52 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 18:22:52 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v5]
In-Reply-To: <zt644uAONugB_C6bcZGI3zb7_NC9-HbRnxgTNFtpIyU=.4bf0ab81-a206-4967-8bb1-9a1e9db511f8@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <73JNCEqvi2dImWjWk71KRB6gQr0vigHz4RebqahvSWo=.c8cb1742-9fa4-41c6-a63b-78ea3ee97682@github.com>
 <zt644uAONugB_C6bcZGI3zb7_NC9-HbRnxgTNFtpIyU=.4bf0ab81-a206-4967-8bb1-9a1e9db511f8@github.com>
Message-ID: <Ir3IykgQmtd5U6pNNLaoy3gs72hPW0jvZOKuw7i8bms=.84f2af16-488b-4d84-a56d-f5b597cc44d8@github.com>

On Thu, 15 Jun 2023 08:23:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Man Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK8309688
>>  - Removed volatile and comment about the benign race
>>  - Switch to using volatile instead of AtomicReference
>>  - Merge branch 'master' into JDK8309688
>>  - 8309688: Data race on java.io.ClassCache.strongReferent
>
> src/java.base/share/classes/java/io/ClassCache.java line 93:
> 
>> 91:             // multiple threads calls get() with the same Class parameter.
>> 92:             // Fixing this race could introduce noticeable performance penalty.
>> 93:             // See the review thread for JDK-8309688 for details.
> 
> Feels like this comment belongs near `strongReferent` declaration. I suggest:
> 
> 
> // This field is deliberately accessed without sychronization. ClassValue
> // provides synchronization when CacheRef is published. However, when
> // a thread reads this field, while another thread is clearing the field, it 
> // would formally constitute a data race. But that data race is benign, and
> // fixing it could introduce noticeable performance penalty, see JDK-8309688.
> private T strongReferent;

Thank you. Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14386#discussion_r1231381928

From rriggs at openjdk.org  Thu Jun 15 18:24:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 15 Jun 2023 18:24:59 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v6]
In-Reply-To: <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>
Message-ID: <0KlFqeD5Jsxb_cGQS453cekthgAp-7xLI8FXOecxQjs=.08757098-e6a4-4864-9c87-b4c35ed75a87@github.com>

On Thu, 15 Jun 2023 18:22:46 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Looks fine

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14386#pullrequestreview-1482163849

From jlu at openjdk.org  Thu Jun 15 19:45:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 19:45:52 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <wHemDob1LcBUGrp94CGVymYmeivv2G9ccgjfngb7m84=.a4d37dbb-54fd-4920-8734-dd2080aeaf32@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: 81bfd789
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14430

From kcr at openjdk.org  Thu Jun 15 20:05:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 20:05:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <lk-HQVh3RGdNHbBiHftYiYZQzEq5Hp6CCtCXPjSbAPs=.ae8c0707-7daf-4142-8147-1ea24323364a@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

I was 

> @kevinrushforth Thanks for the reminder, will make the change in ML first.

Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNNNNNNNNNN`, where `NNNNNNNNNNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435

From duke at openjdk.org  Thu Jun 15 20:05:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 15 Jun 2023 20:05:31 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <j-x2Vg89HAUcCaDz51mqofqhoX932hkfEGlaF-FvKIo=.8473b365-250a-47c3-b052-9d78947374de@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

(Review comment moved to mainline PR)

-------------

PR Review Comment: https://git.openjdk.org/jdk21/pull/11#discussion_r1227287139

From manc at openjdk.org  Thu Jun 15 20:16:14 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 20:16:14 GMT
Subject: RFR: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent [v6]
In-Reply-To: <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
 <CNNf6VI-OGtu_E7XBDPJ2lh35y3OpYYVx46_y_JzFMU=.5da3fe4c-2558-48d4-9893-ef61c5e658dd@github.com>
Message-ID: <Oi8gZIzl7oA75trQmYSFOd9N0TTD66VCvbziAQNoXlU=.4025e941-31b0-4f9a-837b-4c2f47e3548d@github.com>

On Thu, 15 Jun 2023 18:22:46 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Thank you for the reviews and suggestions!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14386#issuecomment-1593667726

From manc at openjdk.org  Thu Jun 15 20:16:16 2023
From: manc at openjdk.org (Man Cao)
Date: Thu, 15 Jun 2023 20:16:16 GMT
Subject: Integrated: 8309688: Data race on
 java.io.ClassCache$CacheRef.strongReferent
In-Reply-To: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
References: <mzMuOgd_7qFdwK_so6RsWO9k5leRO8ouXJ8tuhi7vw4=.bf8c3dd0-0bc2-49a5-a8ad-28e1ec000a0c@github.com>
Message-ID: <Y4MeBYQQlUcKmQY0XSNd0KpLvvsvi2wSTC9U1tADAbI=.03999607-697c-41fe-8e58-294866c167ce@github.com>

On Thu, 8 Jun 2023 22:06:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this small fix for a data race in java.io.ClassCache$CacheRef? This fix makes the code safer by making the code data-race-free.

This pull request has now been integrated.

Changeset: 5c705166
Author:    Man Cao <manc at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c705166da112395dcff70685a4d19ea6e9f426b
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8309688: Data race on java.io.ClassCache$CacheRef.strongReferent

Reviewed-by: rriggs, shade

-------------

PR: https://git.openjdk.org/jdk/pull/14386

From kcr at openjdk.org  Thu Jun 15 21:09:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 21:09:09 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465

From jlu at openjdk.org  Thu Jun 15 21:13:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 21:13:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
Message-ID: <8055MPxK8nGDItLuewscD0HhRwu4yJHWRoWg1H_SEu4=.7a2b5b3b-422c-4d32-8b68-d856a6ac8c05@github.com>

On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784

From smarks at openjdk.org  Thu Jun 15 22:45:14 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 15 Jun 2023 22:45:14 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements
Message-ID: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>

Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.

-------------

Commit messages:
 - 8308694: Clarify reversed() default methods' implementation requirements

Changes: https://git.openjdk.org/jdk/pull/14504/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308694
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14504/head:pull/14504

PR: https://git.openjdk.org/jdk/pull/14504

From bpb at openjdk.org  Thu Jun 15 22:57:00 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 15 Jun 2023 22:57:00 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements
In-Reply-To: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
Message-ID: <hANicaI9oEosIZBw0SLsoq4Avbd5d-98Gi8wO7jt4wI=.049635fe-a7c9-415b-9188-7d33010d69d1@github.com>

On Thu, 15 Jun 2023 22:38:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.

Reads well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14504#pullrequestreview-1482492286

From prr at openjdk.org  Thu Jun 15 23:26:01 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 15 Jun 2023 23:26:01 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <BAJEK7hLwwrd-mpn-CIj8IwiNuW2S5JJuf_v6NG_u50=.04f8d02f-977d-4366-92d7-3d3c2e85f973@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:

> 1087:                 entry_point();
> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, colorBits, &bmi, DIB_RGB_COLORS);

I just can't tell if the updates you are making as a result of the jni_md.h change are really the right ones and some of them don't look that way

You wrote
"As listed above, the native Windows API routines that the java.desktop code calls are actually expecting ints,"

Per the windows docs for GetDIBits()  it takes an LPVOID for the parameter these are used for.
For the cases above if takes an LPVOID which is really just a void*, and using jint in the malloc is just weird since jint doesn't mean anything to GDI

And  clearly this change requires running a whole load of client tests on windows [*]
but I have no idea what your reply to my question about that means. What is "-permissive" ?

[*] and I have no idea what VM etc tests need to be run just for the JNI change

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1231621441

From liach at openjdk.org  Thu Jun 15 23:36:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 15 Jun 2023 23:36:05 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <V2Xj9fsaeWwzEYH4VXQcQ8Xh8df5GuxPdC9dCU2p3KE=.62667bc9-fbdb-4343-bcfa-921158994005@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
 <IucIgyK8zrYS0xvV0n3TN9cUufdxEwz7vXvH3D9PyY0=.8d3054a8-6f49-4e37-87f2-0fe0ea2283f7@github.com>
 <V2Xj9fsaeWwzEYH4VXQcQ8Xh8df5GuxPdC9dCU2p3KE=.62667bc9-fbdb-4343-bcfa-921158994005@github.com>
Message-ID: <DGOHFDic98OgvOcHxdMeJnm0VwfSUPdEYw4SKxHGZ2o=.1599859b-59d1-48cd-8c10-6257ab87de25@github.com>

On Thu, 15 Jun 2023 16:32:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 933:
>> 
>>> 931:      * classes whose element type is a hidden class or interface cannot be
>>> 932:      * discovered by {@code forName}.
>>> 933:      *
>> 
>> This is an API note in Class::getName. It seems excessive to be saying that primitive types, hidden classes, ... can't be discovered with Class.forName. It might be better to just drop the second half of this note.
>
> I think so too.  The spec describes the result of a hidden class is of the form: `{@code N + '/' + <suffix>}`.  If really needed, we can add in that bullet saying "The result is not a binary name."

The 3-arg forName specifies it uses the 'getName' format. It's good to update that to refer to binary names, but that API can find array classes, and array classes aren't quite binary names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1231625796

From smarks at openjdk.org  Thu Jun 15 23:50:05 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 15 Jun 2023 23:50:05 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements
In-Reply-To: <hANicaI9oEosIZBw0SLsoq4Avbd5d-98Gi8wO7jt4wI=.049635fe-a7c9-415b-9188-7d33010d69d1@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
 <hANicaI9oEosIZBw0SLsoq4Avbd5d-98Gi8wO7jt4wI=.049635fe-a7c9-415b-9188-7d33010d69d1@github.com>
Message-ID: <dQyUPcf0gUTptb70-ySUOA2PxK6989qDIc_b4WMQMOI=.3f5e0fb3-3378-4a6a-b3d4-ba40e06d3c6d@github.com>

On Thu, 15 Jun 2023 22:54:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.
>
> Reads well.

@bplb OK thanks. But now that I've posted this, I'm having second thoughts. :-)

The problem is that this spec is trying to be more specific...and the more specific something is, the greater the possibility is of inaccuracy. What I had written is _mostly_ true, but it isn't true for _all_ operations. Some operations in particular such as `addAll` actually have to do rather more complex things than delegating operations to the backing Deque. See the implementation for other examples:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ReverseOrderDequeView.java

I don't want to specify the exact behavior of every method. Issues of a similar magnitude occur with the other reversed views. For example, getting the iterator of a reversed SortedSet involves some heavy lifting:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/ReverseOrderSortedSetView.java#L206

and I certainly don't want to specify all of that.

So, while in fact the general sense is true that the operations of the reversed view are all implemented via calls to the backing collection, I need to be deliberately vague in certain respects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14504#issuecomment-1593852758

From jvernee at openjdk.org  Fri Jun 16 00:12:02 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 16 Jun 2023 00:12:02 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates
Message-ID: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>

This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.

Testing: jdk-tier1,2,3

-------------

Commit messages:
 - allow void-returning filters for collectCoordinates

Changes: https://git.openjdk.org/jdk/pull/14496/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14496&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310157
  Stats: 23 lines in 3 files changed: 9 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14496/head:pull/14496

PR: https://git.openjdk.org/jdk/pull/14496

From mcimadamore at openjdk.org  Fri Jun 16 00:35:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 16 Jun 2023 00:35:00 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates
In-Reply-To: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
References: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
Message-ID: <M85Xk_cHLgePcFLtKdy7fj3JNIKQi4VlTsWVAHP7x0Q=.f331a69e-3973-445f-ab85-1d48ed2a7403@github.com>

On Thu, 15 Jun 2023 15:44:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.
> 
> Testing: jdk-tier1,2,3

Looks good (thanks for taking care of this). The javadoc can probably be consolidated a bit further.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8191:

> 8189:      * coordinate list.
> 8190:      * <p>
> 8191:      * If {@code R} is the return type of the filter, then, unless {@code R} is void, the target var handle must accept

Not introduced by you - but this para seems to be repeated twice-ish. I think we should try to consolidate the two, if we can.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8203:

> 8201:      * If the return type of the filter is <em>not</em> void, it must be identical to the
> 8202:      * coordinate type of the target var handle at position {@code pos}, and that target var handle
> 8203:      * coordinate is supplied by the return value of the filter. If the return type of the filter <em>is</em> void,

This is the other para I was talking about in the other comment.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14496#pullrequestreview-1482554155
PR Review Comment: https://git.openjdk.org/jdk/pull/14496#discussion_r1231654844
PR Review Comment: https://git.openjdk.org/jdk/pull/14496#discussion_r1231654864

From jwaters at openjdk.org  Fri Jun 16 00:43:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 16 Jun 2023 00:43:19 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <BAJEK7hLwwrd-mpn-CIj8IwiNuW2S5JJuf_v6NG_u50=.04f8d02f-977d-4366-92d7-3d3c2e85f973@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <BAJEK7hLwwrd-mpn-CIj8IwiNuW2S5JJuf_v6NG_u50=.04f8d02f-977d-4366-92d7-3d3c2e85f973@github.com>
Message-ID: <Y9FMGwzJBhQth0ZkNl0Vi-OsK_TXSZLFNxfq55d69wc=.5e1fe26b-f9c5-40d5-9519-68696df130db@github.com>

On Thu, 15 Jun 2023 23:22:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:
> 
>> 1087:                 entry_point();
>> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
>> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, colorBits, &bmi, DIB_RGB_COLORS);
> 
> I just can't tell if the updates you are making as a result of the jni_md.h change are really the right ones and some of them don't look that way
> 
> You wrote
> "As listed above, the native Windows API routines that the java.desktop code calls are actually expecting ints,"
> 
> Per the windows docs for GetDIBits()  it takes an LPVOID for the parameter these are used for.
> For the cases above if takes an LPVOID which is really just a void*, and using jint in the malloc is just weird since jint doesn't mean anything to GDI
> 
> And  clearly this change requires running a whole load of client tests on windows [*]
> but I have no idea what your reply to my question about that means. What is "-permissive" ?
> 
> [*] and I have no idea what VM etc tests need to be run just for the JNI change

-permissive- is a compiler switch that forces the Microsoft Visual C compiler to be stricter in compiling C and C++ and makes it enforce the standard much more aggressively. It's becoming less permissive with every iteration of the Microsoft compiler and is stated to become enabled by default eventually by Microsoft. One of the consequences of this is that in the future our code cannot so loosely treat int and long as the same type on Windows (even though they are ultimately the same size in compiled code), as far as the compiler is concerned, they are semantically 2 entirely different types. That's the complication this Pull Request is trying to preempt by changing the jni.h typedef for Windows

I missed the LPVOID change in GetDIBits, but for the other changes I really only followed the existing declarations, the jint for colorBits is because the call to SetIntArrayRegion takes a jint as a parameter. Let me know if I should change the declaration regardless, though

Also, we have David for the VM reviews ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1231658403

From jvernee at openjdk.org  Fri Jun 16 01:53:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 16 Jun 2023 01:53:29 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates [v2]
In-Reply-To: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
References: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
Message-ID: <FzXWUHG3CaS9LKGJY7tR6_OCCXozL389gyN49k_2_74=.e5241237-0707-4c98-a167-976a9a7bd2ca@github.com>

> This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.
> 
> Testing: jdk-tier1,2,3

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - typo
 - polish javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14496/files
  - new: https://git.openjdk.org/jdk/pull/14496/files/942a7243..1a10d48a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14496&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14496&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14496/head:pull/14496

PR: https://git.openjdk.org/jdk/pull/14496

From jvernee at openjdk.org  Fri Jun 16 01:53:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 16 Jun 2023 01:53:29 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates
In-Reply-To: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
References: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
Message-ID: <qx0eKm3rfiwwfVqJT0h7yhPoT8ztW7vJjjTMHAJzmJQ=.d4a1866c-f73b-44d7-9ffc-24d41f5350c9@github.com>

On Thu, 15 Jun 2023 15:44:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.
> 
> Testing: jdk-tier1,2,3

Thanks for the suggestion. I've rewritten these two paragraphs. I now list the behavior of two cases non-void/void separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14496#issuecomment-1593966952

From martin at openjdk.org  Fri Jun 16 04:39:17 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Fri, 16 Jun 2023 04:39:17 GMT
Subject: RFR: 8285368: Overhaul doc-comment inheritance [v9]
In-Reply-To: <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>
References: <ylzhSElbSF854YEe6vYOZSL4YrwO5Mpm12GEkR777rs=.9d949db8-bceb-4d23-afcc-a7fb200b31cb@github.com>
 <eriZBVCbw1E-GCGa36OZpdHELo6aghNNYX3QRD5-1ts=.1da6022e-7e83-43e0-8172-00274d09e1c4@github.com>
 <0VhwFAbMOxparpCwhGbTnNDCthMTrqwzzMe-8XY7oLE=.e17f071f-2ae2-4d54-aeb8-0db60e34a310@github.com>
 <wvgrrZUkfRMQ3rNy7Uphe5-57WTk0A10EdPKbeGWOko=.f35bd62f-c094-4ec5-91f8-ae1ecff726ca@github.com>
Message-ID: <sxYo3C8Lkg2RLbg-NyOwCGOfqtA4Mud4i4ImQ8GNf1I=.a22a4573-4e06-4472-8e5b-3161bcb49d32@github.com>

On Wed, 14 Jun 2023 10:07:05 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line 1534:
>> 
>>> 1532: 
>>> 1533:     /**
>>> 1534:      * {@inheritDoc ConcurrentMap}
>> 
>> This clarifies the authors' intent, so is clear progress. 
>> 
>> Semantic difficulties remain:
>> - it would be nice to somehow declare that we never ever want to inherit doc from AbstractMap (or even at the module level, declare that AbstractFoo classes are specified only for subclass writers, not users).  Private inheritance?
>> - we never want to inherit AbstractFoo @implNotes
>> - ConcurrentMap does *not* have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should *not* be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.
>
>> * we never want to inherit AbstractFoo @implNotes
> 
> `@implNote`, `@apiNote` and `@implSpec` can only be inherited via explicit `{@inheritDoc}`:
> 
>     @implSpec {@inheritDoc}
> 
>> * ConcurrentMap does _not_ have the same spec as ConcurrentHashMap, e.g. the latter does not permit null values.  Therefore one can argue that javadoc should _not_ be inherited here.  Right now the main method spec from ConcurrentMap is perfectly suitable for ConcurrentHashMap, but one can imagine a future change to ConcurrentMap::putIfAbsent's spec that changes that, perhaps due to the null value handling difference.  We have a distasteful choice - brittle inheritance or copy-pasta.  In practice not so bad here, since these classes are maintained together.
> 
> That state of affairs predates this PR and is merely highlighted by it. Sadly, I'm not sure how JavaDoc can help here. Annotations, contracts, inspections, and doc tests come to mind; but none of these are supported by JavaDoc at the moment.

(There's nothing wrong with this PR)

Back in the 1980s there was a lot of optimism that OOP would be a big leap forward in software engineering.
But especially the "inheritance" part of OOP has been disappointing - unexpectedly brittle!
javadoc inheritance in collection classes was particularly interesting to me from this perspective.
Especially with the multiple inheritance that java was mostly reluctant to adopt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14357#discussion_r1231765877

From jlu at openjdk.org  Fri Jun 16 04:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 04:39:42 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value
 - Review: use Naoto's recommended ja values
 - Revert 'main.help.opt.any.file' value for _de

-------------

Changes:
  - all: https://git.openjdk.org/jdk21/pull/11/files
  - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00-01

  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11

From alanb at openjdk.org  Fri Jun 16 07:29:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 07:29:27 GMT
Subject: Integrated: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <qrmFnrqf_ZxNB1Qaq06FWZBdlSCIlMBWJCqTaEm7Gjs=.b955e644-4b95-4b94-85a3-92194d1d23eb@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

This pull request has now been integrated.

Changeset: 227656f3
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/227656f3a9b61ebcadab6b90ce4d53f4e351f650
Stats:     77 lines in 10 files changed: 29 ins; 32 del; 16 mod

8309408: Thread.sleep cleanup

Reviewed-by: dholmes, stefank

-------------

PR: https://git.openjdk.org/jdk/pull/14303

From aboldtch at openjdk.org  Fri Jun 16 09:22:33 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 09:22:33 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing
Message-ID: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>

The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.

The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.

If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.

If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.

If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.

And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.

This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.

This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 

The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`

To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.

`vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
- `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
- `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  

`test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change is isolated in 5c0c0bdab9012a5f35dd4ab3a2847374578c8b9f . It seems more appropriate to actually test the MXBeans by default with no explicit gc, but I am open reverting this part.

The plan is to also backport this to 21 to improve the testing until release. The changes here should fall under `P1?P5 doc/test changes`

Running tests in Oracle CI. (tier1-tier5)
Verified that both `ZGenerational` and `ZSinglegen` tests get run in GHA.
Running tests in builds with `--disable-jvm-feature-zgc` to verify no regression.

-------------

Commit messages:
 - MemoryTest.java run when not explicit
 - Add vm.gc.{ZGenerational,ZSinglegen} to jtreg

Changes: https://git.openjdk.org/jdk/pull/14509/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310187
  Stats: 618 lines in 70 files changed: 447 ins; 5 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

PR: https://git.openjdk.org/jdk/pull/14509

From kevinw at openjdk.org  Fri Jun 16 09:23:38 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 16 Jun 2023 09:23:38 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
Message-ID: <EM-gSGWADuTyVdSaS_8MNv8pMUUGz6JRFidTnHww304=.8747b919-93e6-46ef-aac9-0da01c80033b@github.com>

Clean backport from latest jdk repo to jdk21 for the test change:
8303916: ThreadLists.java inconsistent results

-------------

Commit messages:
 - Backport 8c9b85a990d955487f9141207cc83d0051defc57

Changes: https://git.openjdk.org/jdk21/pull/24/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=24&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303916
  Stats: 77 lines in 1 file changed: 54 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk21/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/24/head:pull/24

PR: https://git.openjdk.org/jdk21/pull/24

From duke at openjdk.org  Fri Jun 16 10:28:56 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 16 Jun 2023 10:28:56 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <7OYMG1cKrZVU01vAqAwBj2PoRtAe8NZ7FN6FU1vk3tk=.fe2ef38e-c45b-474a-8a8b-c757a4691a3d@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

Oliver Kopp has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into fix-8240567
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Remove "final" at "enabled" - not part of the point of this PR
 - Remove comments
 - 8240567: MethodTooLargeException thrown while creating a jlink image
   
   Co-authored-by: Christoph Schwentker <siedlerkiller at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/e158a2c3..e9732951

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=02-03

  Stats: 4618 lines in 173 files changed: 2987 ins; 1053 del; 578 mod
  Patch: https://git.openjdk.org/jdk/pull/14408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14408/head:pull/14408

PR: https://git.openjdk.org/jdk/pull/14408

From duke at openjdk.org  Fri Jun 16 10:36:02 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 16 Jun 2023 10:36:02 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
Message-ID: <Ln9LrCDxKSOoh44Og4b900mB_wjPSmUkdSqWEI3WW-0=.004d330c-d3de-4fe8-84e6-7d9dc4fa0fbf@github.com>

On Mon, 12 Jun 2023 05:03:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into fix-8240567
>>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>>  - Remove "final" at "enabled" - not part of the point of this PR
>>  - Remove comments
>>  - 8240567: MethodTooLargeException thrown while creating a jlink image
>>    
>>    Co-authored-by: Christoph Schwentker <siedlerkiller at gmail.com>
>
> @koppor Is this ready for review? The other PR went through a dozens or so iterations before it was returned to draft. It seems like you were still battling with verifier errors. The comment on this PR says you it was created because a force-push so I can't tell if you the changes are ready or not.

@AlanBateman The diff to the "old" PR https://github.com/openjdk/jdk/pull/10704 is as follows. Maybe this helps at reviewing? IMHO this diff shows very good the new passing of the locals required by the deduplication functionality.


diff --git a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
old mode 100755
new mode 100644
index 8e98a5b94e2..a87fa84ebe2
--- a/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
+++ b/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
@@ -118,7 +118,7 @@ public final class SystemModulesPlugin extends AbstractPlugin {
             ClassDesc.ofInternalName("jdk/internal/module/SystemModules");
     private static final ClassDesc CD_SYSTEM_MODULES_MAP =
             ClassDesc.ofInternalName(SYSTEM_MODULES_MAP_CLASSNAME);
-    private final boolean enabled;
+    private boolean enabled;
 
     public SystemModulesPlugin() {
         super("system-modules");
@@ -519,7 +519,7 @@ public final class SystemModulesPlugin extends AbstractPlugin {
 
         private static final int MAX_LOCAL_VARS = 256;
 
-        private final int BUILDER_VAR    = 0;
+        private final int BUILDER_VAR    = MAX_LOCAL_VARS + 1;
         private final int MD_VAR         = 1;  // variable for ModuleDescriptor
         private final int MT_VAR         = 1;  // variable for ModuleTarget
         private final int MH_VAR         = 1;  // variable for ModuleHashes
@@ -666,7 +666,7 @@ public final class SystemModulesPlugin extends AbstractPlugin {
          * Generate bytecode for moduleDescriptors method
          */
         private void genModuleDescriptorsMethod(ClassBuilder clb) {
-            if (moduleInfos.size() <= 71) {
+            if (moduleInfos.size() <= 75) {
                 clb.withMethodBody(
                         "moduleDescriptors",
                         MethodTypeDesc.of(CD_MODULE_DESCRIPTOR.arrayType()),
@@ -688,71 +688,98 @@ public final class SystemModulesPlugin extends AbstractPlugin {
                 return;
             }
 
-            // split up module infos in "consumable" packages
             List<List<ModuleInfo>> splitModuleInfos = new ArrayList<>();
             List<ModuleInfo> currentModuleInfos = null;
             for (int index = 0; index < moduleInfos.size(); index++) {
-                // The method is "manually split" based on the heuristics that 90 ModuleDescriptors are smaller than 64kb
-                // The number 10 is chosen "randomly" to be below the 64kb limit of a method
-                if (index % 10 == 0) {
-                    // Prepare new list
+                if (index % 50 == 0) {
                     currentModuleInfos = new ArrayList<>();
                     splitModuleInfos.add(currentModuleInfos);
                 }
                 currentModuleInfos.add(moduleInfos.get(index));
             }
-            // generate all helper methods
+
             final String helperMethodNamePrefix = "moduleDescriptorsSub";
+            final ClassDesc arrayListClassDesc = ClassDesc.ofInternalName("java/util/ArrayList");
+
+            final int firstVariableForDedup = nextLocalVar;
+
+            clb.withMethodBody(
+                    "moduleDescriptors",
+                    MethodTypeDesc.of(CD_MODULE_DESCRIPTOR.arrayType()),
+                    ACC_PUBLIC,
+                    cob -> {
+                        cob.constantInstruction(moduleInfos.size())
+                                .anewarray(CD_MODULE_DESCRIPTOR)
+                                .dup()
+                                .astore(MD_VAR);
+                        cob.new_(arrayListClassDesc)
+                           .dup()
+                           .invokespecial(arrayListClassDesc, "<init>", MethodTypeDesc.of(CD_void))
+                           .astore(nextLocalVar);
+                        cob.aload(0)
+                           .aload(MD_VAR)
+                           .aload(nextLocalVar)
+                           .invokevirtual(
+                                   this.classDesc,
+                                   helperMethodNamePrefix + "0",
+                                   MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType(), arrayListClassDesc)
+                           )
+                           .areturn();
+                    });
+
             final int[] globalCount = {0};
             for (final int[] index = {0}; index[0] < splitModuleInfos.size(); index[0]++) {
                 clb.withMethodBody(
                         helperMethodNamePrefix + index[0],
-                        MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType()),
+                        MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType(), arrayListClassDesc),
                         ACC_PUBLIC,
                         cob -> {
                             List<ModuleInfo> moduleInfosPackage = splitModuleInfos.get(index[0]);
-                            if (index[0] > 0) {
-                                // call last helper method
-                                cob.aload(0)
-                                   .aload(MD_VAR) // load first parameter, which is MD_VAR
-                                   .invokevirtual(
-                                           this.classDesc,
-                                           helperMethodNamePrefix + (index[0] - 1),
-                                           MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType())
-                                   );
+
+                            if (nextLocalVar > firstVariableForDedup) {
+                                for (int i = nextLocalVar-1; i >= firstVariableForDedup; i--) {
+                                    cob.aload(2)
+                                       .constantInstruction(i-firstVariableForDedup)
+                                       .invokevirtual(arrayListClassDesc, "get", MethodTypeDesc.of(CD_Object, CD_int))
+                                       .astore(i);
+                                }
                             }
+
                             for (int j = 0; j < moduleInfosPackage.size(); j++) {
                                 ModuleInfo minfo = moduleInfosPackage.get(j);
-                                // executed after the call, thus it is OK to overwrite index 0 (BUILDER_VAR)
                                 new ModuleDescriptorBuilder(cob,
                                         minfo.descriptor(),
                                         minfo.packages(),
                                         globalCount[0]).build();
                                 globalCount[0]++;
                             }
+
+                            if (index[0] + 1 < (splitModuleInfos.size())) {
+                                if (nextLocalVar > firstVariableForDedup) {
+                                    cob.new_(arrayListClassDesc)
+                                       .dup()
+                                       .invokespecial(arrayListClassDesc, "<init>", MethodTypeDesc.of(CD_void))
+                                       .astore(nextLocalVar);
+                                    for (int i = firstVariableForDedup; i < nextLocalVar; i++) {
+                                        cob.aload(nextLocalVar)
+                                           .aload(i)
+                                           .invokevirtual(arrayListClassDesc, "add", MethodTypeDesc.of(CD_boolean, CD_Object))
+                                           .pop();
+                                    }
+                                }
+                                cob.aload(0)
+                                   .aload(MD_VAR)
+                                   .aload(nextLocalVar)
+                                   .invokevirtual(
+                                           this.classDesc,
+                                           helperMethodNamePrefix + (index[0] + 1),
+                                           MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType(), arrayListClassDesc)
+                                   );
+                            }
+
                             cob.return_();
                         });
             }
-
-            // generate call to last helper method
-            clb.withMethodBody(
-                    "moduleDescriptors",
-                    MethodTypeDesc.of(CD_MODULE_DESCRIPTOR.arrayType()),
-                    ACC_PUBLIC,
-                    cob -> {
-                        cob.constantInstruction(moduleInfos.size())
-                           .anewarray(CD_MODULE_DESCRIPTOR)
-                           .astore(MD_VAR)
-                           .aload(MD_VAR) // storing for the return at the end
-                           .aload(0)
-                           .aload(MD_VAR)
-                           .invokevirtual(
-                                   this.classDesc,
-                                   helperMethodNamePrefix + (splitModuleInfos.size() - 1),
-                                   MethodTypeDesc.of(CD_void, CD_MODULE_DESCRIPTOR.arrayType())
-                           )
-                           .areturn();
-                    });
         }
 
         /**
diff --git a/test/jdk/tools/jlink/JLink100Modules.java b/test/jdk/tools/jlink/JLink100Modules.java
index 4a6111505d2..e71206c904f 100644
--- a/test/jdk/tools/jlink/JLink100Modules.java
+++ b/test/jdk/tools/jlink/JLink100Modules.java
@@ -27,8 +27,10 @@ import java.nio.file.Paths;
 import java.util.Arrays;
 import java.util.StringJoiner;
 import java.util.spi.ToolProvider;
+
 import tests.JImageGenerator;
 import tests.JImageGenerator.JLinkTask;
+
 /*
  * @test
  * @summary Make sure that 100 modules can be linked using jlink.
@@ -46,9 +48,9 @@ import tests.JImageGenerator.JLinkTask;
  */
 public class JLink100Modules {
     private static final ToolProvider JAVAC_TOOL = ToolProvider.findFirst("javac")
-                                                               .orElseThrow(() -> new RuntimeException("javac tool not found"));
+            .orElseThrow(() -> new RuntimeException("javac tool not found"));
     private static final ToolProvider JLINK_TOOL = ToolProvider.findFirst("jlink")
-                                                               .orElseThrow(() -> new RuntimeException("jlink tool not found"));
+            .orElseThrow(() -> new RuntimeException("jlink tool not found"));
 
     static void report(String command, String[] args) {
         System.out.println(command + " " + String.join(" ", Arrays.asList(args)));
@@ -77,9 +79,10 @@ public class JLink100Modules {
             StringBuilder builder = new StringBuilder("module ");
             builder.append(name).append(" {");
 
-            for (int j = 0; j < i; j++) {
-                builder.append("requires module" + j + "x;");
+            if (i != 0) {
+                builder.append("requires module0x;");
             }
+
             builder.append("}\n");
             Files.writeString(moduleDir.resolve("module-info.java"), builder.toString());
             mainModuleInfoContent.add(name);
@@ -106,7 +109,7 @@ public class JLink100Modules {
 
         String out = src.resolve("out").toString();
 
-        javac(new String[] {
+        javac(new String[]{
                 "-d", out,
                 "--module-source-path", src.toString(),
                 "--module", "bug8240567x"
@@ -116,6 +119,7 @@ public class JLink100Modules {
                 .modulePath(out)
                 .output(src.resolve("out-jlink"))
                 .addMods("bug8240567x")
-                .call().assertSuccess();
+                .call()
+                .assertSuccess();
     }
 }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1594471485

From mbaesken at openjdk.org  Fri Jun 16 10:52:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jun 2023 10:52:28 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
Message-ID: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>

After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :

java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)

Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

-------------

Commit messages:
 - JDK-8310191

Changes: https://git.openjdk.org/jdk/pull/14515/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310191
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14515/head:pull/14515

PR: https://git.openjdk.org/jdk/pull/14515

From coffeys at openjdk.org  Fri Jun 16 11:14:38 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 16 Jun 2023 11:14:38 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v4]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <foYZ_5ForzAzy0zm7FVeEKf5rBQol9ZEi3TqN4Zcg_k=.2ec588ec-e022-4dee-8374-885063658c4f@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor out security code to helper class
 - Print aliases. Order Provider type/service output.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/55a85e38..020a1863

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=02-03

  Stats: 350 lines in 3 files changed: 211 ins; 133 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From coffeys at openjdk.org  Fri Jun 16 11:14:39 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 16 Jun 2023 11:14:39 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <GB27jUi0roXw0cNa0MmzEAvmbi89ROVQnLz-hPxdEmE=.ed30bc04-b422-4ea2-ac35-70afe079d979@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
 <GB27jUi0roXw0cNa0MmzEAvmbi89ROVQnLz-hPxdEmE=.ed30bc04-b422-4ea2-ac35-70afe079d979@github.com>
Message-ID: <PgWeqkKVTKOtwRHWr5TfXs77R7k8u-SWUOxaHkZSLf0=.6b9109c2-e744-4e12-a810-735f7ffc5523@github.com>

On Wed, 14 Jun 2023 12:46:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Incorporate review comments from Roger and tweak some code
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 357:
> 
>> 355:     private static void printSecuritySummarySettings() {
>> 356:         ostream.println("Security settings summary: " + "\n" +
>> 357:                 INDENT + "Use \"-XshowSettings:security\" for verbose details\n");
> 
> Is it helpful to list sub-options here?

I think it might be better to delegate to `java -X` help output actually. tweaked code in this area. (I could see the subcommand options becoming inaccurate if we add more such subcommands in the future). -X help output should be our reference

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 378:
> 
>> 376:                 ostream.println(TWOINDENT + key + "=");
>> 377:                 List.of(val.split(",")).forEach(
>> 378:                         s -> ostream.println(THREEINDENT + s.trim() + ","));
> 
> Will this print a comma for the last line?

yes, I was hoping it wouldn't be an issue! modified code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232108994
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232107328

From coffeys at openjdk.org  Fri Jun 16 11:14:39 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 16 Jun 2023 11:14:39 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <xNjtXaxdTgE_Sfb1bq_3mzqmgygsDu9saCAzWjklx5A=.fd891696-ea6c-4977-9a3a-d9308c87b8e7@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
 <jetA7idd-bsxLPc2EoqKZrDsCMK5xqEkJdyTUI7di9w=.89907da9-0c04-453b-a9d4-7f609a196212@github.com>
 <xNjtXaxdTgE_Sfb1bq_3mzqmgygsDu9saCAzWjklx5A=.fd891696-ea6c-4977-9a3a-d9308c87b8e7@github.com>
Message-ID: <1K5PfrEc4i0qS14H3IVOBHlVLrZSzcSbMnDkbKbmbo0=.a5a99be5-cedf-427e-a334-17205534243c@github.com>

On Thu, 15 Jun 2023 06:32:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 183:
>> 
>>> 181:             case "locale":
>>> 182:                 printLocale();
>>> 183:                 break;
>> 
>> printLocale might need the same treatment to avoid printing the list of all locales by default.
>
> Have you tried putting the new code into say sun.launcher.SecuritySettings to avoid adding so much security conf code into LauncherHelper? Maybe eventually this will need to a more pluggable as -XshowSettings has grown a bit beyond what it was originally for.

Logged https://bugs.openjdk.org/browse/JDK-8310201 to track the Locale changes Alan.

Good suggestion on factoring out the security code to a helper class. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232109645

From coffeys at openjdk.org  Fri Jun 16 11:14:39 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 16 Jun 2023 11:14:39 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <PaALInMcudG6eoVORUxKPBtIAz3Au3_y_MxPc8CKm6U=.424b7902-6bb2-415c-bf3e-b359e9ef114a@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
 <vVEzRBIPmHe5JZfEUjImT7ehnbBR5mq1H8s8ACIF_ys=.d9b69bc9-79f3-480d-a0b8-80960fb96dd7@github.com>
 <PaALInMcudG6eoVORUxKPBtIAz3Au3_y_MxPc8CKm6U=.424b7902-6bb2-415c-bf3e-b359e9ef114a@github.com>
Message-ID: <1_nHxqnq9Jx8_a_WHvoxRVlO1DnnTdjGSVeyOyD7d6U=.c8e1489f-eff9-4f96-b548-d7ebd3bc83be@github.com>

On Wed, 14 Jun 2023 14:06:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 424:
>> 
>>> 422:                if (!services.isEmpty()) {
>>> 423:                    services.stream()
>>> 424:                            .sorted(Comparator.comparing(Provider.Service::getType))
>> 
>> How about sorting by algorithm within the same type?
>> 
>> Another suggestion: adding aliases to output, for example: `Signature: Ed25519 (1.3.101.112, OID.1.3.101.112)`.
>
> +1 to sorting by algorithm name within same type.

good point. done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232107493

From coffeys at openjdk.org  Fri Jun 16 11:17:01 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 16 Jun 2023 11:17:01 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
Message-ID: <6d5iDkOICVDpQQX8w35_tRV0JoNyvIoMwVand9UD2fw=.227423ad-484d-43d0-946b-6fd84938d14b@github.com>

On Wed, 14 Jun 2023 11:39:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comments from Roger and tweak some code

Incorporated all comments to date. Took Tony's point on board. The provider output format is now `type.service`

the refactoring of code into new security helper class might make it harder to determine recent changes. I committed the main changes before the refactor operation. Might make review easier :

https://github.com/openjdk/jdk/pull/14394/commits/1af66eb6362c15a92ce03b0ab8667d6d3a0cb673

Need to update details in CSR also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1594515340

From alanb at openjdk.org  Fri Jun 16 11:27:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 11:27:17 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v4]
In-Reply-To: <foYZ_5ForzAzy0zm7FVeEKf5rBQol9ZEi3TqN4Zcg_k=.2ec588ec-e022-4dee-8374-885063658c4f@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <foYZ_5ForzAzy0zm7FVeEKf5rBQol9ZEi3TqN4Zcg_k=.2ec588ec-e022-4dee-8374-885063658c4f@github.com>
Message-ID: <yEobE3u5JwbiweRgOII0ezTY8er_mVeY1E23GxVnKgk=.4f3e2888-228c-4564-9386-60fce722b1d2@github.com>

On Fri, 16 Jun 2023 11:14:38 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor out security code to helper class
>  - Print aliases. Order Provider type/service output.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 132:

> 130:                 ResourceBundle.getBundle(defaultBundleName);
> 131:     }
> 132:     static PrintStream ostream;

I don't think we want SecuritySettings accessing LauncherHelper's field like this. I assume printSecuritySetting is just missing a PrintStream parameter so that it can be called to print the security settings to a given stream.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 276:

> 274:                 first = false;
> 275:             } else { // following lines prefix with indents
> 276:                 ostream.println(TWOINDENT + s);

I assume these changes are per reverted now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232121754
PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232121990

From alanb at openjdk.org  Fri Jun 16 11:27:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 11:27:18 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v3]
In-Reply-To: <1K5PfrEc4i0qS14H3IVOBHlVLrZSzcSbMnDkbKbmbo0=.a5a99be5-cedf-427e-a334-17205534243c@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <WFTnZC4q68pWCWOXTaSXSOC6zyjDBrCPZ6rfDggnLXs=.ab0d5104-c079-4aa1-94e9-6d6b7a70cfca@github.com>
 <jetA7idd-bsxLPc2EoqKZrDsCMK5xqEkJdyTUI7di9w=.89907da9-0c04-453b-a9d4-7f609a196212@github.com>
 <xNjtXaxdTgE_Sfb1bq_3mzqmgygsDu9saCAzWjklx5A=.fd891696-ea6c-4977-9a3a-d9308c87b8e7@github.com>
 <1K5PfrEc4i0qS14H3IVOBHlVLrZSzcSbMnDkbKbmbo0=.a5a99be5-cedf-427e-a334-17205534243c@github.com>
Message-ID: <FdlUog7bq4Qh6x9XrS_8dyl41k-R1u7FPlhg8ueQWzk=.ba05f37b-4e4c-4632-8b6a-b008c1e9680d@github.com>

On Fri, 16 Jun 2023 11:09:23 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Logged https://bugs.openjdk.org/browse/JDK-8310201 to track the Locale changes Alan.

Thanks, probably should treat this as a bug for JDK 21 so that a new addition doesn't change behavior between 21 and 22.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232123081

From alanb at openjdk.org  Fri Jun 16 11:30:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 11:30:02 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v4]
In-Reply-To: <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <2Ii4s3nua2btv-6o9LswuISg6DP1hLDVBTgtPODKobM=.23b536c7-d971-4ed8-99ee-972e2cbe0dce@github.com>
Message-ID: <h4ULRj-N3KwL9KaYTicTF8J84pWe6KlVN0rk2UEhCgI=.18bfc7e6-87b5-41db-9ea4-107856094db1@github.com>

On Mon, 12 Jun 2023 05:03:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request with a new target base 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 remote-tracking branch 'upstream/master' into fix-8240567
>>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>>  - Remove "final" at "enabled" - not part of the point of this PR
>>  - Remove comments
>>  - 8240567: MethodTooLargeException thrown while creating a jlink image
>>    
>>    Co-authored-by: Christoph Schwentker <siedlerkiller at gmail.com>
>
> @koppor Is this ready for review? The other PR went through a dozens or so iterations before it was returned to draft. It seems like you were still battling with verifier errors. The comment on this PR says you it was created because a force-push so I can't tell if you the changes are ready or not.

> @AlanBateman The diff to the "old" PR #10704 is as follows. Maybe this helps at reviewing? IMHO this diff shows very good the new passing of the locals required by the deduplication functionality.

It's good that you've got to a patch that doesn't trip the verifier. It is one my list to look at the latest version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1594528830

From alanb at openjdk.org  Fri Jun 16 11:33:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 11:33:58 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <r1ReelkU691SLNwaZFqhQQnT5tBfxgHnB_TB5qO5O-Y=.4d77b16e-594f-481a-97f3-48425fef9af6@github.com>

On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

Yes, same issue as JDK-8309549.

Would you mind grouping the two tests that load the same agent library twice? That would mean the isAIX check is in one place, e.g.



diff --git a/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java b/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
index 4e341b4e274..970bade3530 100644
--- a/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
+++ b/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
@@ -119,23 +119,23 @@ class DynamicLoadWarningTest {
         test().whenRunning(loadJvmtiAgent1)
                 .stderrShouldContain(JVMTI_AGENT_WARNING);
 
-        // dynamically load loadJvmtiAgent1 twice, should be one warning on platforms
-        // that can detect if an agent library was previously loaded
-        if (!Platform.isAix()) {
-            test().whenRunning(loadJvmtiAgent1)
-                    .whenRunning(loadJvmtiAgent1)
-                    .stderrShouldContain(JVMTI_AGENT_WARNING, 1);
-        }
-
         // opt-in via command line option to allow dynamic loading of agents
         test().withOpts("-XX:+EnableDynamicAgentLoading")
                 .whenRunning(loadJvmtiAgent1)
                 .stderrShouldNotContain(JVMTI_AGENT_WARNING);
 
-        // start loadJvmtiAgent1 via the command line, then dynamically load loadJvmtiAgent1
-        test().withOpts("-agentpath:" + jvmtiAgentPath1)
-                .whenRunning(loadJvmtiAgent1)
-                .stderrShouldNotContain(JVMTI_AGENT_WARNING);
+        // test behavior on platforms that can detect if an agent library was previously loaded
+        if (!Platform.isAix()) {
+            // start loadJvmtiAgent1 via the command line, then dynamically load loadJvmtiAgent1
+            test().withOpts("-agentpath:" + jvmtiAgentPath1)
+                    .whenRunning(loadJvmtiAgent1)
+                    .stderrShouldNotContain(JVMTI_AGENT_WARNING);
+
+            // dynamically load loadJvmtiAgent1 twice, should be one warning
+            test().whenRunning(loadJvmtiAgent1)
+                    .whenRunning(loadJvmtiAgent1)
+                    .stderrShouldContain(JVMTI_AGENT_WARNING, 1);
+        }
     }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14515#issuecomment-1594532957

From mcimadamore at openjdk.org  Fri Jun 16 11:35:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 16 Jun 2023 11:35:58 GMT
Subject: RFR: 8309937: Add @sealedGraph for some Panama FFM interfaces
In-Reply-To: <9JlPBUbaxVi-E-8kyWEfIdOrOJXEedzsO-VO6LsdjUs=.9de817af-7257-46b4-abf0-063e37db1bd1@github.com>
References: <9JlPBUbaxVi-E-8kyWEfIdOrOJXEedzsO-VO6LsdjUs=.9de817af-7257-46b4-abf0-063e37db1bd1@github.com>
Message-ID: <gT_i9sDPCRtOWBzhuQ4s5gaARW5qaMBryCgkNhN-GXQ=.5211473a-ab4c-4e38-8f03-67713f713703@github.com>

On Tue, 13 Jun 2023 14:13:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@sealedGraph` to `GroupLayout` so the latter will be rendered in the javadocs the same way the other layouts that has public sub-interfaces.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14449#pullrequestreview-1483265666

From aboldtch at openjdk.org  Fri Jun 16 11:41:14 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 11:41:14 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix wrong ZGenerational flag in VectorRebracket128Test.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14509/files
  - new: https://git.openjdk.org/jdk/pull/14509/files/5c0c0bda..e571b87f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

PR: https://git.openjdk.org/jdk/pull/14509

From stefank at openjdk.org  Fri Jun 16 11:47:58 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 11:47:58 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <DD112bPIhXJScIUoRZ66n3fOFY0qVi17pZqs535oN3c=.ebe61b64-0869-4bfc-80dc-1e532a1be770@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Looks good.

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1483282594

From pminborg at openjdk.org  Fri Jun 16 11:50:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 16 Jun 2023 11:50:09 GMT
Subject: Integrated: 8309937: Add @sealedGraph for some Panama FFM interfaces
In-Reply-To: <9JlPBUbaxVi-E-8kyWEfIdOrOJXEedzsO-VO6LsdjUs=.9de817af-7257-46b4-abf0-063e37db1bd1@github.com>
References: <9JlPBUbaxVi-E-8kyWEfIdOrOJXEedzsO-VO6LsdjUs=.9de817af-7257-46b4-abf0-063e37db1bd1@github.com>
Message-ID: <kdoBp4mRu7seidmRHEQ4kWuvQteZ4W_X4jYdls8RTI4=.455cec56-4d55-48d5-8786-2e92ddd71b4e@github.com>

On Tue, 13 Jun 2023 14:13:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes adding `@sealedGraph` to `GroupLayout` so the latter will be rendered in the javadocs the same way the other layouts that has public sub-interfaces.

This pull request has now been integrated.

Changeset: b412fc79
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8309937: Add @sealedGraph for some Panama FFM interfaces

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14449

From mbaesken at openjdk.org  Fri Jun 16 11:59:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jun 2023 11:59:39 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX [v2]
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Rearrange and simplify test coding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14515/files
  - new: https://git.openjdk.org/jdk/pull/14515/files/8694eb48..af005ebc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14515&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14515&range=00-01

  Stats: 15 lines in 1 file changed: 6 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14515/head:pull/14515

PR: https://git.openjdk.org/jdk/pull/14515

From mbaesken at openjdk.org  Fri Jun 16 11:59:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jun 2023 11:59:39 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <YO_meYD1ENUnnBA2AS_DLqLzQVawrxX4QmGeXgVR3aI=.890ab38c-afe0-429d-92de-785b1ce040b1@github.com>

On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

Hi Alan, I adjusted / simplified the coding.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14515#issuecomment-1594561066

From eosterlund at openjdk.org  Fri Jun 16 12:07:00 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 Jun 2023 12:07:00 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <G9Rk1_psrvYyebtTVJBVhAjrIyvfGwn1AiXCJZkZLxM=.5c2ef27a-7498-4f31-96e4-588c3d33b307@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1483348038

From duke at openjdk.org  Fri Jun 16 12:14:04 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 12:14:04 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
Message-ID: <CYiUcWIBmpqDZBnDtPrS0da8Evu0Xm9VOUOgA1yr5_Q=.a0ac9e38-9f75-4eca-b078-e8f48add366f@github.com>

On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:

> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),

don't lines 147 and 148 above already guarantee the language and region have correct case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232167067

From coffeys at openjdk.org  Fri Jun 16 12:14:49 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 16 Jun 2023 12:14:49 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Pass PrintStream to security helper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/020a1863..91dc41f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=03-04

  Stats: 14 lines in 2 files changed: 5 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From aph at openjdk.org  Fri Jun 16 12:24:12 2023
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 16 Jun 2023 12:24:12 GMT
Subject: Integrated: 8308609: java/lang/ScopedValue/StressStackOverflow.java
 fails with "-XX:-VMContinuations"
In-Reply-To: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
Message-ID: <-k0WD-Fg3ug-he_MdJB-7_Oa9Gv-DN3XPp_l7UV826A=.e08cf5a0-382e-4c41-9b3d-8faadd792ba5@github.com>

On Fri, 9 Jun 2023 16:53:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
> 
> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
> 
> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.

This pull request has now been integrated.

Changeset: 44a8aa06
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44a8aa0691f046d720a789a89c9039a010658f0c
Stats:     109 lines in 7 files changed: 40 ins; 28 del; 41 mod

8308609: java/lang/ScopedValue/StressStackOverflow.java fails with "-XX:-VMContinuations"

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14399

From alanb at openjdk.org  Fri Jun 16 12:26:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 12:26:06 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <YO_meYD1ENUnnBA2AS_DLqLzQVawrxX4QmGeXgVR3aI=.890ab38c-afe0-429d-92de-785b1ce040b1@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
 <YO_meYD1ENUnnBA2AS_DLqLzQVawrxX4QmGeXgVR3aI=.890ab38c-afe0-429d-92de-785b1ce040b1@github.com>
Message-ID: <n2iDDblzaeITDPyAddAet3LWMg0Qhs3egljv7VXvC2Y=.b9a85a1b-1e34-43b1-939a-6f5213cd9670@github.com>

On Fri, 16 Jun 2023 11:54:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, I adjusted / simplified the coding.

Thanks for taking the suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14515#issuecomment-1594595016

From alanb at openjdk.org  Fri Jun 16 12:26:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 12:26:04 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX [v2]
In-Reply-To: <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
 <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
Message-ID: <g-szoukYvEplMBy-5Z17XLTuTF0_nzi5_hrP995YhDw=.e8a87b2d-bfb2-4525-a05f-42197850e6c4@github.com>

On Fri, 16 Jun 2023 11:59:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>> 
>> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
>> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
>> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
>> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> 
>> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange and simplify test coding

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14515#pullrequestreview-1483385221

From duke at openjdk.org  Fri Jun 16 12:49:06 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 12:49:06 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
Message-ID: <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>

On Tue, 13 Jun 2023 17:56:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:

> 166:         // BaseLocale as the key. The returned "normalized" instance
> 167:         // can subsequently be used by the Locale instance which
> 168:         // guarantees the locale components are properly cased/interned.

Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.




    public static BaseLocale getInstance(String language, String script,
                                         String region, String variant) {
        if (script == null) {
            script = "";
        } else {
            script = getCanonicalString(script, LocaleUtils::toTitleString);
        }

        if (region == null) {
            region = "";
        } else {
            region = getCanonicalString(region, LocaleUtils::toUpperString);
        }

        if (language == null) {
            language = "";
        } else {
            language = getCanonicalString(language, LocaleUtils::toLowerString);
        }
        
        if (variant == null) {
            variant = "";
        } else {
            variant = getCanonicalString(variant, Function.identity());
        }
        ...
        return new BaseLocale(language, script, region, variant);
    }



    private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();

    static {
        // prime the old iso codes
        CANONICALIZED_STRINGS.put("he", "he");
        CANONICALIZED_STRINGS.put("iw", "iw");
        CANONICALIZED_STRINGS.put("id", "id");
        CANONICALIZED_STRINGS.put("in", "in");
        CANONICALIZED_STRINGS.put("ji", "ji");
        CANONICALIZED_STRINGS.put("yi", "yi");
    }
    
    private static String getCanonicalString(String value, Function<String, String> conversion) {
        String existing = CANONICALIZED_STRINGS.get(value);
        if (existing != null) {
            return existing;
        }

        String converted = conversion.apply(value);
        return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232205527

From alanb at openjdk.org  Fri Jun 16 12:58:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 12:58:14 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v8]
In-Reply-To: <TMS1EGwlpd8aSg7JNX7yT5QgR4UHxI1ZP57woPdb5MI=.339bb710-2e74-4a25-9966-fc0347e6c96c@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <TMS1EGwlpd8aSg7JNX7yT5QgR4UHxI1ZP57woPdb5MI=.339bb710-2e74-4a25-9966-fc0347e6c96c@github.com>
Message-ID: <jYDwdcTthKEOM-gSwnTag5LEl6ZWJW3rIrGKRbq7nWU=.e5d93340-6f39-41a0-90e2-c41add27b92e@github.com>

On Thu, 15 Jun 2023 11:45:04 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`.
>> 
>> `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM error occurs it can not recover scoped values.
>> 
>> Moving `runWith()` into the common subclass of both `VirtualThread` and `BoundVirtualThread` fixes the problem.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct catch a top level.

I didn't spot this before it was integrated but test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/getstacktr03/libgetstacktr03.cpp is sensitive to the stack trace so its like of expected frames will be take account of runWith no longer be overridden in the sub-class.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1594632634

From jjg at openjdk.org  Fri Jun 16 15:09:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Jun 2023 15:09:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>

On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594844435

From jvernee at openjdk.org  Fri Jun 16 15:15:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 16 Jun 2023 15:15:07 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates [v3]
In-Reply-To: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
References: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
Message-ID: <wBsVzg5jXH4CAULnNCasiM2UMR8McR0I5kbLHC7GVSQ=.8e4c98a5-e48b-47ac-85e4-dbef21bb0828@github.com>

> This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.
> 
> Testing: jdk-tier1,2,3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14496/files
  - new: https://git.openjdk.org/jdk/pull/14496/files/1a10d48a..478da45c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14496&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14496&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14496.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14496/head:pull/14496

PR: https://git.openjdk.org/jdk/pull/14496

From jvernee at openjdk.org  Fri Jun 16 15:15:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 16 Jun 2023 15:15:09 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates [v2]
In-Reply-To: <FzXWUHG3CaS9LKGJY7tR6_OCCXozL389gyN49k_2_74=.e5241237-0707-4c98-a167-976a9a7bd2ca@github.com>
References: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
 <FzXWUHG3CaS9LKGJY7tR6_OCCXozL389gyN49k_2_74=.e5241237-0707-4c98-a167-976a9a7bd2ca@github.com>
Message-ID: <G2YKWbN8WAjfmc9KyqaC8D5QdQYDoWkN3gHz33GYqoA=.a4c1170c-ac22-414a-b741-60477dfdf81b@github.com>

On Fri, 16 Jun 2023 01:53:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.
>> 
>> Testing: jdk-tier1,2,3
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - typo
>  - polish javadoc

Updated the javadoc for the void case after some offline discussion on the wording. It should be much simpler now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14496#issuecomment-1594847101

From mcimadamore at openjdk.org  Fri Jun 16 15:15:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 16 Jun 2023 15:15:33 GMT
Subject: RFR: 8310157: Allow void-returning filters for
 MethodHandles::collectCoordinates [v3]
In-Reply-To: <wBsVzg5jXH4CAULnNCasiM2UMR8McR0I5kbLHC7GVSQ=.8e4c98a5-e48b-47ac-85e4-dbef21bb0828@github.com>
References: <ckbzdAw2VHCTf3MW8QgMESthhJkZH3ySrdr2GokqyRw=.89c18fd7-8a06-4ac3-9a0b-8067f08052be@github.com>
 <wBsVzg5jXH4CAULnNCasiM2UMR8McR0I5kbLHC7GVSQ=.8e4c98a5-e48b-47ac-85e4-dbef21bb0828@github.com>
Message-ID: <emkdUQorM2FCwZjoJGTuxIUn-mWuO2zmeFfWYTtWoko=.fa74aaf3-ec47-4b1e-a5e0-05859ece194a@github.com>

On Fri, 16 Jun 2023 15:15:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch changes the implementation of `MethodHandles::collectCoordinates` to allow using filters that return `void`. This brings the behavior in line with the previously existing `MethodHandles::collectArgument` which operates on MethodHandles rather than VarHandles.
>> 
>> Testing: jdk-tier1,2,3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update javadoc

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14496#pullrequestreview-1483739880

From rriggs at openjdk.org  Fri Jun 16 15:19:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 15:19:05 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
Message-ID: <VrruC56FGROztfBOMCZRpl_07U9H_JVfPoK3DmaLH3w=.98a6c322-70f7-437d-a77f-3930349af313@github.com>

On Fri, 16 Jun 2023 12:14:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass PrintStream to security helper

src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66:

> 64:                 ostream.println("Unrecognized security subcommand. See \"java -X\" for help");
> 65:                 ostream.println("Printing all security settings");
> 66:                 printAllSecurityConfig();

The error message is going to get lost in the volume of settings.
Allowing bad command input reinforces learning the wrong suboption; though it may duplicate the help, I'd print the allowed options.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232388914

From rriggs at openjdk.org  Fri Jun 16 15:34:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 15:34:17 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements
In-Reply-To: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
Message-ID: <ruaxguMiGiXY2Hb52-7NwOSmUNLUyZN4FCgx3O3YoHg=.539d1f5d-f709-4e4f-9cdb-d9638ef50eaf@github.com>

On Thu, 15 Jun 2023 22:38:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.

src/java.base/share/classes/java/util/Deque.java line 626:

> 624:      * inverse-ordered method of this Deque. For example, the {@code getFirst}
> 625:      * method of the returned view delegates to the {@code getLast} method of
> 626:      * this Deque.

The description is general and using 'For example" avoids having to be specific about every operation.
The term "inverse-ordered" is new to this context and perhaps should be "reverse-ordered".
"inverse" does appear in a few other class descriptions for SequencedXXX but its relation to "reverse" may not be clear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14504#discussion_r1232405338

From naoto at openjdk.org  Fri Jun 16 17:16:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:16:33 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
Message-ID: <mnwQXQ-yvvAdB4JlfTC3NwMpbuEENwDTX0GeETglGh0=.9054a675-049f-4dfb-a847-4e93fea5020f@github.com>

On Fri, 16 Jun 2023 15:06:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
>
>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
> 
> 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
> 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.
> 3. The iteration order would be undefined when resources are removed from one or more resource files

Makes sense. Thanks for the explanation @jonathan-gibbons

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594999086

From naoto at openjdk.org  Fri Jun 16 17:22:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:22:04 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
Message-ID: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>

On Fri, 16 Jun 2023 12:46:01 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing review comments
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
> 
>> 166:         // BaseLocale as the key. The returned "normalized" instance
>> 167:         // can subsequently be used by the Locale instance which
>> 168:         // guarantees the locale components are properly cased/interned.
> 
> Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
> my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.
> 
> 
> 
> 
>     public static BaseLocale getInstance(String language, String script,
>                                          String region, String variant) {
>         if (script == null || script.isEmpty()) {
>             script = "";
>         } else {
>             script = getCanonicalString(script, LocaleUtils::toTitleString);
>         }
> 
>         if (region == null || region.isEmpty()) {
>             region = "";
>         } else {
>             region = getCanonicalString(region, LocaleUtils::toUpperString);
>         }
> 
>         if (language == null || language.isEmpty()) {
>             language = "";
>         } else {
>             language = getCanonicalString(language, LocaleUtils::toLowerString);
>         }
>         
>         if (variant == null || variant.isEmpty()) {
>             variant = "";
>         } else {
>             variant = getCanonicalString(variant, Function.identity());
>         }
>         ...
>         return new BaseLocale(language, script, region, variant);
>     }
> 
> 
> 
>     private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();
> 
>     static {
>         // prime the old iso codes
>         CANONICALIZED_STRINGS.put("he", "he");
>         CANONICALIZED_STRINGS.put("iw", "iw");
>         CANONICALIZED_STRINGS.put("id", "id");
>         CANONICALIZED_STRINGS.put("in", "in");
>         CANONICALIZED_STRINGS.put("ji", "ji");
>         CANONICALIZED_STRINGS.put("yi", "yi");
>     }
>     
>     private static String getCanonicalString(String value, Function<String, String> conversion) {
>         String existing = CANONICALIZED_STRINGS.get(value);
>         if (existing != null) {
>             return existing;
>         }
> 
>         String converted = conversion.apply(value);
>         return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);
>     }

Interning components in a Locale instance (through BaseLocale) is a long standing behavior. Changing it could break apps that might have relied on it (using `==` for comparison)

> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
> 
>> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
>> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
>> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),
> 
> don't lines 147 and 148 above already guarantee the language and region have correct case?

147,148 are in `getInstance()` and the BaseLocale key here is created with a constructor, which simply copies the passed arguments. So normalization is needed here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232528918
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232528986

From dcubed at openjdk.org  Fri Jun 16 17:42:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:11 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
Message-ID: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>

A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

-------------

Commit messages:
 - 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing

Changes: https://git.openjdk.org/jdk/pull/14524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310211
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14524/head:pull/14524

PR: https://git.openjdk.org/jdk/pull/14524

From mikael at openjdk.org  Fri Jun 16 17:42:11 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 16 Jun 2023 17:42:11 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
Message-ID: <4-EbMiHgV6CKGswkciMMgncw2MLV3KAP3bTVudtWrVk=.945d6abf-3829-4723-bd1c-6e80a9204334@github.com>

On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

Marked as reviewed by mikael (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14524#pullrequestreview-1484002823

From dcubed at openjdk.org  Fri Jun 16 17:42:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:12 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
Message-ID: <_qrYWoQbCLdMRPRadZ5wIyrK86CXwLfdDDvSPnzP9po=.e74c22d6-7d12-4d27-99da-b95e81757172@github.com>

On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

This fix is being tested with an urgent Mach5 Tier1.

macosx-aarch64-debug has passed the test when it failed before.

linux-x64-debug has passed the test where it failed before...

windows-x64-debug has passed the test where it failed before...

linux-aarch64-debug has passed the test where it failed before...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595004554
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595005744
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595016095
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595020596
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595022380

From dcubed at openjdk.org  Fri Jun 16 17:42:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:12 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <4-EbMiHgV6CKGswkciMMgncw2MLV3KAP3bTVudtWrVk=.945d6abf-3829-4723-bd1c-6e80a9204334@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
 <4-EbMiHgV6CKGswkciMMgncw2MLV3KAP3bTVudtWrVk=.945d6abf-3829-4723-bd1c-6e80a9204334@github.com>
Message-ID: <qjVeynrlIVBYMzKPDgZi2OfyS_t7WErYKi9eLFxqdow=.e54a25d9-9990-45a0-a25d-75f44f1dc7d7@github.com>

On Fri, 16 Jun 2023 17:26:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the review!

It appears that the bots are running very, very slow since my various pull request
commands have not yet all been processed... It's not being a quiet Friday at all...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595015175

From dcubed at openjdk.org  Fri Jun 16 17:42:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:12 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
Message-ID: <325lC2LYpGLcJe2-ZxSE1Xo_xap2JQJy3DJNEZtS2oU=.a7b657ff-6f32-4a0e-b666-a1d0673a8b60@github.com>

On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

This pull request has now been integrated.

Changeset: 16134f44
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16134f44221e46f71d91fdba08e30705b0e1f92f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: mikael

-------------

PR: https://git.openjdk.org/jdk/pull/14524

From dcubed at openjdk.org  Fri Jun 16 17:58:43 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:58:43 GMT
Subject: RFR: 8308609: java/lang/ScopedValue/StressStackOverflow.java fails
 with "-XX:-VMContinuations" [v6]
In-Reply-To: <Y7YbetYlUcOQVcz0F4v5TKldlJr_JnjVl_Mhi-IUOZs=.91765ef2-33ad-4ed1-a497-96c5be43e9a0@github.com>
References: <XbAOpzTrb_mlDxteZeIp4w1HACYRBnQbmshai4grNtc=.0d289b6e-f790-4bc3-97ec-86ae04b795a0@github.com>
 <AVxbiBLRheDJc_UeRWIaGoc3qyrkhiU4mQPQJGgd0WQ=.cabe90a4-9211-4921-8d85-e547e233b2b5@github.com>
 <Bn2pJA8m_Y5vcfNlOZEeFE8zdpsO87fgTOiQJPpkvpQ=.bca324da-663a-4188-8abe-b8a42c4fb8ee@github.com>
 <Y7YbetYlUcOQVcz0F4v5TKldlJr_JnjVl_Mhi-IUOZs=.91765ef2-33ad-4ed1-a497-96c5be43e9a0@github.com>
Message-ID: <_wK77X_fG84i2edmoU3wXVA1GgyhNMkPo80HGcIqrdo=.6e3c231e-8741-4a0b-9126-f9990d6df208@github.com>

On Wed, 14 Jun 2023 16:54:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The implementation changes look good.
>> 
>> The update to test looks okay too although I would like to see if we can do better in SVC and STS when there is a SO.  In passing, I think all usages of tlr should be replaced with ThreadLocalRandom.current().
>
>> The implementation changes look good.
>> 
>> The update to test looks okay too although I would like to see if we can do better in SVC and STS when there is a SO.
> 
> That would be nice, but it's something of a can of worms. 
> 
>> In passing, I think all usages of tlr should be replaced with ThreadLocalRandom.current().
> 
> OK.

@theRealAph -
So the GHA results for this PR show that serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03
failed. Why wasn't this addressed prior to integration? We saw 5 instances of this failure mode in
every Mach5 Tier1 and 20 instances in every Mach5 Tier3 after this PR was integrated. This was not
an intermittent failure.

I've applied the fix that @AlanBateman proposed in [JDK-8310211](https://bugs.openjdk.org/browse/JDK-8310211)
and that appears to have solved the issue for Mach5 Tier1. I'll have to wait for the
fix to reach Mach5 Tier3 before I can declare that one is also good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1595049357

From bchristi at openjdk.org  Fri Jun 16 18:07:30 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 16 Jun 2023 18:07:30 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements
In-Reply-To: <ruaxguMiGiXY2Hb52-7NwOSmUNLUyZN4FCgx3O3YoHg=.539d1f5d-f709-4e4f-9cdb-d9638ef50eaf@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
 <ruaxguMiGiXY2Hb52-7NwOSmUNLUyZN4FCgx3O3YoHg=.539d1f5d-f709-4e4f-9cdb-d9638ef50eaf@github.com>
Message-ID: <iL4tKh5haExexhG_579-Kna_GPNuIIMJHJxZ2rxqAqg=.eac3c093-4ef7-4210-addf-bb35dd1d515c@github.com>

On Fri, 16 Jun 2023 15:30:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.
>
> src/java.base/share/classes/java/util/Deque.java line 626:
> 
>> 624:      * inverse-ordered method of this Deque. For example, the {@code getFirst}
>> 625:      * method of the returned view delegates to the {@code getLast} method of
>> 626:      * this Deque.
> 
> The description is general and using 'For example" avoids having to be specific about every operation.
> The term "inverse-ordered" is new to this context and perhaps should be "reverse-ordered".
> "inverse" does appear in a few other class descriptions for SequencedXXX but its relation to "reverse" may not be clear.

Rather than describing how the methods delegate, I think we mostly want to say that 
order-sensitive operations are performed in reverse order.

I agree about, "For example", and I would keep the `getFirst` -> `getLast` part - that's a good, straighforward example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14504#discussion_r1232571578

From cjplummer at openjdk.org  Fri Jun 16 19:20:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Jun 2023 19:20:07 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX [v2]
In-Reply-To: <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
 <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
Message-ID: <JcudCdXXi_3kxS6HbWvycMoct04ebI4J8sqyuzb_8sM=.86f8aafb-730e-4ac1-8d89-10a13b5a8253@github.com>

On Fri, 16 Jun 2023 11:59:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>> 
>> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
>> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
>> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
>> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> 
>> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange and simplify test coding

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14515#pullrequestreview-1484183655

From mchung at openjdk.org  Fri Jun 16 19:23:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 19:23:09 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
Message-ID: <s4XV_5Uorg4tmIcT1LfN6nqrN9_Qz5A_eRz9mHhWzfk=.8e5cb758-324c-463b-b78b-e18539366a85@github.com>

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the note for getName

The api note is primarily regarding about 1-N Class instances from a class name because of different class loader.   For cases that are not a loadable class name or not a type descriptor, the spec of `Class::forName` and `MethodType::fromMethodDescriptorString` should specify clearly.   If not, we should clarify those specs rather than explaining the negative cases in the api note.   

I think  these API specs can be improved especially `forName` doesn't talk about the name for array type which is a fully-qualified name.  I'll create a PR for that and see if that helps the clarification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1595179872

From rriggs at openjdk.org  Fri Jun 16 19:31:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 19:31:22 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
Message-ID: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>

In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
Add javadoc @see tags to isBefore and isAfter methods

Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
The term "positive" is ambiguous, zero is considered positive and indicates equality.

-------------

Commit messages:
 - Clarify for Duration, AbstractChronology, and Chronology
 - Correct javadoc of compareInstant
 - 8310033: Improve Instant.compareTo javadoc to mention before and after

Changes: https://git.openjdk.org/jdk/pull/14479/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310033
  Stats: 60 lines in 17 files changed: 42 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14479/head:pull/14479

PR: https://git.openjdk.org/jdk/pull/14479

From rriggs at openjdk.org  Fri Jun 16 19:48:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 19:48:31 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v5]
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <DSWExGKShXAwVr5MFiVmP8ZjjJAB_BcZshvUcHkW04w=.5db619df-1c4f-4bec-991b-b0b96649ec20@github.com>

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into 8308452-cross-platform-arch
 - Remove duplicate import
 - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Correct handling of ppc64le/ppc64 using non-canonical architecture.
   Keep canonical architecture names for s390, amd/x86_64.
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Review suggestions
 - Correct address size for ARM (32-bit)
 - 8308452: Extend internal Architecture enum with byte order and address size

-------------

Changes: https://git.openjdk.org/jdk/pull/14063/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=04
  Stats: 147 lines in 5 files changed: 114 ins; 19 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From mchung at openjdk.org  Fri Jun 16 20:05:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 20:05:24 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName
Message-ID: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>

This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

-------------

Commit messages:
 - 8310242: Clarify the name parameter to Class::forName

Changes: https://git.openjdk.org/jdk/pull/14528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310242
  Stats: 18 lines in 1 file changed: 5 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Fri Jun 16 20:12:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 20:12:08 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
Message-ID: <mdswizcy9uk9fh8YFcX9DutSoFqUwuqJmPKjGKlHxlU=.97e75631-f6af-46f6-9323-4646ff68ebaf@github.com>

On Thu, 15 Jun 2023 02:38:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the note for getName

For `Class::getName`, I think #14528 should clarify it.

For `MethodType`, I suggest the following:

--- a/src/java.base/share/classes/java/lang/invoke/MethodType.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java
@@ -1161,28 +1161,29 @@ class MethodType
     }
 
     /**
-     * Finds or creates an instance of a method type, given the spelling of its bytecode descriptor.
-     * Convenience method for {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}.
+     * Finds or creates an instance of a method type of the given method descriptor
+     * (JVMS {@jvms 4.3.3}). This method is a convenience method for
+     * {@link #methodType(java.lang.Class, java.lang.Class[]) methodType}.
      * Any class or interface name embedded in the descriptor string will be
-     * resolved by the given loader (or if it is null, on the system class loader).
+     * resolved by the given loader (or if it is {@code null}, on the system class loader).
      *
      * @apiNote
      * It is possible to encounter method types which cannot be
      * constructed by this method, because their component types are
-     * not all reachable from a common class loader, or some component types
-     * cannot be {@linkplain ##descriptor described nominally}.
+     * not visible from a common class loader.
      * <p>
      * This method is included for the benefit of applications that must
      * generate bytecodes that process method handles and {@code invokedynamic}.
      * @param descriptor a bytecode-level type descriptor string "(T...)T"
      * @param loader the class loader in which to look up the types
      * @return a method type matching the bytecode-level type descriptor
-     * @throws NullPointerException if the string is null
-     * @throws IllegalArgumentException if the string is not well-formed
+     * @throws NullPointerException if the string is {@code null}
+     * @throws IllegalArgumentException if the string is not a method descriptor
      * @throws TypeNotPresentException if a named type cannot be found
      * @throws SecurityException if the security manager is present and
      *         {@code loader} is {@code null} and the caller does not have the
      *         {@link RuntimePermission}{@code ("getClassLoader")}
+     * @jvms 4.3.3 Method Descriptors
      */
     public static MethodType fromMethodDescriptorString(String descriptor, ClassLoader loader)
         throws IllegalArgumentException, TypeNotPresentException
@@ -1230,7 +1231,7 @@ class MethodType
      * fromMethodDescriptorString} which requires a method type descriptor
      * (JVMS {@jvms 4.3.3}) and a suitable class loader argument. Two distinct
      * classes which share a common name but have different class loaders will
-     * appear identical when viewed within descriptor strings.
+     * have the identical descriptor strings.
      * <p>
      * This method is included for the benefit of applications that must
      * generate bytecodes that process method handles and {@code invokedynamic}.


With these clarification, would you think it's clearer?  CNFE or IAE is thrown for the negative cases and no need to mention in API note.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1595250196

From rriggs at openjdk.org  Fri Jun 16 20:18:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 20:18:09 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <OnV6I4A02ItnMOPmxFeCrKWuGb86vaDk8Ih5y18_iew=.c5b27e6a-6a82-4f14-af1e-5ca737b4eb8b@github.com>

On Fri, 16 Jun 2023 19:58:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

src/java.base/share/classes/java/lang/Class.java line 444:

> 442:      * one or more {@code '['} followed by the binary name of the element type
> 443:      * and {@code ';'}, the element type of the array class is loaded but
> 444:      * not initialized.

Do arrays of primitive types need special treatment?  For example, "[I"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1232734681

From ascarpino at openjdk.org  Fri Jun 16 20:24:17 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Fri, 16 Jun 2023 20:24:17 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
Message-ID: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>

Hi,

I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.

There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.

Thanks

Tony

-------------

Commit messages:
 - CheckSecurityProvider test
 - fix module check test
 - whitespace and apple
 - merge
 - cleanup
 - cleanup
 - find/replace and ide screwups
 - add test
 - Initial
 - cleanup
 - ... and 4 more: https://git.openjdk.org/jdk/compare/8aad881e...85870520

Changes: https://git.openjdk.org/jdk/pull/14457/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308398
  Stats: 172 lines in 57 files changed: 62 ins; 40 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/14457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14457/head:pull/14457

PR: https://git.openjdk.org/jdk/pull/14457

From bpb at openjdk.org  Fri Jun 16 20:33:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 Jun 2023 20:33:09 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <rSLo81tXc7ApSHI_PvviTt82AmGFpFJ2aW3Rfjc6qoo=.450d8de7-8b5d-43fc-9c3c-7ab65ab9a056@github.com>

On Wed, 14 Jun 2023 20:35:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
> Add javadoc @see tags to isBefore and isAfter methods
> 
> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
> The term "positive" is ambiguous, zero is considered positive and indicates equality.

Looks good.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1484337195

From dcubed at openjdk.org  Fri Jun 16 20:34:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 20:34:08 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might
want to fix the PR description.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1595274922

From weijun at openjdk.org  Fri Jun 16 20:37:11 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 16 Jun 2023 20:37:11 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <a95LdEZ2w7mv9EzJG91ab6GEw3deLsp0JOAKVHGaOao=.56baa67f-f798-4272-9f4b-20948fa29f09@github.com>

On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.
> 
> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.
> 
> Thanks
> 
> Tony

src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 179:

> 177:             }
> 178: 
> 179:             switch (provName) {

Looks like you can use a switch expression here, i.e. `p = switch ...`.

src/jdk.crypto.ec/share/classes/module-info.java line 36:

> 34: @Deprecated(since="22", forRemoval = true)
> 35: module jdk.crypto.ec {
> 36:     //provides java.security.Provider with sun.security.ec.SunEC;

Just remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1232745489
PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1232749460

From jiangli at openjdk.org  Fri Jun 16 20:43:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 16 Jun 2023 20:43:27 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
Message-ID: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>

8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

-------------

Commit messages:
 - Backport 45414fc2dfa41cbbfc6de7fec15eb47f41cf8986

Changes: https://git.openjdk.org/jdk21/pull/26/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=26&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307858
  Stats: 224 lines in 10 files changed: 173 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk21/pull/26.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/26/head:pull/26

PR: https://git.openjdk.org/jdk21/pull/26

From lancea at openjdk.org  Fri Jun 16 20:50:08 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Jun 2023 20:50:08 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <grgPHI6Q_HdC0h2bHqDbvdT7InRcE9f2QL4dkKJrUhQ=.94abf1d7-f078-4473-87f1-a82e34ae7597@github.com>

On Wed, 14 Jun 2023 20:35:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
> Add javadoc @see tags to isBefore and isAfter methods
> 
> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
> The term "positive" is ambiguous, zero is considered positive and indicates equality.

src/java.base/share/classes/java/time/Duration.java line 1422:

> 1420:      *
> 1421:      * @param otherDuration the other duration to compare to, not null
> 1422:      * @return the comparator value is less than zero if the other duration is before,

General comment.  I am not sure that "other duration" is quite clear.  It seems that javadoc for many `compareTo` methods have not standardized on wording for describing the argument being checked.   Some include "argument" when the documentation.    Perhaps change "other duration" -> "duration argument"?

I think LocalDate::compareTo and its use of "other" is perhaps a better  example of why we might want to beef the wording up a bit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1232767375

From rriggs at openjdk.org  Fri Jun 16 20:54:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 20:54:06 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
In-Reply-To: <grgPHI6Q_HdC0h2bHqDbvdT7InRcE9f2QL4dkKJrUhQ=.94abf1d7-f078-4473-87f1-a82e34ae7597@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <grgPHI6Q_HdC0h2bHqDbvdT7InRcE9f2QL4dkKJrUhQ=.94abf1d7-f078-4473-87f1-a82e34ae7597@github.com>
Message-ID: <az9pd1flbSdQnYRDMMrN8Ldy-dTZU7U4b0vKYruR0js=.5884988c-3c24-4faa-aba1-44129938e253@github.com>

On Fri, 16 Jun 2023 20:47:39 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> src/java.base/share/classes/java/time/Duration.java line 1422:
> 
>> 1420:      *
>> 1421:      * @param otherDuration the other duration to compare to, not null
>> 1422:      * @return the comparator value is less than zero if the other duration is before,
> 
> General comment.  I am not sure that "other duration" is quite clear.  It seems that javadoc for many `compareTo` methods have not standardized on wording for describing the argument being checked.   Some include "argument" when the documentation.    Perhaps change "other duration" -> "duration argument"?
> 
> I think LocalDate::compareTo and its use of "other" is perhaps a better  example of why we might want to beef the wording up a bit

The argument name is `otherDuration` would putting the argument name in {@code} font put sufficient focus on the argument?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1232769945

From kcr at openjdk.org  Fri Jun 16 20:55:16 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Jun 2023 20:55:16 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <lQss88J_Zm8YnKy90nPTQsVjeM9bn0FlicGXMr4isbU=.86988b8f-c6c5-4c40-b78e-e750a209e746@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

As a P4 enhancement, this doesn't meet the criteria for integration into JDK 21 during [Rampdown Phase 1](https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html). You could request late approval to get this enhancement in, via the process described in [JEP 3](https://openjdk.org/jeps/3).

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595304249

From lancea at openjdk.org  Fri Jun 16 20:59:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 16 Jun 2023 20:59:07 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
In-Reply-To: <az9pd1flbSdQnYRDMMrN8Ldy-dTZU7U4b0vKYruR0js=.5884988c-3c24-4faa-aba1-44129938e253@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <grgPHI6Q_HdC0h2bHqDbvdT7InRcE9f2QL4dkKJrUhQ=.94abf1d7-f078-4473-87f1-a82e34ae7597@github.com>
 <az9pd1flbSdQnYRDMMrN8Ldy-dTZU7U4b0vKYruR0js=.5884988c-3c24-4faa-aba1-44129938e253@github.com>
Message-ID: <KByStg55iQq8CgWX63TBPjvkrHLirFUK84oWEJzHzDk=.94b0d16f-a94b-450f-ab24-b9fdcab065bd@github.com>

On Fri, 16 Jun 2023 20:51:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/Duration.java line 1422:
>> 
>>> 1420:      *
>>> 1421:      * @param otherDuration the other duration to compare to, not null
>>> 1422:      * @return the comparator value is less than zero if the other duration is before,
>> 
>> General comment.  I am not sure that "other duration" is quite clear.  It seems that javadoc for many `compareTo` methods have not standardized on wording for describing the argument being checked.   Some include "argument" when the documentation.    Perhaps change "other duration" -> "duration argument"?
>> 
>> I think LocalDate::compareTo and its use of "other" is perhaps a better  example of why we might want to beef the wording up a bit
>
> The argument name is `otherDuration` would putting the argument name in {@code} font put sufficient focus on the argument?

I think that would be fine as well as then it is clear we are referring to the argument.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1232773433

From naoto at openjdk.org  Fri Jun 16 21:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 21:02:17 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
Message-ID: <Jfrbn9kav_htg9Xsi2K0qX_DMxUTs4QAEzMKI77gj-4=.089cfa89-dcf3-4441-817b-f6a575cb4d9c@github.com>

On Fri, 16 Jun 2023 04:39:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value
>  - Review: use Naoto's recommended ja values
>  - Revert 'main.help.opt.any.file' value for _de

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/11#pullrequestreview-1484380340

From jiangli at openjdk.org  Fri Jun 16 21:08:06 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 16 Jun 2023 21:08:06 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <lQss88J_Zm8YnKy90nPTQsVjeM9bn0FlicGXMr4isbU=.86988b8f-c6c5-4c40-b78e-e750a209e746@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <lQss88J_Zm8YnKy90nPTQsVjeM9bn0FlicGXMr4isbU=.86988b8f-c6c5-4c40-b78e-e750a209e746@github.com>
Message-ID: <v7kUZ2bMVlJxgc74Ylo_HMRN1FwoLXSZX3CnM-JnLYU=.f5457210-61e9-4c85-9453-c0c402d79e30@github.com>

On Fri, 16 Jun 2023 20:52:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> As a P4 enhancement, this doesn't meet the criteria for integration into JDK 21 during [Rampdown Phase 1](https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html). You could request late approval to get this enhancement in, via the process described in [JEP 3](https://openjdk.org/jeps/3).

Thanks for the pointer, @kevinrushforth. Will follow the process.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595318981

From jlu at openjdk.org  Fri Jun 16 21:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 21:14:20 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <yxBFAdo-tYodL8exo3y2xbRz6pYcTIvYVJ8Tnbzp1WM=.80ad659c-02ea-476d-8e2a-ed80b3187880@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: a1c1d97a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto
Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a

-------------

PR: https://git.openjdk.org/jdk21/pull/11

From mchung at openjdk.org  Fri Jun 16 21:24:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 21:24:17 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v2]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <juTKflF3YCTB174m-GSe8q61WXREsQWXdmbo6u01LTw=.66d1dc2a-4fd5-42b7-abfb-d5cd27ee6598@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Clarify for an array class of primitive type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/baf56d21..b7fd0a8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=00-01

  Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Fri Jun 16 21:24:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 21:24:18 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v2]
In-Reply-To: <OnV6I4A02ItnMOPmxFeCrKWuGb86vaDk8Ih5y18_iew=.c5b27e6a-6a82-4f14-af1e-5ca737b4eb8b@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <OnV6I4A02ItnMOPmxFeCrKWuGb86vaDk8Ih5y18_iew=.c5b27e6a-6a82-4f14-af1e-5ca737b4eb8b@github.com>
Message-ID: <oeZ7ptV07sjsqI0n-ZtJFvdZBxKxrXxMVaORqjC4W1I=.97c610b6-3832-4b4b-8515-9f73fbaa6294@github.com>

On Fri, 16 Jun 2023 20:15:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify for an array class of primitive type
>
> src/java.base/share/classes/java/lang/Class.java line 444:
> 
>> 442:      * one or more {@code '['} followed by the binary name of the element type
>> 443:      * and {@code ';'}, the element type of the array class is loaded but
>> 444:      * not initialized.
> 
> Do arrays of primitive types need special treatment?  For example, "[I"

Thanks for catching it.  Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1232788281

From rriggs at openjdk.org  Fri Jun 16 21:26:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 21:26:14 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v2]
In-Reply-To: <juTKflF3YCTB174m-GSe8q61WXREsQWXdmbo6u01LTw=.66d1dc2a-4fd5-42b7-abfb-d5cd27ee6598@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <juTKflF3YCTB174m-GSe8q61WXREsQWXdmbo6u01LTw=.66d1dc2a-4fd5-42b7-abfb-d5cd27ee6598@github.com>
Message-ID: <Pqq1w_DCBJmdys5wk8sFLABSxGUAZ44k9BBBp_Cu6pU=.a649d9fb-0467-49d5-8c06-7aff98e736f0@github.com>

On Fri, 16 Jun 2023 21:24:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify for an array class of primitive type

src/java.base/share/classes/java/lang/Class.java line 448:

> 446:      * <p> To find an array class of a primitive type, the name string
> 447:      * consists of one or more {@code '['} followed by the field type descriptor
> 448:      * of the primitive type (JVMS {@jvms 4.3.2 }) e.g. {@code "[I"} to

Can we avoid mixing "i.e." and "e.g"?
There are more "For example" occurrences than either "i.e." or "e.g." 
Your call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1232792847

From mchung at openjdk.org  Fri Jun 16 21:33:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 21:33:44 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v3]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <x_1sfL9qFGvx5ZW9ejdPKpf6wmgoAeWA5eR2CkBapas=.46fd9a23-dbba-4590-aa30-1a878732132b@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/b7fd0a8e..004f35d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Fri Jun 16 21:33:44 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 16 Jun 2023 21:33:44 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v2]
In-Reply-To: <Pqq1w_DCBJmdys5wk8sFLABSxGUAZ44k9BBBp_Cu6pU=.a649d9fb-0467-49d5-8c06-7aff98e736f0@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <juTKflF3YCTB174m-GSe8q61WXREsQWXdmbo6u01LTw=.66d1dc2a-4fd5-42b7-abfb-d5cd27ee6598@github.com>
 <Pqq1w_DCBJmdys5wk8sFLABSxGUAZ44k9BBBp_Cu6pU=.a649d9fb-0467-49d5-8c06-7aff98e736f0@github.com>
Message-ID: <stfg11gt2x50e-yMTEA1uCKxg0msg8PKsUERBT5lA-g=.9caaf280-e848-4c4d-b1b0-6d9e4abd6744@github.com>

On Fri, 16 Jun 2023 21:23:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify for an array class of primitive type
>
> src/java.base/share/classes/java/lang/Class.java line 448:
> 
>> 446:      * <p> To find an array class of a primitive type, the name string
>> 447:      * consists of one or more {@code '['} followed by the field type descriptor
>> 448:      * of the primitive type (JVMS {@jvms 4.3.2 }) e.g. {@code "[I"} to
> 
> Can we avoid mixing "i.e." and "e.g"?
> There are more "For example" occurrences than either "i.e." or "e.g." 
> Your call.

ok.  is the revised version better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1232797824

From rriggs at openjdk.org  Fri Jun 16 21:43:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 21:43:06 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v3]
In-Reply-To: <x_1sfL9qFGvx5ZW9ejdPKpf6wmgoAeWA5eR2CkBapas=.46fd9a23-dbba-4590-aa30-1a878732132b@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <x_1sfL9qFGvx5ZW9ejdPKpf6wmgoAeWA5eR2CkBapas=.46fd9a23-dbba-4590-aa30-1a878732132b@github.com>
Message-ID: <bLKLQcjuffHyXgpF4zNUrOxjqMKm6YtSwH06kTu1zWA=.33549104-4d63-402b-881b-2df6c597cc0d@github.com>

On Fri, 16 Jun 2023 21:33:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Looks good, thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1484449118

From rriggs at openjdk.org  Fri Jun 16 22:12:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 16 Jun 2023 22:12:43 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>

> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
> Add javadoc @see tags to isBefore and isAfter methods
> 
> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
> The term "positive" is ambiguous, zero is considered positive and indicates equality.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Use {@code xxx} to highlight the comparison against the arg.
   Update copyrights.
 - Merge branch 'master' into 8310033-time-compareto
 - Clarify for Duration, AbstractChronology, and Chronology
 - Correct javadoc of compareInstant
 - 8310033: Improve Instant.compareTo javadoc to mention before and after
   Refine timeline order to mention before and after
   Add javadoc @see tags to isBefore and isAfter methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/61021307..cd997ede

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=00-01

  Stats: 12213 lines in 386 files changed: 3676 ins; 7398 del; 1139 mod
  Patch: https://git.openjdk.org/jdk/pull/14479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14479/head:pull/14479

PR: https://git.openjdk.org/jdk/pull/14479

From dcubed at openjdk.org  Fri Jun 16 22:13:14 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 22:13:14 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

GHA is failing on windows; is this related to this PR or something else?

@erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you
have plans to redo that testing for the JDK21 backport?

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595371284
PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595373061

From jiangli at openjdk.org  Fri Jun 16 22:35:12 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 16 Jun 2023 22:35:12 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
Message-ID: <jFn301dnjkPcyS64jHoEVVdUTL8qjCRHo4SJ31XdASo=.6f5cf120-64b4-474b-a802-d1274487d7c3@github.com>

On Fri, 16 Jun 2023 22:08:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> GHA is failing on windows; is this related to this PR or something else?

The windows build failures occur with other PRs as well, e.g. https://github.com/openjdk/jdk21/pull/24/checks?check_run_id=14317258603. They should be unrelated.


make: *** [jtdiff.gmk:36: D:/a/jdk21/jdk21/jtreg/src/build/classes.com.sun.javatest.diff.ok] Error 126
Error: Process completed with exit code 2.


I noticed these presubmit failures with `jdk` started since last week or so.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1595395385

From bpb at openjdk.org  Fri Jun 16 22:41:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 Jun 2023 22:41:09 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
Message-ID: <xHJBsZPOPUVUgbwOhvTWHNs_HuvAlJh9qk4TkwMN12o=.49f3637f-c919-46f8-a2dd-2b0ed2151850@github.com>

On Fri, 16 Jun 2023 22:12:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Clarify for Duration, AbstractChronology, and Chronology
>  - Correct javadoc of compareInstant
>  - 8310033: Improve Instant.compareTo javadoc to mention before and after
>    Refine timeline order to mention before and after
>    Add javadoc @see tags to isBefore and isAfter methods

Using `{@code}` looks good.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1484519571

From prappo at openjdk.org  Fri Jun 16 23:00:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 16 Jun 2023 23:00:11 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
Message-ID: <r2RuVqW5iF0NhWiQsKyJmuoM8UT_rHmcBscOVE2b1ew=.62a5d1c7-21b0-4565-99ee-45c36d369c54@github.com>

On Fri, 16 Jun 2023 22:12:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Clarify for Duration, AbstractChronology, and Chronology
>  - Correct javadoc of compareInstant
>  - 8310033: Improve Instant.compareTo javadoc to mention before and after
>    Refine timeline order to mention before and after
>    Add javadoc @see tags to isBefore and isAfter methods

While the new wording is clearly an improvement, this reads weird:

> @return the comparator value is less...

For readability, I'd use _which_ or _that_, depending on your preferred flavour/flavor of English.

@return the comparator value that is less...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1595417780

From duke at openjdk.org  Fri Jun 16 23:07:09 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 23:07:09 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
 <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
Message-ID: <kgHbRjygYOWymroVUQRzMTvBORaS1xA1oNntD5JLAC8=.fc94b5c2-7e76-4eea-842e-aa1416c96cc6@github.com>

On Fri, 16 Jun 2023 17:18:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 168:
>> 
>>> 166:         // BaseLocale as the key. The returned "normalized" instance
>>> 167:         // can subsequently be used by the Locale instance which
>>> 168:         // guarantees the locale components are properly cased/interned.
>> 
>> Is it truly important that the String values are interned, or is the desire simply that all refer to the same "canonical" String instance?
>> my thought is that managing the canonical String instances could avoid WeakReferences and synchronized map access and just return a new BaseLocale each time.
>> 
>> 
>> 
>> 
>>     public static BaseLocale getInstance(String language, String script,
>>                                          String region, String variant) {
>>         if (script == null || script.isEmpty()) {
>>             script = "";
>>         } else {
>>             script = getCanonicalString(script, LocaleUtils::toTitleString);
>>         }
>> 
>>         if (region == null || region.isEmpty()) {
>>             region = "";
>>         } else {
>>             region = getCanonicalString(region, LocaleUtils::toUpperString);
>>         }
>> 
>>         if (language == null || language.isEmpty()) {
>>             language = "";
>>         } else {
>>             language = getCanonicalString(language, LocaleUtils::toLowerString);
>>         }
>>         
>>         if (variant == null || variant.isEmpty()) {
>>             variant = "";
>>         } else {
>>             variant = getCanonicalString(variant, Function.identity());
>>         }
>>         ...
>>         return new BaseLocale(language, script, region, variant);
>>     }
>> 
>> 
>> 
>>     private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();
>> 
>>     static {
>>         // prime the old iso codes
>>         CANONICALIZED_STRINGS.put("he", "he");
>>         CANONICALIZED_STRINGS.put("iw", "iw");
>>         CANONICALIZED_STRINGS.put("id", "id");
>>         CANONICALIZED_STRINGS.put("in", "in");
>>         CANONICALIZED_STRINGS.put("ji", "ji");
>>         CANONICALIZED_STRINGS.put("yi", "yi");
>>     }
>>     
>>     private static String getCanonicalString(String value, Function<String, String> conversion) {
>>         String existing = CANONICALIZED_STRINGS.get(value);
>>         if (existing != null) {
>>             return existing;
>>         }
>> 
>>         String converted = conversion.apply(value);
>>         return CANONICALIZED_STRINGS.merge(converted, converted, (k,v) -> v);...
>
> Interning components in a Locale instance (through BaseLocale) is a long standing behavior. Changing it could break apps that might have relied on it (using `==` for comparison)

as in doing `"en" == locale.getLanguage()`?

In that case, the interned values could still be used as the canonical values, and the CHM can account both for case adjustments and interning (and likely faster than actually calling intern). I am curious how this does with your jmh test:



    private static final ConcurrentMap<String, String> CANONICALIZED_UPPER_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_LOWER_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_TITLE_STRINGS = new ConcurrentHashMap<>();
    private static final ConcurrentMap<String, String> CANONICALIZED_STRINGS = new ConcurrentHashMap<>();

    public static BaseLocale getInstance(String language, String script,
                                         String region, String variant) {
        if (script == null || script.isEmpty()) {
            script = "";
        } else {
            script = getCanonicalString(script, LocaleUtils::toTitleString, CANONICALIZED_TITLE_STRINGS);
        }

        if (region == null || region.isEmpty()) {
            region = "";
        } else {
            region = getCanonicalString(region, LocaleUtils::toUpperString, CANONICALIZED_UPPER_STRINGS);
        }

        if (language == null || language.isEmpty()) {
            language = "";
        } else {
            language = getCanonicalString(language, LocaleUtils::toLowerString, CANONICALIZED_LOWER_STRINGS);
        }

        if (variant == null || variant.isEmpty()) {
            variant = "";
        } else {
            variant = getCanonicalString(variant, Function.identity(), CANONICALIZED_STRINGS);
        }
        ...
        return new BaseLocale(language, script, region, variant);
    }

    private static String getCanonicalString(String value, Function<String, String> conversion, ConcurrentMap<String, String> map) {
        String existing = map.get(value);
        if (existing != null) {
            return existing;
        }

        String converted = conversion.apply(value).intern();
        // put the interned value in, keyed by the interned value
        map.putIfAbsent(converted, converted);

        // also put the interned value in for the given key, if not already present
        // this avoids future needs to apply a conversion to the value
        map.putIfAbsent(value, converted);
        return converted;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232867251

From liach at openjdk.org  Fri Jun 16 23:22:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 16 Jun 2023 23:22:10 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v3]
In-Reply-To: <x_1sfL9qFGvx5ZW9ejdPKpf6wmgoAeWA5eR2CkBapas=.46fd9a23-dbba-4590-aa30-1a878732132b@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <x_1sfL9qFGvx5ZW9ejdPKpf6wmgoAeWA5eR2CkBapas=.46fd9a23-dbba-4590-aa30-1a878732132b@github.com>
Message-ID: <hQKFS5fJP1HKR-ansM43XjlZi_xLZQaavvsegXuDv5U=.394c219b-cbff-45e2-9b86-04e65967c4de@github.com>

On Fri, 16 Jun 2023 21:33:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Changes requested by liach (Author).

src/java.base/share/classes/java/lang/Class.java line 443:

> 441:      * <p> If {@code name} denotes an array class whose element type
> 442:      * is a class or interface, the name consists of one or more {@code '['}
> 443:      * followed by the binary name of the element type and {@code ';'},

There's an L between [ and component binary name, like [Ljava.lang.Object;

-------------

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1484545741
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1232872533

From duke at openjdk.org  Fri Jun 16 23:42:07 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 16 Jun 2023 23:42:07 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v3]
In-Reply-To: <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <fCAxvr4_FpMeWhmZdgF2k3CUaPlIESDD0wda2N4haDM=.a238b319-720d-4ee2-b659-81d717a59d37@github.com>
 <SyBtZ_2foARX4ZKuCsOh1sBL8FvFIYNNx6zs_6AcMak=.6ba1413b-7d98-4351-9c29-a6af5b7ab12f@github.com>
 <fvm7OX2FjbxpRjC340G5rBAxz4qC6Qpbdc6ODFpXf3I=.8d88b6fe-b1d1-4e5b-b510-4dcecb179be5@github.com>
Message-ID: <gWkti9DR72RUYx0_08o08TjJdRAyWEZkQz5EWDkqKqE=.ad60c779-36d8-43b4-be52-5b0a8f72ffb7@github.com>

On Fri, 16 Jun 2023 17:18:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 175:
>> 
>>> 173:                             LocaleUtils.toLowerString(b.getLanguage()).intern(),
>>> 174:                             LocaleUtils.toTitleString(b.getScript()).intern(),
>>> 175:                             LocaleUtils.toUpperString(b.getRegion()).intern(),
>> 
>> don't lines 147 and 148 above already guarantee the language and region have correct case?
>
> 147,148 are in `getInstance()` and the BaseLocale key here is created with a constructor, which simply copies the passed arguments. So normalization is needed here

perhaps I am missing something, but aren't `language` and `region` being reassigned to the case adjusted values? So the values used to create the "key" BaseLocale instance reflect that case adjustment? (language is again potentially adjusted at line 162 to account for old iso codes, but that never results in the wrong case.)


        language = LocaleUtils.toLowerString(language);
        region = LocaleUtils.toUpperString(region);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1232880865

From mchung at openjdk.org  Sat Jun 17 00:35:22 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 17 Jun 2023 00:35:22 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  missing 'L' for the array class name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/004f35d5..b631c2be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=02-03

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Sat Jun 17 00:35:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 17 Jun 2023 00:35:26 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v3]
In-Reply-To: <hQKFS5fJP1HKR-ansM43XjlZi_xLZQaavvsegXuDv5U=.394c219b-cbff-45e2-9b86-04e65967c4de@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <x_1sfL9qFGvx5ZW9ejdPKpf6wmgoAeWA5eR2CkBapas=.46fd9a23-dbba-4590-aa30-1a878732132b@github.com>
 <hQKFS5fJP1HKR-ansM43XjlZi_xLZQaavvsegXuDv5U=.394c219b-cbff-45e2-9b86-04e65967c4de@github.com>
Message-ID: <SewMsiClaIG0gA2ScA3fhD8Tz1X0QpBfezs4rwoUq_A=.2103c2c1-cd5b-44ab-b34f-721a6d75ecbf@github.com>

On Fri, 16 Jun 2023 23:18:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comment
>
> src/java.base/share/classes/java/lang/Class.java line 443:
> 
>> 441:      * <p> If {@code name} denotes an array class whose element type
>> 442:      * is a class or interface, the name consists of one or more {@code '['}
>> 443:      * followed by the binary name of the element type and {@code ';'},
> 
> There's an L between [ and component binary name, like [Ljava.lang.Object;

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1232894754

From weijun at openjdk.org  Sat Jun 17 01:54:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 17 Jun 2023 01:54:12 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
Message-ID: <KW5Z-znWR2dA0uEnkQBYaBatzO69hh0lFhdJuW6T5yU=.7503aa55-1d02-43f8-a7ef-7622adaec6a4@github.com>

On Fri, 16 Jun 2023 12:14:49 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass PrintStream to security helper

src/java.base/share/classes/sun/launcher/SecuritySettings.java line 93:

> 91:         for (String key : p.stringPropertyNames().stream().sorted().toList()) {
> 92:             String val = p.getProperty(key);
> 93:             if (val.contains(",") && val.length() > 60) {

Do you want to do the same for `;`? `jceks.key.serialFilter` uses it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1232926833

From jarabekit at gmail.com  Sat Jun 17 04:33:42 2023
From: jarabekit at gmail.com (Daniel Jarabek)
Date: Sat, 17 Jun 2023 00:33:42 -0400
Subject: jspawnhelper's sometimes problematic use of argv0
Message-ID: <b5d30be9-d876-4071-dec0-a73989cfca34@gmail.com>

Hi,

While trying to run jshell in qemu-user-static using binfmt_misc 
(specifically, using this docker based tool [1]), I ran into an issue. 
Jshell would fail to start and print `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` along 
with a stack trace including `Failed to exec spawn helper`. After 
searching this error, I found JDK-8296001 [2]. This issue presented a 
very similar scenario (using a userspace architecture emulator). I 
looked into this issue and I believe I have identified the root cause.

My specific investigation was done around jdk17, but this issue also 
occurs on jdk20 and older jdk versions (though it seems like the "spawn" 
strategy is not used by default on linux with jdk 8 and 11).

Note: I use argv0 to refer to "argv[0]" to prevent confusion with footnotes.

Traditionally, argv0 contains the name of the program being executed. 
While this is more a convention than anything [3], it is very widely 
used. jspawnhelper [4] is an executable used to assist in launching 
processes via ProcessBuilder and Runtime.exec. Unlike the convention, 
jspawnhelper uses argv0 for passing data [5]. When binfmts_misc [6] 
executes an interpreter, it overwrites argv0, unless a flag is set. This 
causes jspawnhelper to fail to parse argv0 (since it's the application 
path, and not the data sent by the JDK), so it prints the warning about 
not being for general use. By setting the binfmt_misc `P` 
(preserve-argv0) flag, it preserves argv0 which fixes this problem.

Since qemu-user correctly supports this flag, all I had to do to fix the 
issue in my case was run qemu-binfmt-conf.sh with `--preserve-argv0 yes` 
to set that flag. It's likely that in the case of the above issue, the 
same problem is occurring and it may have a similar resolution. This 
could be fixed in OpenJDK by using argv1 instead, but at least in my 
case of binfmts_misc, this is an external configuration issue that can 
be easily fixed. However, I would appreciate it if someone with 
permission could comment on the above issue with a link to this email 
for anyone who runs into this in the future.

-DJ

[1] https://github.com/multiarch/qemu-user-static
[2] https://bugs.openjdk.org/browse/JDK-8296001
[3] https://stackoverflow.com/a/2051031
[4] 
https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/jspawnhelper/jspawnhelper.c
[5] 
https://github.com/openjdk/jdk/blob/bcc4d36857b0907e865d0afc4447f9b0780f8101/src/java.base/unix/native/libjava/ProcessImpl_md.c#L498-L500
[6] https://docs.kernel.org/admin-guide/binfmt-misc.html

From rpressler at openjdk.org  Sat Jun 17 09:12:16 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Sat, 17 Jun 2023 09:12:16 GMT
Subject: RFR: 8309853: StructuredTaskScope.join description improvements
In-Reply-To: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>
References: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>
Message-ID: <M39962HjzOLSQdKLFVISx8L8gyxllu3KjFRYMq2twxU=.2e22630e-de25-4405-84fa-c40964e3f37d@github.com>

On Mon, 12 Jun 2023 14:32:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope's class description introduces the join method as waiting for all subtasks to finish but the API docs for join/joinUntil are phrased in terms of waiting for all threads to finish. ShutdownOnXXX join/joinUntil inherit this description but would be clearer if their description said they wait until all subtasks finished or a subtask to succeed or fail.

Marked as reviewed by rpressler (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14419#pullrequestreview-1484745243

From alanb at openjdk.org  Sat Jun 17 12:56:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Jun 2023 12:56:07 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <a95LdEZ2w7mv9EzJG91ab6GEw3deLsp0JOAKVHGaOao=.56baa67f-f798-4272-9f4b-20948fa29f09@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <a95LdEZ2w7mv9EzJG91ab6GEw3deLsp0JOAKVHGaOao=.56baa67f-f798-4272-9f4b-20948fa29f09@github.com>
Message-ID: <hK4Q95amNQgkQrlmwHvz3ZEMABLcLLpShlaun6q2u3g=.454dadca-9af8-4963-802a-70c07d874767@github.com>

On Fri, 16 Jun 2023 20:32:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.
>> 
>> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.
>> 
>> Thanks
>> 
>> Tony
>
> src/jdk.crypto.ec/share/classes/module-info.java line 36:
> 
>> 34: @Deprecated(since="22", forRemoval = true)
>> 35: module jdk.crypto.ec {
>> 36:     //provides java.security.Provider with sun.security.ec.SunEC;
> 
> Just remove it.

Yes, it should be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1233041891

From alanb at openjdk.org  Sat Jun 17 13:13:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Jun 2023 13:13:07 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <U7q_tXOc0Epf_WwfMm42oGTLlHCm2dGTGOFKYsMPpEU=.f4fc3b28-9d7b-4994-b3ef-27a7be5558e2@github.com>

On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16. 

The proposed changes look okay, meaning it should be okay to have the SunEC provider in java.base. However, the motivation isn't clear as there isn't an issue with JCE providers in java.base using native code. I know there were non-technical issues with libsunec in the past but that would haven't prevent the SunEC code form being compiled into java.base.

I assume the main implications of the change is that 3rd party JCE providers signed with an EC certificate can now be deployed on the module path.  Another way to solve that issue is that delay verification of signed JARs until the boot layer is created - if we did that, would you still want to move the SunEC provider into java.base?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1595748679

From alanb at openjdk.org  Sat Jun 17 13:27:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Jun 2023 13:27:07 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Would you mind adding "id=default" to this test? If a test has several `@test` tags, some with an identifier, and some without, then it can be tricky to understand test selection and exclusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233062199

From alanb at openjdk.org  Sat Jun 17 13:59:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Jun 2023 13:59:16 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
Message-ID: <zwXVcS455p6aSagRP_957u3o_3HmuUFW89ucLuNInr4=.b089e6c4-752f-408e-8dfe-69347ebd2c5e@github.com>

On Sat, 17 Jun 2023 00:35:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing 'L' for the array class name

This changes look okay but they do make me wonder if we should add a note to the 2-arg Class.forName to make it clear that it does not allow class names for array types, the class name has to be a binary name.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1484828693

From duke at openjdk.org  Sat Jun 17 16:36:20 2023
From: duke at openjdk.org (duke)
Date: Sat, 17 Jun 2023 16:36:20 GMT
Subject: Withdrawn: 8304917: Remove unused function declarations in
 check_classname.h
In-Reply-To: <Nba8lcasOnPYCR6EDc7J5h0xLZFR0Q2h89WTWvazZlY=.d2d32ff7-85a0-428c-993e-28028736e377@github.com>
References: <Nba8lcasOnPYCR6EDc7J5h0xLZFR0Q2h89WTWvazZlY=.d2d32ff7-85a0-428c-993e-28028736e377@github.com>
Message-ID: <JDi0CKfr9iTaqH51_dddBvqKZJ7tOBN-kL5YJEJ7uEM=.3c2a3eaa-589d-463c-89cd-9f4ee6b6f593@github.com>

On Fri, 17 Mar 2023 14:17:00 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> Both functions "VerifyClassname" and "VerifyFixClassname" are not used. The functions that are used in the Class.c are "verifyClassname" and "verifyFixClassname", which are declared in the "check_classname.h" header

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13077

From thomas.stuefe at gmail.com  Sat Jun 17 18:20:51 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 17 Jun 2023 20:20:51 +0200
Subject: jspawnhelper's sometimes problematic use of argv0
In-Reply-To: <b5d30be9-d876-4071-dec0-a73989cfca34@gmail.com>
References: <b5d30be9-d876-4071-dec0-a73989cfca34@gmail.com>
Message-ID: <CAA-vtUwpsvqcN9c51AP8QWfQTmco4QptM35bd6pSWx4nuEBxrg@mail.gmail.com>

Hi Daniel,

thank you for that thorough analysis. I opened
https://bugs.openjdk.org/browse/JDK-8310265 to track this issue.

Looking at the code, this should be easy to fix, we would not even have to
fix jspawnhelper itself, just its spawn point.

I did a small patch which seemed to work. But this code is notorious for
being tricky and I may overlooking something. Lets see.

Cheers, Thomas





On Sat, Jun 17, 2023 at 6:33?AM Daniel Jarabek <jarabekit at gmail.com> wrote:

> Hi,
>
> While trying to run jshell in qemu-user-static using binfmt_misc
> (specifically, using this docker based tool [1]), I ran into an issue.
> Jshell would fail to start and print `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` along
> with a stack trace including `Failed to exec spawn helper`. After
> searching this error, I found JDK-8296001 [2]. This issue presented a
> very similar scenario (using a userspace architecture emulator). I
> looked into this issue and I believe I have identified the root cause.
>
> My specific investigation was done around jdk17, but this issue also
> occurs on jdk20 and older jdk versions (though it seems like the "spawn"
> strategy is not used by default on linux with jdk 8 and 11).
>
> Note: I use argv0 to refer to "argv[0]" to prevent confusion with
> footnotes.
>
> Traditionally, argv0 contains the name of the program being executed.
> While this is more a convention than anything [3], it is very widely
> used. jspawnhelper [4] is an executable used to assist in launching
> processes via ProcessBuilder and Runtime.exec. Unlike the convention,
> jspawnhelper uses argv0 for passing data [5]. When binfmts_misc [6]
> executes an interpreter, it overwrites argv0, unless a flag is set. This
> causes jspawnhelper to fail to parse argv0 (since it's the application
> path, and not the data sent by the JDK), so it prints the warning about
> not being for general use. By setting the binfmt_misc `P`
> (preserve-argv0) flag, it preserves argv0 which fixes this problem.
>
> Since qemu-user correctly supports this flag, all I had to do to fix the
> issue in my case was run qemu-binfmt-conf.sh with `--preserve-argv0 yes`
> to set that flag. It's likely that in the case of the above issue, the
> same problem is occurring and it may have a similar resolution. This
> could be fixed in OpenJDK by using argv1 instead, but at least in my
> case of binfmts_misc, this is an external configuration issue that can
> be easily fixed. However, I would appreciate it if someone with
> permission could comment on the above issue with a link to this email
> for anyone who runs into this in the future.
>
> -DJ
>
> [1] https://github.com/multiarch/qemu-user-static
> [2] https://bugs.openjdk.org/browse/JDK-8296001
> [3] https://stackoverflow.com/a/2051031
> [4]
>
> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/jspawnhelper/jspawnhelper.c
> [5]
>
> https://github.com/openjdk/jdk/blob/bcc4d36857b0907e865d0afc4447f9b0780f8101/src/java.base/unix/native/libjava/ProcessImpl_md.c#L498-L500
> [6] https://docs.kernel.org/admin-guide/binfmt-misc.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230617/ad9cb3c7/attachment.htm>

From thomas.stuefe at gmail.com  Sat Jun 17 20:43:46 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 17 Jun 2023 22:43:46 +0200
Subject: jspawnhelper's sometimes problematic use of argv0
In-Reply-To: <CAA-vtUwpsvqcN9c51AP8QWfQTmco4QptM35bd6pSWx4nuEBxrg@mail.gmail.com>
References: <b5d30be9-d876-4071-dec0-a73989cfca34@gmail.com>
 <CAA-vtUwpsvqcN9c51AP8QWfQTmco4QptM35bd6pSWx4nuEBxrg@mail.gmail.com>
Message-ID: <CAA-vtUwkxqpAE1Ff-Uhno_HAGMBgD9tdR+zC0etD=LR0DvNfcw@mail.gmail.com>

Mind testing https://github.com/openjdk/jdk/pull/14531 ?

On Sat, Jun 17, 2023 at 8:20?PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Daniel,
>
> thank you for that thorough analysis. I opened
> https://bugs.openjdk.org/browse/JDK-8310265 to track this issue.
>
> Looking at the code, this should be easy to fix, we would not even have to
> fix jspawnhelper itself, just its spawn point.
>
> I did a small patch which seemed to work. But this code is notorious for
> being tricky and I may overlooking something. Lets see.
>
> Cheers, Thomas
>
>
>
>
>
> On Sat, Jun 17, 2023 at 6:33?AM Daniel Jarabek <jarabekit at gmail.com>
> wrote:
>
>> Hi,
>>
>> While trying to run jshell in qemu-user-static using binfmt_misc
>> (specifically, using this docker based tool [1]), I ran into an issue.
>> Jshell would fail to start and print `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` along
>> with a stack trace including `Failed to exec spawn helper`. After
>> searching this error, I found JDK-8296001 [2]. This issue presented a
>> very similar scenario (using a userspace architecture emulator). I
>> looked into this issue and I believe I have identified the root cause.
>>
>> My specific investigation was done around jdk17, but this issue also
>> occurs on jdk20 and older jdk versions (though it seems like the "spawn"
>> strategy is not used by default on linux with jdk 8 and 11).
>>
>> Note: I use argv0 to refer to "argv[0]" to prevent confusion with
>> footnotes.
>>
>> Traditionally, argv0 contains the name of the program being executed.
>> While this is more a convention than anything [3], it is very widely
>> used. jspawnhelper [4] is an executable used to assist in launching
>> processes via ProcessBuilder and Runtime.exec. Unlike the convention,
>> jspawnhelper uses argv0 for passing data [5]. When binfmts_misc [6]
>> executes an interpreter, it overwrites argv0, unless a flag is set. This
>> causes jspawnhelper to fail to parse argv0 (since it's the application
>> path, and not the data sent by the JDK), so it prints the warning about
>> not being for general use. By setting the binfmt_misc `P`
>> (preserve-argv0) flag, it preserves argv0 which fixes this problem.
>>
>> Since qemu-user correctly supports this flag, all I had to do to fix the
>> issue in my case was run qemu-binfmt-conf.sh with `--preserve-argv0 yes`
>> to set that flag. It's likely that in the case of the above issue, the
>> same problem is occurring and it may have a similar resolution. This
>> could be fixed in OpenJDK by using argv1 instead, but at least in my
>> case of binfmts_misc, this is an external configuration issue that can
>> be easily fixed. However, I would appreciate it if someone with
>> permission could comment on the above issue with a link to this email
>> for anyone who runs into this in the future.
>>
>> -DJ
>>
>> [1] https://github.com/multiarch/qemu-user-static
>> [2] https://bugs.openjdk.org/browse/JDK-8296001
>> [3] https://stackoverflow.com/a/2051031
>> [4]
>>
>> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/jspawnhelper/jspawnhelper.c
>> [5]
>>
>> https://github.com/openjdk/jdk/blob/bcc4d36857b0907e865d0afc4447f9b0780f8101/src/java.base/unix/native/libjava/ProcessImpl_md.c#L498-L500
>> [6] https://docs.kernel.org/admin-guide/binfmt-misc.html
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230617/cba889ac/attachment-0001.htm>

From stuefe at openjdk.org  Sat Jun 17 20:48:17 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 17 Jun 2023 20:48:17 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
Message-ID: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>

Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 

jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 

For details, see linked ML discussion. 

[1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html

-------------

Commit messages:
 - JDK-8310265-jspawnhelper-argv0

Changes: https://git.openjdk.org/jdk/pull/14531/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14531&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310265
  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14531.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14531/head:pull/14531

PR: https://git.openjdk.org/jdk/pull/14531

From jarabekit at gmail.com  Sun Jun 18 00:25:42 2023
From: jarabekit at gmail.com (Daniel Jarabek)
Date: Sat, 17 Jun 2023 20:25:42 -0400
Subject: jspawnhelper's sometimes problematic use of argv0
In-Reply-To: <CAA-vtUwkxqpAE1Ff-Uhno_HAGMBgD9tdR+zC0etD=LR0DvNfcw@mail.gmail.com>
References: <b5d30be9-d876-4071-dec0-a73989cfca34@gmail.com>
 <CAA-vtUwpsvqcN9c51AP8QWfQTmco4QptM35bd6pSWx4nuEBxrg@mail.gmail.com>
 <CAA-vtUwkxqpAE1Ff-Uhno_HAGMBgD9tdR+zC0etD=LR0DvNfcw@mail.gmail.com>
Message-ID: <ae24315e-10d8-269a-2429-775091db8113@gmail.com>

Hi Thomas,

Thank you for this quick fix!

I have tested (after much difficultly getting cross compilation to work 
- a good learning experience) and this fix works for me. Using 
QEMU_STRACE, I verified that argv[0] is now the program name and argv[1] 
contains the fd data.

While you are correct, that changes to jspawnhelper aren't needed (since 
it uses argv[argc-1]), you may want to update this comment here: 
https://github.com/openjdk/jdk/blob/959a61fdd483c9523764b9ba0972f59ca06db0ee/src/java.base/unix/native/jspawnhelper/jspawnhelper.c#L139

-DJ

On 6/17/2023 16:43, Thomas St?fe wrote:
> Mind testing https://github.com/openjdk/jdk/pull/14531 ?
>
> On Sat, Jun 17, 2023 at 8:20?PM Thomas St?fe <thomas.stuefe at gmail.com> 
> wrote:
>
>     Hi Daniel,
>
>     thank you for that thorough analysis. I opened
>     https://bugs.openjdk.org/browse/JDK-8310265 to track this issue.
>
>     Looking at the code, this should be easy to fix, we would not even
>     have to fix jspawnhelper itself, just its spawn point.
>
>     I did a small patch which seemed to work. But this code is
>     notorious for being tricky and I may overlooking something. Lets see.
>
>     Cheers, Thomas
>
>
>
>
>
>     On Sat, Jun 17, 2023 at 6:33?AM Daniel Jarabek
>     <jarabekit at gmail.com> wrote:
>
>         Hi,
>
>         While trying to run jshell in qemu-user-static using binfmt_misc
>         (specifically, using this docker based tool [1]), I ran into
>         an issue.
>         Jshell would fail to start and print `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` along
>         with a stack trace including `Failed to exec spawn helper`. After
>         searching this error, I found JDK-8296001 [2]. This issue
>         presented a
>         very similar scenario (using a userspace architecture
>         emulator). I
>         looked into this issue and I believe I have identified the
>         root cause.
>
>         My specific investigation was done around jdk17, but this
>         issue also
>         occurs on jdk20 and older jdk versions (though it seems like
>         the "spawn"
>         strategy is not used by default on linux with jdk 8 and 11).
>
>         Note: I use argv0 to refer to "argv[0]" to prevent confusion
>         with footnotes.
>
>         Traditionally, argv0 contains the name of the program being
>         executed.
>         While this is more a convention than anything [3], it is very
>         widely
>         used. jspawnhelper [4] is an executable used to assist in
>         launching
>         processes via ProcessBuilder and Runtime.exec. Unlike the
>         convention,
>         jspawnhelper uses argv0 for passing data [5]. When
>         binfmts_misc [6]
>         executes an interpreter, it overwrites argv0, unless a flag is
>         set. This
>         causes jspawnhelper to fail to parse argv0 (since it's the
>         application
>         path, and not the data sent by the JDK), so it prints the
>         warning about
>         not being for general use. By setting the binfmt_misc `P`
>         (preserve-argv0) flag, it preserves argv0 which fixes this
>         problem.
>
>         Since qemu-user correctly supports this flag, all I had to do
>         to fix the
>         issue in my case was run qemu-binfmt-conf.sh with
>         `--preserve-argv0 yes`
>         to set that flag. It's likely that in the case of the above
>         issue, the
>         same problem is occurring and it may have a similar
>         resolution. This
>         could be fixed in OpenJDK by using argv1 instead, but at least
>         in my
>         case of binfmts_misc, this is an external configuration issue
>         that can
>         be easily fixed. However, I would appreciate it if someone with
>         permission could comment on the above issue with a link to
>         this email
>         for anyone who runs into this in the future.
>
>         -DJ
>
>         [1] https://github.com/multiarch/qemu-user-static
>         [2] https://bugs.openjdk.org/browse/JDK-8296001
>         [3] https://stackoverflow.com/a/2051031
>         [4]
>         https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/jspawnhelper/jspawnhelper.c
>         [5]
>         https://github.com/openjdk/jdk/blob/bcc4d36857b0907e865d0afc4447f9b0780f8101/src/java.base/unix/native/libjava/ProcessImpl_md.c#L498-L500
>         [6] https://docs.kernel.org/admin-guide/binfmt-misc.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230617/9ccf5423/attachment.htm>

From duke at openjdk.org  Sun Jun 18 18:39:10 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Sun, 18 Jun 2023 18:39:10 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
Message-ID: <wRIto64b9TFzglnew--KcUz_XzRn0_eBeVUCU_JnzI8=.1b9e8ccc-d950-493e-ad75-38e62af53a49@github.com>

On Sat, 17 Jun 2023 00:35:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing 'L' for the array class name

src/java.base/share/classes/java/lang/Class.java line 395:

> 393:      * attached thread), the system class loader is used.
> 394:      *
> 395:      * @param     className the <a href="#binary-name">binary name</a> of the class

The new text is probably more correct, but it is less easy to understand. I think "fully qualified name" of a class is a well-known term, but "binary name" is rather unknown.

I suggest changing the text to mention both terms. For example like this:

Suggestion:

     * @param     className  the <a href="#binary-name">binary name</a>) of the class, for example its fully qualified name

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1233357830

From duke at openjdk.org  Sun Jun 18 18:59:12 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Sun, 18 Jun 2023 18:59:12 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
Message-ID: <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>

On Sat, 17 Jun 2023 00:35:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing 'L' for the array class name

src/java.base/share/classes/java/lang/Class.java line 395:

> 393:      * attached thread), the system class loader is used.
> 394:      *
> 395:      * @param     className the <a href="#binary-name">binary name</a> of the class

Where do these links lead? I don't find any section with this ID in the `Class` Javadoc. Should they lead to `ClassLoader`? That Javadoc has such a section.

src/java.base/share/classes/java/lang/Class.java line 427:

> 425:      * Returns the {@code Class} object associated with the class or
> 426:      * interface with the given string name, using the given class loader.
> 427:      * Given the {@linkplain ##binary-name binary name} for a class or interface,

Is double hash a mistake?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1233359948
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1233360226

From duke at openjdk.org  Sun Jun 18 19:36:25 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Sun, 18 Jun 2023 19:36:25 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
Message-ID: <-eJOismaPqvwI-Y427qNV0bCmfscDRkUPzrLsPoTUko=.71d3ee26-3a9e-4fe9-a08d-88d5429bb3e4@github.com>

On Fri, 16 Jun 2023 22:12:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Clarify for Duration, AbstractChronology, and Chronology
>  - Correct javadoc of compareInstant
>  - 8310033: Improve Instant.compareTo javadoc to mention before and after
>    Refine timeline order to mention before and after
>    Add javadoc @see tags to isBefore and isAfter methods

>  The term "positive" is ambiguous, zero is considered positive and indicates equality.

Where did you get this idea? A "positive" means a number that is _greater_ than zero.

See both these dictionaries:

https://dictionary.cambridge.org/dictionary/english/positive
https://www.merriam-webster.com/dictionary/positive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1596244674

From duke at openjdk.org  Sun Jun 18 19:39:09 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Sun, 18 Jun 2023 19:39:09 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <r2RuVqW5iF0NhWiQsKyJmuoM8UT_rHmcBscOVE2b1ew=.62a5d1c7-21b0-4565-99ee-45c36d369c54@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
 <r2RuVqW5iF0NhWiQsKyJmuoM8UT_rHmcBscOVE2b1ew=.62a5d1c7-21b0-4565-99ee-45c36d369c54@github.com>
Message-ID: <O92G3kwdRNbA86pMTH3vVquftLYw_tnfxzOy1Yudr7w=.e0f715c8-7448-4e0f-b0bc-059d522e8ef3@github.com>

On Fri, 16 Jun 2023 22:54:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While the new wording is clearly an improvement, this reads weird:
> 
> > @return the comparator value is less...
> 

I suggest you use the safe form as the old text, which used a comma:

> ```
> @return the comparator value, that is negative...
> ```

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1596245859

From scolebourne at openjdk.org  Sun Jun 18 20:29:17 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sun, 18 Jun 2023 20:29:17 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
Message-ID: <eAdM3cKHLYj8n7Fzt5C0fKDdokpupARuFfT5NI1qpRQ=.4fea0b15-7a84-4d60-9a02-725cf71a508e@github.com>

On Fri, 16 Jun 2023 22:12:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Use {@code xxx} to highlight the comparison against the arg.
>    Update copyrights.
>  - Merge branch 'master' into 8310033-time-compareto
>  - Clarify for Duration, AbstractChronology, and Chronology
>  - Correct javadoc of compareInstant
>  - 8310033: Improve Instant.compareTo javadoc to mention before and after
>    Refine timeline order to mention before and after
>    Add javadoc @see tags to isBefore and isAfter methods

As things stand, this PR makes things worse not better I'm afraid.

src/java.base/share/classes/java/time/Duration.java line 1422:

> 1420:      *
> 1421:      * @param otherDuration the other duration to compare to, not null
> 1422:      * @return the comparator value is less than zero if the {@code otherDuration} is before,

There is no concept of before and after when talking about a `Duration`

src/java.base/share/classes/java/time/Instant.java line 1276:

> 1274:      * @param otherInstant  the other instant to compare to, not null
> 1275:      * @return the comparator value is less than zero if the {@code otherInstant} is before,
> 1276:      *          zero if they are equal, greater than zero if the {@code otherInstant} is after

Suggestion:

     * @return the comparator value - less than zero if {@code otherInstant} is before this instant,
     *          zero if they are equal, greater than zero if {@code otherInstant} is after this instant


Saying `the {@code otherInstant}` doesn't read correctly in text.

`the comparator value` needs punctuation after it in order to make sense

src/java.base/share/classes/java/time/MonthDay.java line 678:

> 676:      *
> 677:      * @param other  the other month-day to compare to, not null
> 678:      * @return the comparator value is less than zero if the {@code other} is before,

Using before/after here could be confusing, as January could be considered to be before or after July (since the year is not defined).

src/java.base/share/classes/java/time/OffsetDateTime.java line 1805:

> 1803:      *
> 1804:      * @param other  the other date-time to compare to, not null
> 1805:      * @return the comparator value is less than zero if the {@code other} is before,

As per `OffsetTime` this definition is wrong. The comparison order is not before/after.

src/java.base/share/classes/java/time/OffsetTime.java line 1284:

> 1282:      *
> 1283:      * @param other  the other time to compare to, not null
> 1284:      * @return the comparator value is less than zero if the {@code other} is before,

Using before/after here is very wrong. As described in the text above, two instances can be at the same point in time, yet still have a defined sort order.

src/java.base/share/classes/java/time/ZoneOffset.java line 717:

> 715:      *
> 716:      * @param other  the other date to compare to, not null
> 717:      * @return the comparator value is less than zero if the {@code other} is before,

It is tricky to describe an offset as before or after. If you are going to change this you will need a much better description

src/java.base/share/classes/java/time/chrono/AbstractChronology.java line 659:

> 657:      *
> 658:      * @param other  the other chronology to compare to, not null
> 659:      * @return the comparator value is less than zero if the {@code other} ID string is before,

A `Chronology` is compared by ID, not before/after

src/java.base/share/classes/java/time/chrono/ChronoZonedDateTime.java line 572:

> 570:      *
> 571:      * @param other  the other date-time to compare to, not null
> 572:      * @return the comparator value is less than zero if the {@code other} is before,

The comparison is not before/after, as the ID is taken into account

src/java.base/share/classes/java/time/chrono/Chronology.java line 810:

> 808:      *
> 809:      * @param other  the other chronology to compare to, not null
> 810:      * @return the comparator value is less than zero if the {@code other} ID string is before,

Not before/after

src/java.base/share/classes/java/time/zone/ZoneOffsetTransition.java line 403:

> 401:      *
> 402:      * @param transition  the transition to compare to, not null
> 403:      * @return the comparator value is less than zero if the {@code transition} is before,

Not before/after

-------------

Changes requested by scolebourne (Author).

PR Review: https://git.openjdk.org/jdk/pull/14479#pullrequestreview-1485184785
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233371176
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233371665
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233372314
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233372199
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233372018
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233371857
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233371782
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233372453
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233372462
PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1233372480

From ascarpino at openjdk.org  Sun Jun 18 20:30:20 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Sun, 18 Jun 2023 20:30:20 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <hK4Q95amNQgkQrlmwHvz3ZEMABLcLLpShlaun6q2u3g=.454dadca-9af8-4963-802a-70c07d874767@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <a95LdEZ2w7mv9EzJG91ab6GEw3deLsp0JOAKVHGaOao=.56baa67f-f798-4272-9f4b-20948fa29f09@github.com>
 <hK4Q95amNQgkQrlmwHvz3ZEMABLcLLpShlaun6q2u3g=.454dadca-9af8-4963-802a-70c07d874767@github.com>
Message-ID: <o1RyG5PvY6AYNyLPQKZg8V9qShYdDC8ZPqOJHOjM1wQ=.a60ea025-00d4-494f-b4d3-4bd0c0579371@github.com>

On Sat, 17 Jun 2023 12:53:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.crypto.ec/share/classes/module-info.java line 36:
>> 
>>> 34: @Deprecated(since="22", forRemoval = true)
>>> 35: module jdk.crypto.ec {
>>> 36:     //provides java.security.Provider with sun.security.ec.SunEC;
>> 
>> Just remove it.
>
> Yes, it should be removed.

Yep

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1233372709

From duke at openjdk.org  Sun Jun 18 21:02:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 18 Jun 2023 21:02:08 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
Message-ID: <w3CRIqS8l4SW_dcLksye-Kmz_SEpnd1zuIXgVOGQ3zY=.3c685d7f-f4e6-412a-94af-b5719a55fdf7@github.com>

On Sun, 18 Jun 2023 18:56:39 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missing 'L' for the array class name
>
> src/java.base/share/classes/java/lang/Class.java line 427:
> 
>> 425:      * Returns the {@code Class} object associated with the class or
>> 426:      * interface with the given string name, using the given class loader.
>> 427:      * Given the {@linkplain ##binary-name binary name} for a class or interface,
> 
> Is double hash a mistake?

That?s?a?new **Javadoc**?feature available?since **JDK?20**: [JDK?8200337] ([GH?10395])

[JDK?8200337]: https://bugs.openjdk.org/browse/JDK-8200337 "[JDK?8200337] Generalize?see and?link?tags for?user?defined?anchors"
[GH?10395]: https://github.com/openjdk/jdk/pull/10395

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1233379833

From duke at openjdk.org  Sun Jun 18 21:49:06 2023
From: duke at openjdk.org (Vladimir Petko)
Date: Sun, 18 Jun 2023 21:49:06 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]
In-Reply-To: <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
Message-ID: <v8T_p3wlPXxOQl6DcRDCx5vxmCQy5LJncqFrT-6CSdw=.3ecb5f0b-590c-4401-975a-f23597e4ea9b@github.com>

On Thu, 15 Jun 2023 17:44:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add mipsel and mips64el to the Architecture enum.
>> (Later to be backported to JDK 21)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mps64el test case

[mipsel](https://buildd.debian.org/status/fetch.php?pkg=openjdk-21&arch=mipsel&ver=21%7E27ea-4&stamp=1687097215&raw=0) and [mips64el](https://buildd.debian.org/status/fetch.php?pkg=openjdk-21&arch=mips64el&ver=21%7E27ea-4&stamp=1687090389&raw=0) builds were successful after applying this MR patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14471#issuecomment-1596277615

From liach at openjdk.org  Sun Jun 18 23:12:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 18 Jun 2023 23:12:25 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <wRIto64b9TFzglnew--KcUz_XzRn0_eBeVUCU_JnzI8=.1b9e8ccc-d950-493e-ad75-38e62af53a49@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <wRIto64b9TFzglnew--KcUz_XzRn0_eBeVUCU_JnzI8=.1b9e8ccc-d950-493e-ad75-38e62af53a49@github.com>
Message-ID: <h0oNP778SUCf5tEBpryfKvzMlNBcYryjMoOP_pEj-Xo=.0659fa25-7b84-47a1-9a10-341dc558b193@github.com>

On Sun, 18 Jun 2023 18:36:28 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missing 'L' for the array class name
>
> src/java.base/share/classes/java/lang/Class.java line 395:
> 
>> 393:      * attached thread), the system class loader is used.
>> 394:      *
>> 395:      * @param     className the <a href="#binary-name">binary name</a> of the class
> 
> The new text is probably more correct, but it is less easy to understand. I think "fully qualified name" of a class is a well-known term, but "binary name" is rather unknown.
> 
> I suggest changing the text to mention both terms. For example like this:
> 
> Suggestion:
> 
>      * @param     className  the <a href="#binary-name">binary name</a>) of the class, for example its fully qualified name

Binary name is defined in JLS. Fully qualified name is ambiguous as it may refer to the internal name or a descriptor string.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1233401865

From dholmes at openjdk.org  Mon Jun 19 01:38:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 01:38:08 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
Message-ID: <TeHXYnEHfkamyj7HVyXRxDZtRQ40rriaWSxGOZbo4QA=.9719c25a-cf82-4b5d-9083-afac801269a6@github.com>

On Sun, 18 Jun 2023 18:54:22 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   missing 'L' for the array class name
>
> src/java.base/share/classes/java/lang/Class.java line 395:
> 
>> 393:      * attached thread), the system class loader is used.
>> 394:      *
>> 395:      * @param     className the <a href="#binary-name">binary name</a> of the class
> 
> Where do these links lead? I don't find any section with this ID in the `Class` Javadoc. Should they lead to `ClassLoader`? That Javadoc has such a section.

This seems a specification change as the binary-name and FQN are not always the same. In particular for a member class `M` in class `C` the binary name is `C$M`, whereas the FQN is `C.M`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1233436089

From ascarpino at openjdk.org  Mon Jun 19 05:49:25 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 19 Jun 2023 05:49:25 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <U7q_tXOc0Epf_WwfMm42oGTLlHCm2dGTGOFKYsMPpEU=.f4fc3b28-9d7b-4994-b3ef-27a7be5558e2@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <U7q_tXOc0Epf_WwfMm42oGTLlHCm2dGTGOFKYsMPpEU=.f4fc3b28-9d7b-4994-b3ef-27a7be5558e2@github.com>
Message-ID: <mKmBD-KDBnSly6LAPlQ66ml0LGesGO3ytHfPYPuh2bw=.4ba7e7b3-7179-4e32-8649-f6a23692c4be@github.com>

On Sat, 17 Jun 2023 13:10:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > This moves the SunEC JCE Provider (Elliptic Curve) into java.base. EC has always been separate from the base module/pkg because of its dependence on a native library. That library was removed in JDK 16.
> 
> The proposed changes look okay, meaning it should be okay to have the SunEC provider in java.base. However, the motivation isn't clear as there isn't an issue with JCE providers in java.base using native code. I know there were non-technical issues with libsunec in the past but that would haven't prevent the SunEC code form being compiled into java.base.
> 

>From what I was told, the native library was one of the reasons it was not in the base pkg before modularization and just remained so afterwards.

> I assume the main implications of the change is that 3rd party JCE providers signed with an EC certificate can now be deployed on the module path. Another way to solve that issue is that delay verification of signed JARs until the boot layer is created - if we did that, would you still want to move the SunEC provider into java.base? Maybe you want it in java.base so there is an alternative to RSA in all run-time images?

Just before this review went out I tried JDK-8215932.  At this point, I'm unable to reproduce the original problem with EC JCE signed jars.  I talked to the submitter and at this point I'm not sure if JDK-8215932 was incorrect or it was fixed elsewhere. That doesn't reduce the motivation to remove the module.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1596540890

From thomas.stuefe at gmail.com  Mon Jun 19 06:02:58 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 19 Jun 2023 08:02:58 +0200
Subject: jspawnhelper's sometimes problematic use of argv0
In-Reply-To: <ae24315e-10d8-269a-2429-775091db8113@gmail.com>
References: <b5d30be9-d876-4071-dec0-a73989cfca34@gmail.com>
 <CAA-vtUwpsvqcN9c51AP8QWfQTmco4QptM35bd6pSWx4nuEBxrg@mail.gmail.com>
 <CAA-vtUwkxqpAE1Ff-Uhno_HAGMBgD9tdR+zC0etD=LR0DvNfcw@mail.gmail.com>
 <ae24315e-10d8-269a-2429-775091db8113@gmail.com>
Message-ID: <CAA-vtUz5bDOZfJnYLuYsRt8m+mt48HLyciw7jAGOp8iuO2pYxQ@mail.gmail.com>

Thank you Daniel. Comment's fixed.

Cheers, Thomas

On Sun, Jun 18, 2023 at 2:25?AM Daniel Jarabek <jarabekit at gmail.com> wrote:

> Hi Thomas,
>
> Thank you for this quick fix!
>
> I have tested (after much difficultly getting cross compilation to work -
> a good learning experience) and this fix works for me. Using QEMU_STRACE, I
> verified that argv[0] is now the program name and argv[1] contains the fd
> data.
>
> While you are correct, that changes to jspawnhelper aren't needed (since
> it uses argv[argc-1]), you may want to update this comment here:
> https://github.com/openjdk/jdk/blob/959a61fdd483c9523764b9ba0972f59ca06db0ee/src/java.base/unix/native/jspawnhelper/jspawnhelper.c#L139
>
> -DJ
>
> On 6/17/2023 16:43, Thomas St?fe wrote:
>
> Mind testing https://github.com/openjdk/jdk/pull/14531 ?
>
> On Sat, Jun 17, 2023 at 8:20?PM Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi Daniel,
>>
>> thank you for that thorough analysis. I opened
>> https://bugs.openjdk.org/browse/JDK-8310265 to track this issue.
>>
>> Looking at the code, this should be easy to fix, we would not even have
>> to fix jspawnhelper itself, just its spawn point.
>>
>> I did a small patch which seemed to work. But this code is notorious for
>> being tricky and I may overlooking something. Lets see.
>>
>> Cheers, Thomas
>>
>>
>>
>>
>>
>> On Sat, Jun 17, 2023 at 6:33?AM Daniel Jarabek <jarabekit at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> While trying to run jshell in qemu-user-static using binfmt_misc
>>> (specifically, using this docker based tool [1]), I ran into an issue.
>>> Jshell would fail to start and print `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` along
>>> with a stack trace including `Failed to exec spawn helper`. After
>>> searching this error, I found JDK-8296001 [2]. This issue presented a
>>> very similar scenario (using a userspace architecture emulator). I
>>> looked into this issue and I believe I have identified the root cause.
>>>
>>> My specific investigation was done around jdk17, but this issue also
>>> occurs on jdk20 and older jdk versions (though it seems like the "spawn"
>>> strategy is not used by default on linux with jdk 8 and 11).
>>>
>>> Note: I use argv0 to refer to "argv[0]" to prevent confusion with
>>> footnotes.
>>>
>>> Traditionally, argv0 contains the name of the program being executed.
>>> While this is more a convention than anything [3], it is very widely
>>> used. jspawnhelper [4] is an executable used to assist in launching
>>> processes via ProcessBuilder and Runtime.exec. Unlike the convention,
>>> jspawnhelper uses argv0 for passing data [5]. When binfmts_misc [6]
>>> executes an interpreter, it overwrites argv0, unless a flag is set. This
>>> causes jspawnhelper to fail to parse argv0 (since it's the application
>>> path, and not the data sent by the JDK), so it prints the warning about
>>> not being for general use. By setting the binfmt_misc `P`
>>> (preserve-argv0) flag, it preserves argv0 which fixes this problem.
>>>
>>> Since qemu-user correctly supports this flag, all I had to do to fix the
>>> issue in my case was run qemu-binfmt-conf.sh with `--preserve-argv0 yes`
>>> to set that flag. It's likely that in the case of the above issue, the
>>> same problem is occurring and it may have a similar resolution. This
>>> could be fixed in OpenJDK by using argv1 instead, but at least in my
>>> case of binfmts_misc, this is an external configuration issue that can
>>> be easily fixed. However, I would appreciate it if someone with
>>> permission could comment on the above issue with a link to this email
>>> for anyone who runs into this in the future.
>>>
>>> -DJ
>>>
>>> [1] https://github.com/multiarch/qemu-user-static
>>> [2] https://bugs.openjdk.org/browse/JDK-8296001
>>> [3] https://stackoverflow.com/a/2051031
>>> [4]
>>>
>>> https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/jspawnhelper/jspawnhelper.c
>>> [5]
>>>
>>> https://github.com/openjdk/jdk/blob/bcc4d36857b0907e865d0afc4447f9b0780f8101/src/java.base/unix/native/libjava/ProcessImpl_md.c#L498-L500
>>> [6] https://docs.kernel.org/admin-guide/binfmt-misc.html
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230619/8cc8109e/attachment-0001.htm>

From stuefe at openjdk.org  Mon Jun 19 06:07:26 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Jun 2023 06:07:26 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
Message-ID: <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>

> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
> 
> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
> 
> For details, see linked ML discussion. 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  correct comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14531/files
  - new: https://git.openjdk.org/jdk/pull/14531/files/2ec4f3b6..1ee05c05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14531&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14531&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14531.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14531/head:pull/14531

PR: https://git.openjdk.org/jdk/pull/14531

From alanb at openjdk.org  Mon Jun 19 06:19:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Jun 2023 06:19:07 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <mKmBD-KDBnSly6LAPlQ66ml0LGesGO3ytHfPYPuh2bw=.4ba7e7b3-7179-4e32-8649-f6a23692c4be@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <U7q_tXOc0Epf_WwfMm42oGTLlHCm2dGTGOFKYsMPpEU=.f4fc3b28-9d7b-4994-b3ef-27a7be5558e2@github.com>
 <mKmBD-KDBnSly6LAPlQ66ml0LGesGO3ytHfPYPuh2bw=.4ba7e7b3-7179-4e32-8649-f6a23692c4be@github.com>
Message-ID: <THZUAYU1F-43TbVVonX6radCnCOYWorfbxqWm4hz2PM=.3dfcdb82-c8bc-4ff7-a6ef-252018f5ca5f@github.com>

On Mon, 19 Jun 2023 05:46:34 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> From what I was told, the native library was one of the reasons it was not in the base pkg before modularization and just remained so afterwards.

Maybe you are thinking about the size of libsunec or non-technical issues that meant it wasn't included by some distributions? There weren't an issue with deciding which providers to include to java.base. I think the motivation for having the SunEC provider in java.base now is probably TLS so there are more secure cipher suites available for those that create a small run-image with jlink and don't include all security providers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1596574579

From aboldtch at openjdk.org  Mon Jun 19 06:55:52 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 06:55:52 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add explicit id to all Skynet.java @test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14509/files
  - new: https://git.openjdk.org/jdk/pull/14509/files/e571b87f..b262d48b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

PR: https://git.openjdk.org/jdk/pull/14509

From aboldtch at openjdk.org  Mon Jun 19 07:03:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 07:03:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>
Message-ID: <GBrJ84po6uCENIHrklbo2U9V89wEkmsL08bJIqPa4Ho=.120247b1-d582-4dbc-b6e7-264a3fb4b463@github.com>

On Sat, 17 Jun 2023 13:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong ZGenerational flag in VectorRebracket128Test.java
>
> test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Would you mind adding "id=default" to this test? If a test has several `@test` tags, some with an identifier, and some without, then it can be tricky to understand test selection and exclusion.

Done. 

I tried to reduce changes to other ids as much as possible as they may be used for problemlisting etc. The first run would have been `#id0` before and after this patch. However does not seem to be any exclusion filters in the repo for Skynet so added a default id. 

Because this patch adds extra `@test` some `#idX` will change. I've tried to double check that there are no problemlistings that depend on this, and I can find none. 

Ideally all multi `@test` tests should use explicit ids so changing that updating existing tests is less fragile with respect to exclusions. However I know that there are more gotchas here with how problemlisting works. Not sure I remember the exact details but I believe that under certain circumstances the id will be ignored, and if a problemlisting includes it, it will not filter it out. 

For now updating tests will always require going through all relevant problemlisting files and check that the exclusions are still valid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233609799

From aboldtch at openjdk.org  Mon Jun 19 07:09:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 07:09:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
Message-ID: <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>

On Fri, 16 Jun 2023 20:31:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might want to fix the PR description.

What part are you worried about? When would `vm.gc.ZSingelgen` be invalid? 

Also what part of the PR requires fixing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1596626922

From alanb at openjdk.org  Mon Jun 19 07:23:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Jun 2023 07:23:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
 <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>
Message-ID: <06Ia9w1yf91JRYaIMQAdbwKymzljIA_6mdAO22L9OYo=.f70ab943-832e-4018-ab2b-973f90f6d2b9@github.com>

On Mon, 19 Jun 2023 07:06:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might want to fix the PR description.
> 
> What part are you worried about? When would `vm.gc.ZSingelgen` be invalid?
> 
> Also what part of the PR requires fixing?

I assume Dan is pointing out the typo in the PR description ("e" and "l" have been transposed).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1596645899

From shade at openjdk.org  Mon Jun 19 07:59:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Jun 2023 07:59:07 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
Message-ID: <62FQNYbbuul3I-AOzejNwoj4GuwQuPtibavj2xK-7hE=.27227c31-cdf0-4c18-a2c9-d4f52eb094c6@github.com>

On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct comment

Paging @simonis :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14531#issuecomment-1596691062

From stuefe at openjdk.org  Mon Jun 19 08:24:09 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Jun 2023 08:24:09 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
Message-ID: <ggyTIltJr9LW8mp_MUQK-Ci0CGEAonsilxgpoIGH8tQ=.c8e8d47a-3c61-46be-8734-b5985a50c3ea@github.com>

On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct comment

and @RogerRiggs of course. I think this is simple though, and the process tests succeeded in GHAs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14531#issuecomment-1596732197

From stuefe at openjdk.org  Mon Jun 19 08:41:08 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Jun 2023 08:41:08 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
Message-ID: <CefSp9U6wnilYeIUhg9iq4gFMT74LrVQxcVYU-ZmJLQ=.de7c42fb-1235-429a-9cb1-d83857cb9694@github.com>

On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct comment

(also ran test/jdk/java/lang/Process* locally on linux x64)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14531#issuecomment-1596756036

From stuefe at openjdk.org  Mon Jun 19 09:07:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Jun 2023 09:07:11 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

I'm not the most qualified for ZGC, but I looked this over with a mind on the planned 21 backport. I wanted to check if any of the existing legacy ZGC tests had been changed, either accidentally or deliberately. This seems not be the case.

The remarks are small nits, feel free to ignore them.

How much time do we spend now in GHAs on the additional Zgenerational tests? In any case, this makes sense.

Cheers, Thomas

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 298:

> 296:         if (selectedGCMode != null) {
> 297:             args.add(selectedGCMode);
> 298:         }

just to be sure, maybe add a "must not be Z" assert in the else path?

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 58:

> 56:     public final static String ERR_MSG = "The saved state of UseCompressedOops and UseCompressedClassPointers is different from runtime, CDS will be disabled.";
> 57:     public static void main(String... args) throws Exception {
> 58:          String zGenerational = args[0];

assert not null?

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1485730970
PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233738199
PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233740188

From simonis at openjdk.org  Mon Jun 19 12:57:12 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 19 Jun 2023 12:57:12 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
Message-ID: <UBaLRHhUkYerFadTrAn4VR3DQPu9uGLfD0nRhbOPyAI=.e9f5377b-1e55-439f-8dfe-e3a732928dc2@github.com>

On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct comment

Looks good to me. While doing my recent `jspawnhelper` fixes I wondered why we're passing our arguments in `argv[0]` but I didn't wanted to change it because it is not really [required by any standard](https://stackoverflow.com/questions/2050961/is-argv0-name-of-executable-an-accepted-standard-or-just-a-common-conventi).

I agree however, that it still makes sense to adhere to conventions :) especially because this will probably simplify the handling of the next `jspawnhelper` issue because it will be easier to discover the process with system tools if something should go wrong :)

src/java.base/unix/native/libjava/ProcessImpl_md.c line 500:

> 498:     /* NULL-terminated argv array.
> 499:      * argv[0] contains path to jspawnhelper, to follow conventions.
> 500:      * argv[1] contains the fd string as argument to the helper cmd

May want to use "jspawnhelper" instead of "the helper app" and terminate the sentence with a period to be consistent with the previous comment.

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14531#pullrequestreview-1486159389
PR Review Comment: https://git.openjdk.org/jdk/pull/14531#discussion_r1234016774

From liach at openjdk.org  Mon Jun 19 13:17:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 Jun 2023 13:17:05 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <zwXVcS455p6aSagRP_957u3o_3HmuUFW89ucLuNInr4=.b089e6c4-752f-408e-8dfe-69347ebd2c5e@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <zwXVcS455p6aSagRP_957u3o_3HmuUFW89ucLuNInr4=.b089e6c4-752f-408e-8dfe-69347ebd2c5e@github.com>
Message-ID: <HvbTg6MXpb8R16xCHVSKRGml0rlJ0Zst__G6muXsUp8=.e8ac371c-6e6a-4873-a9b4-a4e872f6d712@github.com>

On Sat, 17 Jun 2023 13:56:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This changes look okay but they do make me wonder if we should add a note to the 2-arg Class.forName to make it clear that it does not allow class names for array types, the class name has to be a binary name.

In its specification:
"This method attempts to locate and load the class or interface."

"Class or interface" already precludes array classes or primitive types (8 types + void). If we need, we can add that it doesn't find primitive types or array classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14528#issuecomment-1597172838

From pminborg at openjdk.org  Mon Jun 19 15:05:36 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 19 Jun 2023 15:05:36 GMT
Subject: RFR: 8309937: Add @sealedGraph for some Panama FFM interfaces
Message-ID: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>

Hi all,

This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.

Thanks!

-------------

Commit messages:
 - Backport b412fc79c3c2548df10918090beedaf6b2d08d96

Changes: https://git.openjdk.org/jdk21/pull/34/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=34&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309937
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/34.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/34/head:pull/34

PR: https://git.openjdk.org/jdk21/pull/34

From coffeys at openjdk.org  Mon Jun 19 16:13:30 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Jun 2023 16:13:30 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v6]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <OpW5huaYq4_bEdMJdzPxl4rHnnTMd3PIKOK46iSjFOI=.dc3e411d-ab60-43f0-a3eb-19e45d01a070@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - restore more informative help message
 - Split long properties for ; also

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/91dc41f3..8abd2fe9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=04-05

  Stats: 25 lines in 1 file changed: 16 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From coffeys at openjdk.org  Mon Jun 19 16:15:13 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Jun 2023 16:15:13 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v4]
In-Reply-To: <yEobE3u5JwbiweRgOII0ezTY8er_mVeY1E23GxVnKgk=.4f3e2888-228c-4564-9386-60fce722b1d2@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <foYZ_5ForzAzy0zm7FVeEKf5rBQol9ZEi3TqN4Zcg_k=.2ec588ec-e022-4dee-8374-885063658c4f@github.com>
 <yEobE3u5JwbiweRgOII0ezTY8er_mVeY1E23GxVnKgk=.4f3e2888-228c-4564-9386-60fce722b1d2@github.com>
Message-ID: <PxIyw4VH3xCHgxPVgErFZ13nCP-aUkqDDKDbz7B4fVg=.0a8c0ee5-7132-418f-a6f3-fdb89319262a@github.com>

On Fri, 16 Jun 2023 11:23:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor out security code to helper class
>>  - Print aliases. Order Provider type/service output.
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 276:
> 
>> 274:                 first = false;
>> 275:             } else { // following lines prefix with indents
>> 276:                 ostream.println(TWOINDENT + s);
> 
> I assume these changes are be reverted now.

@AlanBateman  - I was planning to keep this trivial change. Does it not read better ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234248828

From coffeys at openjdk.org  Mon Jun 19 16:15:17 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Jun 2023 16:15:17 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <VrruC56FGROztfBOMCZRpl_07U9H_JVfPoK3DmaLH3w=.98a6c322-70f7-437d-a77f-3930349af313@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
 <VrruC56FGROztfBOMCZRpl_07U9H_JVfPoK3DmaLH3w=.98a6c322-70f7-437d-a77f-3930349af313@github.com>
Message-ID: <ezDwimwZfhuUexb121bNP1fGZjSshEE4HX59QsgqESo=.bfd42072-ce43-4749-a8ee-350be68a017f@github.com>

On Fri, 16 Jun 2023 15:15:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass PrintStream to security helper
>
> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66:
> 
>> 64:                 ostream.println("Unrecognized security subcommand. See \"java -X\" for help");
>> 65:                 ostream.println("Printing all security settings");
>> 66:                 printAllSecurityConfig();
> 
> The error message is going to get lost in the volume of settings.
> Allowing bad command input reinforces learning the wrong suboption; though it may duplicate the help, I'd print the allowed options.

@RogerRiggs  - do you mean to print nothing in the "bad command input" scenario ? The current -XshowSettings launch behaviour prints all data if a bad value is passed to it. I was mimicking this for security subcommands. 

Are you suggesting to print the relevant part of the "java -X" help menu here or is restoring the message with value subcommands sufficient ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234251237

From coffeys at openjdk.org  Mon Jun 19 16:15:19 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Jun 2023 16:15:19 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <KW5Z-znWR2dA0uEnkQBYaBatzO69hh0lFhdJuW6T5yU=.7503aa55-1d02-43f8-a7ef-7622adaec6a4@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
 <KW5Z-znWR2dA0uEnkQBYaBatzO69hh0lFhdJuW6T5yU=.7503aa55-1d02-43f8-a7ef-7622adaec6a4@github.com>
Message-ID: <oKWHsah79CnmGoN_D77vTMX142HMnbnLXmQpZ1z4JME=.29ee1e12-6950-4668-99c4-15c00a8ca459@github.com>

On Sat, 17 Jun 2023 01:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass PrintStream to security helper
>
> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 93:
> 
>> 91:         for (String key : p.stringPropertyNames().stream().sorted().toList()) {
>> 92:             String val = p.getProperty(key);
>> 93:             if (val.contains(",") && val.length() > 60) {
> 
> Do you want to do the same for `;`? `jceks.key.serialFilter` uses it.

fair point. done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234252148

From ascarpino at openjdk.org  Mon Jun 19 16:44:12 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 19 Jun 2023 16:44:12 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <BkhjBtYjGj-yPKoXgsC8JP4GSC_0nJeAlzoLiIZ7yCk=.cc6da874-c70e-4755-a7f0-8b4c5a94b927@github.com>

On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.
> 
> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.
> 
> Thanks
> 
> Tony

> 

TLS is mentioned in the CSR as a reason for the merger.  With EC not being in java.base and an alternative for RSA, it could lead to slimmed down, custom images not having the best crypto algorithms available moving in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1597475346

From alanb at openjdk.org  Mon Jun 19 17:05:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Jun 2023 17:05:22 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v4]
In-Reply-To: <yEobE3u5JwbiweRgOII0ezTY8er_mVeY1E23GxVnKgk=.4f3e2888-228c-4564-9386-60fce722b1d2@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <foYZ_5ForzAzy0zm7FVeEKf5rBQol9ZEi3TqN4Zcg_k=.2ec588ec-e022-4dee-8374-885063658c4f@github.com>
 <yEobE3u5JwbiweRgOII0ezTY8er_mVeY1E23GxVnKgk=.4f3e2888-228c-4564-9386-60fce722b1d2@github.com>
Message-ID: <MZ5M1Qly6m1B5aGTKT7g90jt2kmDDPjA4om5xpvT0C0=.71894e62-5962-49ea-ae8f-409d34b29fe4@github.com>

On Fri, 16 Jun 2023 11:23:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor out security code to helper class
>>  - Print aliases. Order Provider type/service output.
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 276:
> 
>> 274:                 first = false;
>> 275:             } else { // following lines prefix with indents
>> 276:                 ostream.println(TWOINDENT + s);
> 
> I assume these changes are be reverted now.

> @AlanBateman - I was planning to keep this trivial change. Does it not read better ?

It would be better if the name is shortened to printSecuritySettings and it takes an indent parameter, that avoid needing to change the accessibility of INDENT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234287743

From rriggs at openjdk.org  Mon Jun 19 18:25:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Jun 2023 18:25:06 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <ezDwimwZfhuUexb121bNP1fGZjSshEE4HX59QsgqESo=.bfd42072-ce43-4749-a8ee-350be68a017f@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
 <VrruC56FGROztfBOMCZRpl_07U9H_JVfPoK3DmaLH3w=.98a6c322-70f7-437d-a77f-3930349af313@github.com>
 <ezDwimwZfhuUexb121bNP1fGZjSshEE4HX59QsgqESo=.bfd42072-ce43-4749-a8ee-350be68a017f@github.com>
Message-ID: <xPVqgB0lrIJIw4_qMiP37A9rzbhDaEU8co4rWg4USuA=.16595b78-ea5a-494d-b390-3502d7b96705@github.com>

On Mon, 19 Jun 2023 16:11:12 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66:
>> 
>>> 64:                 ostream.println("Unrecognized security subcommand. See \"java -X\" for help");
>>> 65:                 ostream.println("Printing all security settings");
>>> 66:                 printAllSecurityConfig();
>> 
>> The error message is going to get lost in the volume of settings.
>> Allowing bad command input reinforces learning the wrong suboption; though it may duplicate the help, I'd print the allowed options.
>
> @RogerRiggs  - do you mean to print nothing in the "bad command input" scenario ? The current -XshowSettings launch behaviour prints all data if a bad value is passed to it. I was mimicking this for security subcommands. 
> 
> Are you suggesting to print the relevant part of the "java -X" help menu here or is restoring the message with value subcommands sufficient ?

Restoring the message with value subcommands is what I would prefer.
I do disagree with the original choice of printing everything if the command is wrong and would not propagate that behavior to the new command.  
Separately, I would consider changing the existing behavior but I suspect that would fail to achieve consensus based on compatibility concerns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234344945

From rriggs at openjdk.org  Mon Jun 19 18:32:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 19 Jun 2023 18:32:11 GMT
Subject: Integrated: 8310019: MIPS builds are broken after JDK-8304913
In-Reply-To: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
Message-ID: <6GUxHbq6xrUtptBPSOGaoL65wxkX06Ywqjye4Hi3mj0=.86efbfdd-6db6-4529-8971-ecffd8c2f796@github.com>

On Wed, 14 Jun 2023 15:04:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add mipsel and mips64el to the Architecture enum.
> (Later to be backported to JDK 21)

This pull request has now been integrated.

Changeset: 33c6ec9d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33c6ec9d4eb36649a94125aa005dc6b961dcd2c1
Stats:     26 lines in 3 files changed: 26 ins; 0 del; 0 mod

8310019: MIPS builds are broken after JDK-8304913

Reviewed-by: phh, shade, aoqi

-------------

PR: https://git.openjdk.org/jdk/pull/14471

From aoqi at openjdk.org  Mon Jun 19 18:59:17 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 19 Jun 2023 18:59:17 GMT
Subject: RFR: 8310105: LoongArch64 builds are broken after JDK-8304913 [v2]
In-Reply-To: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
References: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
Message-ID: <vC7bQ8UnTrtxBxNFxqc8QXTYLjUAdQiVKlXS9CsyTqo=.511092d9-b3e3-442e-a6f1-1c33ac4522ba@github.com>

> LoongArch64 Zero builds are broken after [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913):
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Error: jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> 
> 
> Builds tested: LoongArch64 Zero, both release and fastdebug.
> 
> If this patch conflicts with #14471, I will rebase after #14471 is integrated.

Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8310105
 - 8310105: LoongArch64 builds are broken after JDK-8304913

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14482/files
  - new: https://git.openjdk.org/jdk/pull/14482/files/351e7b42..498066a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14482&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14482&range=00-01

  Stats: 8146 lines in 308 files changed: 4925 ins; 2137 del; 1084 mod
  Patch: https://git.openjdk.org/jdk/pull/14482.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14482/head:pull/14482

PR: https://git.openjdk.org/jdk/pull/14482

From coffeys at openjdk.org  Mon Jun 19 19:43:40 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Jun 2023 19:43:40 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v7]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <GfVdDfXJhqmaytonB3J-solOd6PmXSbAG7UjUXFo6sQ=.3bf56817-ef55-4fea-8048-30b7a636b2df@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Don't allow bad subcommand values for security component

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/8abd2fe9..77c9f5e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=05-06

  Stats: 13 lines in 2 files changed: 0 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From coffeys at openjdk.org  Mon Jun 19 19:44:02 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 19 Jun 2023 19:44:02 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v5]
In-Reply-To: <xPVqgB0lrIJIw4_qMiP37A9rzbhDaEU8co4rWg4USuA=.16595b78-ea5a-494d-b390-3502d7b96705@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <c2shjXnvPkn4kbkD45TgMgKfl0rZc2r89zFXvpmaYPk=.919e6963-3106-4a28-926d-bad6ef5e67b6@github.com>
 <VrruC56FGROztfBOMCZRpl_07U9H_JVfPoK3DmaLH3w=.98a6c322-70f7-437d-a77f-3930349af313@github.com>
 <ezDwimwZfhuUexb121bNP1fGZjSshEE4HX59QsgqESo=.bfd42072-ce43-4749-a8ee-350be68a017f@github.com>
 <xPVqgB0lrIJIw4_qMiP37A9rzbhDaEU8co4rWg4USuA=.16595b78-ea5a-494d-b390-3502d7b96705@github.com>
Message-ID: <5OSXZElHFtjr7Gg1sUxoQmC0lD8hhqbO_9ljh4_PR3I=.a0a3bbd0-2b67-4e60-9d1d-1bf38589c7b8@github.com>

On Mon, 19 Jun 2023 18:21:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> @RogerRiggs  - do you mean to print nothing in the "bad command input" scenario ? The current -XshowSettings launch behaviour prints all data if a bad value is passed to it. I was mimicking this for security subcommands. 
>> 
>> Are you suggesting to print the relevant part of the "java -X" help menu here or is restoring the message with value subcommands sufficient ?
>
> Restoring the message with value subcommands is what I would prefer.
> I do disagree with the original choice of printing everything if the command is wrong and would not propagate that behavior to the new command.  
> Separately, I would consider changing the existing behavior but I suspect that would fail to achieve consensus based on compatibility concerns.

Fair point. Modified the code so that we don't print any security settings if a bad security subcommand value is specified. Info message instead. I'll update the CSR on that point also.

Agreed on the compatibility concerns of changing the existing behaviour already present in this area.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14394#discussion_r1234416659

From aoqi at openjdk.org  Mon Jun 19 21:09:12 2023
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 19 Jun 2023 21:09:12 GMT
Subject: Integrated: 8310105: LoongArch64 builds are broken after JDK-8304913
In-Reply-To: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
References: <yuFmGTzAfmgQLFqTn40dXwrLdvsLYixUHDFAqV79z7k=.400e19fd-9322-4385-8ca5-10e2248a5f0e@github.com>
Message-ID: <UMlStnt0Lkl02XYMnY3RLrNalkTifw6SgfFgw6hBNu0=.1e6bfc5b-a285-42ec-9d41-3ae2454dbbfe@github.com>

On Thu, 15 Jun 2023 04:40:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch64 Zero builds are broken after [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913):
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> Error: jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.LOONGARCH64
> 
> 
> Builds tested: LoongArch64 Zero, both release and fastdebug.
> 
> If this patch conflicts with #14471, I will rebase after #14471 is integrated.

This pull request has now been integrated.

Changeset: 137a5f7c
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/137a5f7c2ce35258702b28565f6feb7cb7f1d68e
Stats:     13 lines in 3 files changed: 13 ins; 0 del; 0 mod

8310105: LoongArch64 builds are broken after JDK-8304913

Reviewed-by: shade, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14482

From dholmes at openjdk.org  Mon Jun 19 22:32:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:32:05 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 [v2]
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <NuoEwbq5aPlw8_pQqyR8pHnCRBJJ9SxulvKOGyd9YJI=.a10acc7c-38dc-49d4-8e93-a46ff2cbcb0b@github.com>

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Pick up javac and jshell changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14462/files
  - new: https://git.openjdk.org/jdk/pull/14462/files/3efc518f..e8ff96d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00-01

  Stats: 74 lines in 2 files changed: 71 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462

PR: https://git.openjdk.org/jdk/pull/14462

From dholmes at openjdk.org  Mon Jun 19 22:32:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:32:07 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <bunHkJGm3C7xSU0JqdU8O-z3rPLQw3xFScOef_2KnKo=.123f7217-2057-4ac6-b0fb-fd46c0c4c481@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The javac changes have been restored so I am merging them into this PR - the only difference should be minor formatting changes.

This has also now picked up the jshell changes from JDK-8308988.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597836257

From dholmes at openjdk.org  Mon Jun 19 22:34:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:34:28 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <NBHlggX8F55iGpoySMQ3Ye20dSFyUnav1vexQ5yB8vI=.b5d8058d-4186-4584-877e-ca1b02688e48@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The javac update has also now pulled in JDK-8308456

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597839767

From dholmes at openjdk.org  Mon Jun 19 22:34:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:34:29 GMT
Subject: Integrated: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <ZKcpvmC0cM2_o-sQJXe4-0F5A2z95lDQQ5VX5Qu4-HI=.d6b1c8bc-4110-4d09-ac97-098202d295e7@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

This pull request has now been integrated.

Changeset: b2e86aef
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2e86aef65f4d579896b6db83aaad408b6c580d4
Stats:     129 lines in 28 files changed: 24 ins; 57 del; 48 mod

8304478: Initial nroff manpage generation for JDK 22

Reviewed-by: alanb, sspitsyn, mchung, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/14462

From jwaters at openjdk.org  Tue Jun 20 07:14:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:14:11 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <yl1ID4d9tj697Ub8zJ2V6kp8mRNl0K8H8ui2mGMVffs=.9f975a37-df57-468c-bf7b-0076fe3488a7@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1598234398

From jwaters at openjdk.org  Tue Jun 20 07:20:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:20:12 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v5]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - Whitespace
 - Revert
 - _MSC_VER

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13258/files
  - new: https://git.openjdk.org/jdk/pull/13258/files/e63d5938..2fed50f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=03-04

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

PR: https://git.openjdk.org/jdk/pull/13258

From jwaters at openjdk.org  Tue Jun 20 07:20:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:20:13 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <r3nzdMOZ2jyvmb8397B91p7Df8rcFsUeCRsZrun17Yc=.c5d9be48-55bc-4044-8cfe-204591638642@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1598236477

From adinn at openjdk.org  Tue Jun 20 09:10:09 2023
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 20 Jun 2023 09:10:09 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <CcV5_XJBBxakoSI_clUKbeNs-skJ6bKtSpmLEKjJCB4=.817ccef1-4811-4990-b0ee-998d386f3311@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <G9u89zgphCQ0I7pyWMV3kZACY-JzxBYmMecseqK8hFg=.7c4f8604-005c-43c0-a1fb-3d4888645e1d@github.com>
 <Hf_sb5okDsMhTxBWMGG3rCGm6d4IZQI_s7ZhvepeslY=.9b184308-6e86-4cd3-bb38-f22e0f044623@github.com>
 <CcV5_XJBBxakoSI_clUKbeNs-skJ6bKtSpmLEKjJCB4=.817ccef1-4811-4990-b0ee-998d386f3311@github.com>
Message-ID: <JqxrnTaKLLDJVTdYD3EsuQS_nQfUQs2zjp2NUC-Z-I0=.986490cc-58b3-42a5-8619-7531b52f6ca6@github.com>

On Tue, 13 Jun 2023 15:48:31 GMT, Christian Wimmer <cwimmer at openjdk.org> wrote:

> We (as the Native Image team) are OK with this. Our testing will detect that pretty quickly, and then the new code can be fixed.

That may well be the case. However, until all the concerns raised by OpenJDK reviewers who have looked at this PR are addressed to their satisfaction it would not be appropriate to merge this patch.

n.b. That does not automatically mean the course of action the reviewers have recommended has to be followed. A resolution needs to be negotiated according to the merits and risks of the change. However, regarding that negotiation, I'll observe that the (repeated) request to break this change down in several steps appears to me to be motivated by the desire to ensure that the merits of the change are maximized (no unnecessary loss of important functionality) and the risks minimized (no unnecessary perturbation of the current implementation) -- which is not an unusual way for OpenJDK reviewers to proceed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1598400830

From duke at openjdk.org  Tue Jun 20 10:05:08 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Tue, 20 Jun 2023 10:05:08 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <zqkT-bX79jlAsnCzhYTl2HqY-uFMwXqEyihxSv1VQro=.3ed11ca4-5d64-4d94-bd6d-d48d5014f6e5@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
 <zqkT-bX79jlAsnCzhYTl2HqY-uFMwXqEyihxSv1VQro=.3ed11ca4-5d64-4d94-bd6d-d48d5014f6e5@github.com>
Message-ID: <NPKA4B7VzvKgJu_7wKC-6go46CUTErYSYznBI7N4a8o=.48fae0bb-df57-493a-980e-b9df4a883b3d@github.com>

On Tue, 9 May 2023 00:12:19 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This isn't correct. When length() returns Integer.MIN_VALUE, this doesn't _necessarily_ cause get(from, to) to always return an empty BitSet. Well, it does in the current implementation, but that's simply a bug that can be fixed. The implementation of the get() method can access the internal data of the object and do the right thing, regardless of what the length() method does. That change should probably be made, regardless of other spec changes we've been discussing.

Noted, the opening paragraph of Problem should be corrected to the following:
"BitSet.length() returns a negative value when Integer.MAX_VALUE is set, such as by using the set(int) method or by passing large arrays to a BitSet constructor. This unexpected behaviour can cause issues where the user relies on length() returning a positive value or 0, such as the bug that occurs in the current implementation of get(int,int)."
This corrects the original paragraph, while still demonstrating why issues it can cause.

> Re disallowing bit Integer.MAX_VALUE: I have a feeling we can do better than this.

That is fair enough. I will fill in the specification for the suggested CSR, so that the CSR can at least be properly discussed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1598483666

From aboldtch at openjdk.org  Tue Jun 20 10:11:15 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:15 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
 <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>
Message-ID: <VDW3BGJ096WIM-W4o8iASPVBxgFZUODEGU7-jMzvcxk=.e6ab6339-bf00-487c-afdd-2ef09b9d5b08@github.com>

On Mon, 19 Jun 2023 09:04:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> How much time do we spend now in GHAs on the additional Zgenerational tests? In any case, this makes sense.

This adds around 40 more tests per platform. The runtime of GHA seems to have a lot of run to run variance. Most new tests are in the `hs/tier1 gc` which has a lower runtime than a few other jobs. So until the heavies jobs gets split into multiple jobs,   this should have a negligible affect the overall GHA runtime

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598488556

From aboldtch at openjdk.org  Tue Jun 20 10:11:18 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:18 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <_wzHFl48ZJqPvYFTwOtY4ughHH3EvHSH9-JtsJiAiXg=.c0e787e7-7797-4a50-a6d3-1b4ef9dfd39e@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

Thanks for all the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598489642

From aboldtch at openjdk.org  Tue Jun 20 10:11:19 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:19 GMT
Subject: Integrated: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <XBb9N9mM3eUuzE3Hn7dEBfENSBizoTw539Co_-H_ngs=.898b8ddf-b6dd-42e0-9e6c-986800b61005@github.com>

On Fri, 16 Jun 2023 09:14:10 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

This pull request has now been integrated.

Changeset: a0595761
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba
Stats:     619 lines in 70 files changed: 447 ins; 5 del; 167 mod

8310187: Improve Generational ZGC jtreg testing

Reviewed-by: stefank, eosterlund, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/14509

From alanb at openjdk.org  Tue Jun 20 10:52:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Jun 2023 10:52:18 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <G_fUJXUoUswNvdyVIhoNP3UlgmyTLlDat4E8fBlnqA4=.6981f172-1cfd-419b-a709-df710c1afbca@github.com>

On Tue, 13 Jun 2023 20:36:28 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

> Hi,
> 
> I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.
> 
> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.
> 
> Thanks
> 
> Tony

test/jdk/sun/security/ec/ecModuleCheck.java line 43:

> 41:             throw new AssertionError("jdk.crypto.ec module does not exist");
> 42:         }
> 43:         System.out.println("jdk.crypto.ec module exists");

`@modules jdk.crypto.ec` in the test description means this test will not be selected/executed if the jdk.crypto.ec is not the run-time image. It also means the test with run with `--add-modules jdk.crypto.ec` which is not what you want. I think this is closer to what you want in this test:


    assertTrue(ModuleFinder.ofSystem().find("jdk.crypto.ec").isPresent());
    assertFalse(ModuleLayer.boot().findModule("jdk.crypto.ec").isPresent());    


This tests that the jdk.crypto.ec is observable but is not resolved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1235086798

From alanb at openjdk.org  Tue Jun 20 10:58:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Jun 2023 10:58:04 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com>
Message-ID: <ub22dvhRh40sJ3UWGNYX2Ay1rrtaRXV0O1MYcquRfBM=.eb7e5dbc-b000-486d-8788-8fa561972771@github.com>

On Tue, 20 Jun 2023 00:57:46 GMT, Sean Mullan <sean.mullan at oracle.com> wrote:

> > Maybe you are thinking about the size of libsunec or non-technical issues that meant it wasn't included by some distributions? There weren't an issue with deciding which providers to include to java.base. I think the motivation for having the SunEC provider in java.base now is probably TLS so there are more secure cipher suites available for those that create a small run-image with jlink and don't include all security providers.
> 
> Yes, I think the motivation is more that Elliptic Curve Cryptography is a widely used form of crypto and should be in java.base. I haven't tried this, but I think TLS 1.3 would simply not work if you just had java.base in your runtime.

I think we've converged on the right motivation. If would be good to check if there are TLS tests that could run with --limit-modules java.base, that would give confidence that the API/implementation will work when the run-time image only contains java.base.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1598552414

From aboldtch at openjdk.org  Tue Jun 20 11:24:22 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 11:24:22 GMT
Subject: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
Message-ID: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>

Hi all,

This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.

Thanks!

-------------

Commit messages:
 - Backport a0595761ef35c4eec8cb84326a869b9473cd5bba

Changes: https://git.openjdk.org/jdk21/pull/37/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=37&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310187
  Stats: 619 lines in 70 files changed: 447 ins; 5 del; 167 mod
  Patch: https://git.openjdk.org/jdk21/pull/37.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/37/head:pull/37

PR: https://git.openjdk.org/jdk21/pull/37

From eosterlund at openjdk.org  Tue Jun 20 11:28:10 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Jun 2023 11:28:10 GMT
Subject: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
References: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
Message-ID: <4_7pKKc53x4JitLz3mqqGPROusebWNzImc2QiYeNOLw=.bfba6681-1a22-4e5b-8669-d6261cc129e3@github.com>

On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.
> 
> Thanks!

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/37#pullrequestreview-1487924209

From kcr at openjdk.org  Tue Jun 20 12:13:04 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jun 2023 12:13:04 GMT
Subject: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
Message-ID: <SnItHEv7bEjxYZlhKVjWRLKuDmiLQIt-w3PG4sA1xYM=.a0cc0a04-64fc-4561-9731-e58bb6530fc0@github.com>

On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Since this is a P4 Enhancement, you will need approval to backport this to JDK 21 during RDP1. See the "Late-Enhancement Request Process" section of [JEP 3](https://openjdk.org/jeps/3).

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1598654781

From mbaesken at openjdk.org  Tue Jun 20 13:30:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Jun 2023 13:30:59 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS when
 codesign tool does not work
Message-ID: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>

Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
But without the entitlement, a core is not generated.

-------------

Commit messages:
 - JDK-8310380

Changes: https://git.openjdk.org/jdk/pull/14562/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310380
  Stats: 36 lines in 3 files changed: 35 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mcimadamore at openjdk.org  Tue Jun 20 13:54:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Jun 2023 13:54:03 GMT
Subject: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <SnItHEv7bEjxYZlhKVjWRLKuDmiLQIt-w3PG4sA1xYM=.a0cc0a04-64fc-4561-9731-e58bb6530fc0@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
 <SnItHEv7bEjxYZlhKVjWRLKuDmiLQIt-w3PG4sA1xYM=.a0cc0a04-64fc-4561-9731-e58bb6530fc0@github.com>
Message-ID: <uaKl8dQExeZSHxixmu7ViEExviASICmcSC_fPVrlnMw=.53455609-6ba9-488a-a1c7-ee0d45f4dcf5@github.com>

On Tue, 20 Jun 2023 12:10:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Since this is a P4 Enhancement, you will need approval to backport this to JDK 21 during RDP1. See the "Late-Enhancement Request Process" section of [JEP 3](https://openjdk.org/jeps/3).


Test and documentation bugs and enhancements

Bugs and enhancements of any priority that only affect tests, or test-problem lists, or documentation may be addressed in RDP 1 and RDP 2. You don?t need to request approval for such a change in order to integrate it, but please do make sure that the issue has a [noreg-self or noreg-doc label](https://openjdk.org/guide/#noreg), as appropriate.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1598832498

From cstein at openjdk.org  Tue Jun 20 14:01:08 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 20 Jun 2023 14:01:08 GMT
Subject: RFR: 8309670: java -help output for --module-path / -p is incomplete
Message-ID: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>

Please review this update to `java`'s help output for `--module-path`/`-p`.

This PR also updates the output for the closely related `--upgrade-module-path` option.

Thanks in advance!

-------------

Commit messages:
 - Update `--upgrade-module-path` description
 - 8309670: java -help output for --module-path / -p is incomplete

Changes: https://git.openjdk.org/jdk/pull/14564/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14564&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309670
  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14564/head:pull/14564

PR: https://git.openjdk.org/jdk/pull/14564

From pminborg at openjdk.org  Tue Jun 20 14:08:03 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 20 Jun 2023 14:08:03 GMT
Subject: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
Message-ID: <Jxj6nBzQ3XVEsDsIBXnA_-vFbJ6Zvc3CODjE31-74v4=.a5960422-6dd0-49ff-a419-d980a20ba676@github.com>

On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

The issue has a label `noreg-doc` so we should be able to integrate this PR.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1598863298

From alanb at openjdk.org  Tue Jun 20 14:55:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Jun 2023 14:55:13 GMT
Subject: RFR: 8309670: java -help output for --module-path / -p is
 incomplete
In-Reply-To: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
References: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
Message-ID: <kOLcLcvPK-7BQ-n4r9JaEZauvKRGPqfteagjiQdwu0k=.95089745-2e69-44a3-8e27-7b3ca08909e1@github.com>

On Tue, 20 Jun 2023 13:54:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to `java`'s help output for `--module-path`/`-p`.
> 
> This PR also updates the output for the closely related `--upgrade-module-path` option.
> 
> Thanks in advance!

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 55:

> 53: \                  A {0} separated list of elements, each element is a file path\n\
> 54: \                  to a module or a directory containing modules. Each module is either\n\
> 55: \                  a modular JAR or an exploded-module directory.\n\

JEP 261 uses "module definition" but that would be too hard to explain in the help output, so I think what you have is okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14564#discussion_r1235391988

From rriggs at openjdk.org  Tue Jun 20 15:03:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 15:03:18 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
Message-ID: <1D5LsOe2qB-UQ-NH3tjX6y1NgiMLlEWHj9KwHhnOI_8=.342da45f-0237-4af8-84e1-f4fe65dc208d@github.com>

On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct comment

src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 139:

> 137:     ChildStuff c;
> 138:     struct stat buf;
> 139:     /* argv[1] contains the fd number to read all the child info */

I would prefer to also fix the use of `argc-1` below to match.  Its a pretty odd form and might trip someone later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14531#discussion_r1235403720

From stuefe at openjdk.org  Tue Jun 20 15:11:05 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Jun 2023 15:11:05 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <1D5LsOe2qB-UQ-NH3tjX6y1NgiMLlEWHj9KwHhnOI_8=.342da45f-0237-4af8-84e1-f4fe65dc208d@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
 <1D5LsOe2qB-UQ-NH3tjX6y1NgiMLlEWHj9KwHhnOI_8=.342da45f-0237-4af8-84e1-f4fe65dc208d@github.com>
Message-ID: <zmAAqodm-Kf5w90_IwRA6_zWh4kYA9hDaot3htWvo4M=.013f129f-973f-494c-acff-c750230bb610@github.com>

On Tue, 20 Jun 2023 15:00:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correct comment
>
> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 139:
> 
>> 137:     ChildStuff c;
>> 138:     struct stat buf;
>> 139:     /* argv[1] contains the fd number to read all the child info */
> 
> I would prefer to also fix the use of `argc-1` below to match.  Its a pretty odd form and might trip someone later.

I wondered about this, it looked so deliberate. So I wondered whether jspawnhelper is used outside of the posix_spawn context, but cannot find anything. Maybe historic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14531#discussion_r1235414109

From kcr at openjdk.org  Tue Jun 20 15:20:08 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jun 2023 15:20:08 GMT
Subject: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
Message-ID: <Q8FZ0H9_yzbbCi8eTAgeCPtEKt-1XiGoGEcAHYA0Xl8=.81653351-e02e-4106-9328-43cfd8eba7ee@github.com>

On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Now that it has a `noreg-doc` label it is fine.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1598996676

From jvernee at openjdk.org  Tue Jun 20 15:39:20 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 20 Jun 2023 15:39:20 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
Message-ID: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>

Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.

-------------

Commit messages:
 - improve firstVariadicArg doc

Changes: https://git.openjdk.org/jdk/pull/14565/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310405
  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14565/head:pull/14565

PR: https://git.openjdk.org/jdk/pull/14565

From duke at openjdk.org  Tue Jun 20 15:57:29 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 20 Jun 2023 15:57:29 GMT
Subject: [jdk21] RFR: 8310105: LoongArch64 builds are broken after JDK-8304913
Message-ID: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>

8310105: LoongArch64 builds are broken after JDK-8304913

-------------

Commit messages:
 - Backport 137a5f7c2ce35258702b28565f6feb7cb7f1d68e

Changes: https://git.openjdk.org/jdk21/pull/39/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=39&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310105
  Stats: 13 lines in 3 files changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/39.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/39/head:pull/39

PR: https://git.openjdk.org/jdk21/pull/39

From kcr at openjdk.org  Tue Jun 20 15:58:53 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Jun 2023 15:58:53 GMT
Subject: [jdk21] RFR: 8310105: LoongArch64 builds are broken after
 JDK-8304913
In-Reply-To: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
References: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
Message-ID: <4OV19ivGZ6q4gY1fv2H40dP9OgSdhc1pYC_rHsnoUpc=.aa9fcb93-2efa-4ecb-8817-1f670109fdbe@github.com>

On Tue, 20 Jun 2023 15:49:42 GMT, Glavo <duke at openjdk.org> wrote:

> 8310105: LoongArch64 builds are broken after JDK-8304913

@Glavo If the priority of the bug, which is listed as P4, is correct (which I suspect it is not), this would not meet the criteria for integrating into JDK 21 during RDP1. If this is objectively a P2 or P3 bug, then please adjust the priority of the bug in JBS accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/39#issuecomment-1599074073

From duke at openjdk.org  Tue Jun 20 16:15:34 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 20 Jun 2023 16:15:34 GMT
Subject: [jdk21] RFR: 8310105: LoongArch64 builds are broken after
 JDK-8304913
In-Reply-To: <4OV19ivGZ6q4gY1fv2H40dP9OgSdhc1pYC_rHsnoUpc=.aa9fcb93-2efa-4ecb-8817-1f670109fdbe@github.com>
References: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
 <4OV19ivGZ6q4gY1fv2H40dP9OgSdhc1pYC_rHsnoUpc=.aa9fcb93-2efa-4ecb-8817-1f670109fdbe@github.com>
Message-ID: <v4hA_tmCFpoe7hdoKUUYKB5IFN32qhyLNYL3xBrH5WU=.a70bb7fe-8951-49d0-9d41-b2046a3922d9@github.com>

On Tue, 20 Jun 2023 15:56:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> 8310105: LoongArch64 builds are broken after JDK-8304913
>
> @Glavo If the priority of the bug, which is listed as P4, is correct (which I suspect it is not), this would not meet the criteria for integrating into JDK 21 during RDP1. If this is objectively a P2 or P3 bug, then please adjust the priority of the bug in JBS accordingly.

@kevinrushforth This bug prevents building JDK on an architecture, and I believe it should have a higher priority.

However, I am not a member of OpenJDK, so what can I do?

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/39#issuecomment-1599101901

From shade at openjdk.org  Tue Jun 20 16:22:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Jun 2023 16:22:25 GMT
Subject: [jdk21] RFR: 8310105: LoongArch64 builds are broken after
 JDK-8304913
In-Reply-To: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
References: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
Message-ID: <P-BaT3Pr88u1Qt9kXqZeYx-Z3cVQDlgBZByApPB_ji8=.62c4b92d-cfad-428c-b91f-0c121b3e7fa6@github.com>

On Tue, 20 Jun 2023 15:49:42 GMT, Glavo <duke at openjdk.org> wrote:

> 8310105: LoongArch64 builds are broken after JDK-8304913

The change looks fine.

This is a build breakage. I adjusted the priority to P2.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/39#pullrequestreview-1488533001
PR Comment: https://git.openjdk.org/jdk21/pull/39#issuecomment-1599111231

From shade at openjdk.org  Tue Jun 20 16:29:46 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Jun 2023 16:29:46 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]
In-Reply-To: <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
Message-ID: <xnc2T5Cv5St7lORScWbMpoqjFkpGk4N3HYtuT86B2bo=.51f4b068-fbf9-4d06-bfd4-d8da084c81ef@github.com>

On Thu, 15 Jun 2023 17:44:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add mipsel and mips64el to the Architecture enum.
>> (Later to be backported to JDK 21)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct mps64el test case

Hey @RogerRiggs, could you ask bots to backport to JDK 21? I'll then review that one as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14471#issuecomment-1599121687

From rriggs at openjdk.org  Tue Jun 20 16:30:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 16:30:23 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <zmAAqodm-Kf5w90_IwRA6_zWh4kYA9hDaot3htWvo4M=.013f129f-973f-494c-acff-c750230bb610@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
 <1D5LsOe2qB-UQ-NH3tjX6y1NgiMLlEWHj9KwHhnOI_8=.342da45f-0237-4af8-84e1-f4fe65dc208d@github.com>
 <zmAAqodm-Kf5w90_IwRA6_zWh4kYA9hDaot3htWvo4M=.013f129f-973f-494c-acff-c750230bb610@github.com>
Message-ID: <_eBMP61aNZ7vhnYC0AhINpG7Qwxm4Zj_-pVn5OsQPQ4=.1b0887cc-9c2c-40a6-a92b-381c8502b6a3@github.com>

On Tue, 20 Jun 2023 15:08:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 139:
>> 
>>> 137:     ChildStuff c;
>>> 138:     struct stat buf;
>>> 139:     /* argv[1] contains the fd number to read all the child info */
>> 
>> I would prefer to also fix the use of `argc-1` below to match.  Its a pretty odd form and might trip someone later.
>
> I wondered about this, it looked so deliberate. So I wondered whether jspawnhelper is used outside of the posix_spawn context, but cannot find anything. Maybe historic?

I'm not aware of any other uses either; its not intended to be used outside of ProcessImpl especially since the addition of the new protocol to communicate parameters and confirm launching of the child.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14531#discussion_r1235515103

From duke at openjdk.org  Tue Jun 20 16:31:09 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 20 Jun 2023 16:31:09 GMT
Subject: [jdk21] Integrated: 8310105: LoongArch64 builds are broken after
 JDK-8304913
In-Reply-To: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
References: <5RzNtA_03WzNJlW6q5mZ3zc1aF-lDY6vGNUjQRw71us=.bbd0c098-183d-475c-8dce-474553df13e0@github.com>
Message-ID: <02r-sxHOwoFIXBzhfxiDzwm88SBRkrErpG2kYbSfzvU=.ec281555-48f7-4cf8-adc7-0d8235c116c8@github.com>

On Tue, 20 Jun 2023 15:49:42 GMT, Glavo <duke at openjdk.org> wrote:

> 8310105: LoongArch64 builds are broken after JDK-8304913

This pull request has now been integrated.

Changeset: 7e788939
Author:    Glavo <zjx001202 at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/7e788939d3d7de433d6aa3c7da396d32cae1233a
Stats:     13 lines in 3 files changed: 13 ins; 0 del; 0 mod

8310105: LoongArch64 builds are broken after JDK-8304913

Reviewed-by: shade
Backport-of: 137a5f7c2ce35258702b28565f6feb7cb7f1d68e

-------------

PR: https://git.openjdk.org/jdk21/pull/39

From stuefe at openjdk.org  Tue Jun 20 16:48:42 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 20 Jun 2023 16:48:42 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v3]
In-Reply-To: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
Message-ID: <JtT8c086L_oseaMtI4DjHYuRxzBAAvMh3EW6XmX4dGw=.653d66a1-b710-4724-bf39-913dbab2b246@github.com>

> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
> 
> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
> 
> For details, see linked ML discussion. 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  feedback Volker and Roger

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14531/files
  - new: https://git.openjdk.org/jdk/pull/14531/files/1ee05c05..8f83fa27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14531&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14531&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14531.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14531/head:pull/14531

PR: https://git.openjdk.org/jdk/pull/14531

From rriggs at openjdk.org  Tue Jun 20 16:56:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 16:56:06 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v3]
In-Reply-To: <JtT8c086L_oseaMtI4DjHYuRxzBAAvMh3EW6XmX4dGw=.653d66a1-b710-4724-bf39-913dbab2b246@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <JtT8c086L_oseaMtI4DjHYuRxzBAAvMh3EW6XmX4dGw=.653d66a1-b710-4724-bf39-913dbab2b246@github.com>
Message-ID: <oc2IAMGEVAFTP-HlQCu6WjwMlVfDCtJcbJ1ilJrjYdU=.12c31085-ec5b-4b47-a493-168ca59cbe85@github.com>

On Tue, 20 Jun 2023 16:48:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback Volker and Roger

looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14531#pullrequestreview-1488593752

From rriggs at openjdk.org  Tue Jun 20 17:08:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 17:08:23 GMT
Subject: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]
In-Reply-To: <xnc2T5Cv5St7lORScWbMpoqjFkpGk4N3HYtuT86B2bo=.51f4b068-fbf9-4d06-bfd4-d8da084c81ef@github.com>
References: <vZbYKuWZAqGk6Kxec3At-TWiaQk2kcUwDL8VRkJI5mY=.9232d049-bc16-408c-bfad-cb6c7648d0a2@github.com>
 <zVMaXY95xg0wbSf_e9aavyy9XbRp3y_WnvwNC-8X4P0=.b28ea411-49e5-4238-babe-82d6a834d2f9@github.com>
 <xnc2T5Cv5St7lORScWbMpoqjFkpGk4N3HYtuT86B2bo=.51f4b068-fbf9-4d06-bfd4-d8da084c81ef@github.com>
Message-ID: <rxfCi-MlIsg2iOX3Czah99wbuE7skdyJPEFPoMU7c6Y=.368e8e8e-2e33-42a5-93b1-e0ce02cc06d4@github.com>

On Tue, 20 Jun 2023 16:26:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct mps64el test case
>
> Hey @RogerRiggs, could you ask bots to backport to JDK 21? I'll then review that one as well.

@shipilev Thanks for the reminder; 
Backport PR https://github.com/openjdk/jdk21/pull/40

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14471#issuecomment-1599183993

From rriggs at openjdk.org  Tue Jun 20 17:12:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 17:12:12 GMT
Subject: [jdk21] RFR: 8310019: MIPS builds are broken after JDK-8304913
Message-ID: <ttPBQ8qWk8v825HvSkAZshBzB45YfbFJic0jVX5VI9o=.c9c67643-1350-4a48-8125-9ae4268b3b79@github.com>

Hi all,

    This pull request contains a backport of commit [33c6ec9d] from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

    The commit being backported was authored by Roger Riggs on 19 Jun 2023 and was reviewed by Paul Hohensee, Aleksey Shipilev and Ao Qi.

    Thanks!

-------------

Commit messages:
 - Backport 33c6ec9d4eb36649a94125aa005dc6b961dcd2c1

Changes: https://git.openjdk.org/jdk21/pull/40/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=40&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310019
  Stats: 26 lines in 3 files changed: 26 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/40.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/40/head:pull/40

PR: https://git.openjdk.org/jdk21/pull/40

From shade at openjdk.org  Tue Jun 20 17:12:13 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Jun 2023 17:12:13 GMT
Subject: [jdk21] RFR: 8310019: MIPS builds are broken after JDK-8304913
In-Reply-To: <ttPBQ8qWk8v825HvSkAZshBzB45YfbFJic0jVX5VI9o=.c9c67643-1350-4a48-8125-9ae4268b3b79@github.com>
References: <ttPBQ8qWk8v825HvSkAZshBzB45YfbFJic0jVX5VI9o=.c9c67643-1350-4a48-8125-9ae4268b3b79@github.com>
Message-ID: <M5F-FQwmcs4K-XppcCWYmbE660EIf1jrkaV7htU0oGs=.2c54d266-1517-45bd-8359-47fdba9a6df2@github.com>

On Tue, 20 Jun 2023 17:02:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [33c6ec9d] from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Roger Riggs on 19 Jun 2023 and was reviewed by Paul Hohensee, Aleksey Shipilev and Ao Qi.
> 
>     Thanks!

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/40#pullrequestreview-1488618518

From darcy at openjdk.org  Tue Jun 20 17:19:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 20 Jun 2023 17:19:20 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
Message-ID: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>

I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.

There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.

Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

-------------

Commit messages:
 - JDK-8310453: Update javadoc of java.lang.Object

Changes: https://git.openjdk.org/jdk/pull/14567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310453
  Stats: 25 lines in 1 file changed: 11 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14567/head:pull/14567

PR: https://git.openjdk.org/jdk/pull/14567

From erikj at openjdk.org  Tue Jun 20 17:28:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jun 2023 17:28:09 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <P5Xe4ZPVI6KoQg381kffgjBQyZne52hbQr06DAMVOzA=.7569800b-1215-4374-98b2-a8a14c44c07a@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

The changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/26#pullrequestreview-1488653545

From erikj at openjdk.org  Tue Jun 20 17:28:10 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 20 Jun 2023 17:28:10 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
Message-ID: <GsNmOCTyHN6YGg8VD_ec2w07wBuLqVHcsEANb0iL_ZI=.a593f001-3eb9-4f84-8c3f-2755abc3be62@github.com>

On Fri, 16 Jun 2023 22:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> @erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you have plans to redo that testing for the JDK21 backport?

I have done testing of the JDK 21 version of the patch and it's running cleanly.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599212967

From rriggs at openjdk.org  Tue Jun 20 17:43:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 17:43:04 GMT
Subject: [jdk21] Integrated: 8310019: MIPS builds are broken after JDK-8304913
In-Reply-To: <ttPBQ8qWk8v825HvSkAZshBzB45YfbFJic0jVX5VI9o=.c9c67643-1350-4a48-8125-9ae4268b3b79@github.com>
References: <ttPBQ8qWk8v825HvSkAZshBzB45YfbFJic0jVX5VI9o=.c9c67643-1350-4a48-8125-9ae4268b3b79@github.com>
Message-ID: <niVkqNs8RAI7JWr5fKw3VHbm5Q1HSNLXQSW9Tg3qt8w=.7d9f9d33-bf6b-45e6-ac04-f9030f1986e3@github.com>

On Tue, 20 Jun 2023 17:02:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Hi all,
> 
>     This pull request contains a backport of commit [33c6ec9d] from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>     The commit being backported was authored by Roger Riggs on 19 Jun 2023 and was reviewed by Paul Hohensee, Aleksey Shipilev and Ao Qi.
> 
>     Thanks!

This pull request has now been integrated.

Changeset: e0cc4010
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/e0cc40108afc9dd30639d949a88fe6f2a05d45bf
Stats:     26 lines in 3 files changed: 26 ins; 0 del; 0 mod

8310019: MIPS builds are broken after JDK-8304913

Reviewed-by: shade
Backport-of: 33c6ec9d4eb36649a94125aa005dc6b961dcd2c1

-------------

PR: https://git.openjdk.org/jdk21/pull/40

From rriggs at openjdk.org  Tue Jun 20 17:46:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 17:46:04 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <uTtTOKaOi9Ytk4Lb55GDht1W7nojjhLU51DbHV05AEE=.a7bab839-1e65-4ea9-8600-a8c616445e09@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14567#pullrequestreview-1488684336

From mchung at openjdk.org  Tue Jun 20 17:53:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 17:53:27 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v5]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <ul2Wat5ucV2seIBvsuzWON1Rw4CC_qkv9zsyXfAgQ50=.cc4b5cad-7b04-42e7-865d-b94299b78ad6@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Review comment.  Add a test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/b631c2be..a75542ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=03-04

  Stats: 92 lines in 2 files changed: 86 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Tue Jun 20 17:53:29 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 17:53:29 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
Message-ID: <7i5mZTf1vya-MJXMlbW_tcPNCrGWhtjs18X8UZXzqPM=.e4c77c78-ab7f-4911-9e19-a0e57b48b3a6@github.com>

On Sat, 17 Jun 2023 00:35:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing 'L' for the array class name

I added an API note in the 2-arg forName that it does not support loading of array types.  Also fixed the links.   A new test is added to show the valid and invalid names.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14528#issuecomment-1599246337

From mchung at openjdk.org  Tue Jun 20 17:53:30 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 17:53:30 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <TeHXYnEHfkamyj7HVyXRxDZtRQ40rriaWSxGOZbo4QA=.9719c25a-cf82-4b5d-9083-afac801269a6@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
 <TeHXYnEHfkamyj7HVyXRxDZtRQ40rriaWSxGOZbo4QA=.9719c25a-cf82-4b5d-9083-afac801269a6@github.com>
Message-ID: <gL59tX6QJ53qJldSg6MT4TM-KmtJpRgnegAkwvMJCCg=.f99c53dd-a144-4d54-a1ff-895729513638@github.com>

On Mon, 19 Jun 2023 01:34:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 395:
>> 
>>> 393:      * attached thread), the system class loader is used.
>>> 394:      *
>>> 395:      * @param     className the <a href="#binary-name">binary name</a> of the class
>> 
>> Where do these links lead? I don't find any section with this ID in the `Class` Javadoc. Should they lead to `ClassLoader`? That Javadoc has such a section.
>
> This seems a specification change as the binary-name and FQN are not always the same. In particular for a member class `M` in class `C` the binary name is `C$M`, whereas the FQN is `C.M`.

Binary name is a long-standing behavior.  It's a spec bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1235609362

From jiangli at openjdk.org  Tue Jun 20 17:57:04 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 Jun 2023 17:57:04 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <GsNmOCTyHN6YGg8VD_ec2w07wBuLqVHcsEANb0iL_ZI=.a593f001-3eb9-4f84-8c3f-2755abc3be62@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <Ra9TLZFRnnonzNUawdd9vct-TD9rBZOD2G3GxW_d2Nk=.f2718f84-c679-4faf-9482-5cd0e80ec9ca@github.com>
 <GsNmOCTyHN6YGg8VD_ec2w07wBuLqVHcsEANb0iL_ZI=.a593f001-3eb9-4f84-8c3f-2755abc3be62@github.com>
Message-ID: <lYF3jKOwLHcmw5IC91M5v7mt9wAgBMhjlvGqAtq43x4=.78cab790-3f86-4f90-ad2e-a6219be671b0@github.com>

On Tue, 20 Jun 2023 17:24:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > @erikj - You did a round of Mach5 testing on the JDK22 version of this fix. Do you have plans to redo that testing for the JDK21 backport?
> 
> I have done testing of the JDK 21 version of the patch and it's running cleanly.

Thanks for testing, @erikj79!

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599255419

From jiangli at openjdk.org  Tue Jun 20 17:57:04 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 Jun 2023 17:57:04 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <P5Xe4ZPVI6KoQg381kffgjBQyZne52hbQr06DAMVOzA=.7569800b-1215-4374-98b2-a8a14c44c07a@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <P5Xe4ZPVI6KoQg381kffgjBQyZne52hbQr06DAMVOzA=.7569800b-1215-4374-98b2-a8a14c44c07a@github.com>
Message-ID: <MQkHYsLqOQ0Cyt-y0G9qx-ymh85g6bazFCTi11y_rfs=.5e0e07f9-a781-4976-8957-aac265c83dc4@github.com>

On Tue, 20 Jun 2023 17:25:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The changes look ok.

Thanks. I'll wait for approval on https://bugs.openjdk.org/browse/JDK-8307858 as well.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1599256118

From mchung at openjdk.org  Tue Jun 20 18:11:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 18:11:04 GMT
Subject: RFR: 8309670: java -help output for --module-path / -p is
 incomplete
In-Reply-To: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
References: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
Message-ID: <Gul5tXEonV1LoDCYRZzy4e2hbd7bwQVCJViAtourUoE=.e9ecd29b-6592-4b8c-96c9-4b3f0aabea46@github.com>

On Tue, 20 Jun 2023 13:54:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to `java`'s help output for `--module-path`/`-p`.
> 
> This PR also updates the output for the closely related `--upgrade-module-path` option.
> 
> Thanks in advance!

This looks okay to me.   Please also update the markdown version of the man page.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14564#pullrequestreview-1488726935

From rriggs at openjdk.org  Tue Jun 20 18:26:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 20 Jun 2023 18:26:19 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <-eJOismaPqvwI-Y427qNV0bCmfscDRkUPzrLsPoTUko=.71d3ee26-3a9e-4fe9-a08d-88d5429bb3e4@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
 <-eJOismaPqvwI-Y427qNV0bCmfscDRkUPzrLsPoTUko=.71d3ee26-3a9e-4fe9-a08d-88d5429bb3e4@github.com>
Message-ID: <l5lh3ilK4H-aCE1j8aeQvWkRLiy7EpeAWYhoPbO64-k=.eacbe3a6-468f-428f-b77b-ab455ae9ed85@github.com>

On Sun, 18 Jun 2023 19:33:07 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> Where did you get this idea? A "positive" means a number that is _greater_ than zero.

One of my colleagues with a strong math background has corrected many of my API javadoc comments seeking to avoid any ambiguity.  See reference below about positive integers.

[home](https://www.math.net/) / [primary math](https://www.math.net/primary-math) / [number](https://www.math.net/number) / positive numbers
Positive numbers

A positive number is any number that is greater than 0. **Unlike positive integers**, which include 0 and the [natural numbers](https://www.math.net/natural-numbers), positive numbers include [fractions](https://www.math.net/fraction), [decimals](https://www.math.net/decimal), and other types of [numerals](https://www.math.net/numerals).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1599291030

From simonis at openjdk.org  Tue Jun 20 18:39:03 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 20 Jun 2023 18:39:03 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v3]
In-Reply-To: <JtT8c086L_oseaMtI4DjHYuRxzBAAvMh3EW6XmX4dGw=.653d66a1-b710-4724-bf39-913dbab2b246@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <JtT8c086L_oseaMtI4DjHYuRxzBAAvMh3EW6XmX4dGw=.653d66a1-b710-4724-bf39-913dbab2b246@github.com>
Message-ID: <Megdjl_ewrv7-1C1sqswpgG8LhQAVJJg1SQzQRp5IyE=.3e11665f-87a3-4b05-837d-d1e27d46fd19@github.com>

On Tue, 20 Jun 2023 16:48:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
>> 
>> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
>> 
>> For details, see linked ML discussion. 
>> 
>> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback Volker and Roger

Still good :)

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14531#pullrequestreview-1488771409

From mchung at openjdk.org  Tue Jun 20 18:51:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 18:51:07 GMT
Subject: RFR: JDK-8310460: Remove jdeps -profile option
Message-ID: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>

Compact profiles are defined in Java SE 8 and are legacy in Java SE 9. jdeps -profile option was deprecated for removal in JDK 21. This option can be removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.

-------------

Commit messages:
 - JDK-8310460: Remove jdeps -profile option

Changes: https://git.openjdk.org/jdk/pull/14570/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310460
  Stats: 376 lines in 9 files changed: 0 ins; 329 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/14570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14570/head:pull/14570

PR: https://git.openjdk.org/jdk/pull/14570

From ascarpino at openjdk.org  Tue Jun 20 18:52:06 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 20 Jun 2023 18:52:06 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base
In-Reply-To: <ub22dvhRh40sJ3UWGNYX2Ay1rrtaRXV0O1MYcquRfBM=.eb7e5dbc-b000-486d-8788-8fa561972771@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <119efe37-132c-4d9f-5b32-c7f60c302599@oracle.com>
 <ub22dvhRh40sJ3UWGNYX2Ay1rrtaRXV0O1MYcquRfBM=.eb7e5dbc-b000-486d-8788-8fa561972771@github.com>
Message-ID: <hNhAqkwBc5t8apCl-HOy4gSzq0iihVbe0UquwrCJewA=.f6a63a4f-2b7d-4ead-be0f-43ed464aaf2c@github.com>

On Tue, 20 Jun 2023 10:55:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we've converged on the right motivation. If would be good to check if there are TLS tests that could run with --limit-modules java.base, that would give confidence that the API/implementation will work when the run-time image only contains java.base.

I can add a case for one of the TLS tests I changed in this PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14457#issuecomment-1599336912

From mchung at openjdk.org  Tue Jun 20 19:15:35 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 19:15:35 GMT
Subject: RFR: JDK-8310460: Remove jdeps -profile option [v2]
In-Reply-To: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>
References: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>
Message-ID: <tBWnrROqMYNhmRQhb7dAG6z_M577hLKBnfmVaUeEZA0=.58f16be5-a957-480c-8197-58da48637b2b@github.com>

> Compact profiles are defined in Java SE 8 and are legacy in Java SE 9. jdeps -profile option was deprecated for removal in JDK 21. This option can be removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  update copyright end year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14570/files
  - new: https://git.openjdk.org/jdk/pull/14570/files/0c35f03c..cde3296c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14570&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14570&range=00-01

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14570/head:pull/14570

PR: https://git.openjdk.org/jdk/pull/14570

From alanb at openjdk.org  Tue Jun 20 19:23:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 20 Jun 2023 19:23:05 GMT
Subject: RFR: JDK-8310460: Remove jdeps -profile option [v2]
In-Reply-To: <tBWnrROqMYNhmRQhb7dAG6z_M577hLKBnfmVaUeEZA0=.58f16be5-a957-480c-8197-58da48637b2b@github.com>
References: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>
 <tBWnrROqMYNhmRQhb7dAG6z_M577hLKBnfmVaUeEZA0=.58f16be5-a957-480c-8197-58da48637b2b@github.com>
Message-ID: <Uh42jM97D_BzhTreVf2ul58XtLxMI-s7sOfT7gqXPPA=.9ad19b3a-507b-4157-992b-8f6b7aefeb71@github.com>

On Tue, 20 Jun 2023 19:15:35 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Compact profiles are defined in Java SE 8 and are legacy in Java SE 9. jdeps -profile option was deprecated for removal in JDK 21. This option can be removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

Removal looks okay, I didn't spot anything else that needs to be updated.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14570#pullrequestreview-1488867487

From mchung at openjdk.org  Tue Jun 20 19:33:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 20 Jun 2023 19:33:05 GMT
Subject: RFR: JDK-8310460: Remove jdeps -profile option [v2]
In-Reply-To: <tBWnrROqMYNhmRQhb7dAG6z_M577hLKBnfmVaUeEZA0=.58f16be5-a957-480c-8197-58da48637b2b@github.com>
References: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>
 <tBWnrROqMYNhmRQhb7dAG6z_M577hLKBnfmVaUeEZA0=.58f16be5-a957-480c-8197-58da48637b2b@github.com>
Message-ID: <SWLu7FEwDQysewKMFKqM1MgGZDGi2FhOdPnNN3-Tu0Q=.61764c03-6f8e-4ee3-aa25-08da46b97725@github.com>

On Tue, 20 Jun 2023 19:15:35 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Compact profiles are defined in Java SE 8 and are legacy in Java SE 9. jdeps -profile option was deprecated for removal in JDK 21. This option can be removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright end year

Thanks for the quick review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14570#issuecomment-1599385806

From prr at openjdk.org  Tue Jun 20 20:25:15 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jun 2023 20:25:15 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <ELnPTmj_oP5vV_spnx855G7rHvSrglS31H2TwRQ1xwg=.8557871f-3ab2-40ed-bee4-2574c1865be9@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

I have no issues with the enhanced Java 2D tests to cover both generational and original ZGC.
But I'll leave it to hotspot reviews to formally approve the fix since those tests are such a tiny part of this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1599445397

From duke at openjdk.org  Tue Jun 20 20:57:06 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Tue, 20 Jun 2023 20:57:06 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <l5lh3ilK4H-aCE1j8aeQvWkRLiy7EpeAWYhoPbO64-k=.eacbe3a6-468f-428f-b77b-ab455ae9ed85@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
 <-eJOismaPqvwI-Y427qNV0bCmfscDRkUPzrLsPoTUko=.71d3ee26-3a9e-4fe9-a08d-88d5429bb3e4@github.com>
 <l5lh3ilK4H-aCE1j8aeQvWkRLiy7EpeAWYhoPbO64-k=.eacbe3a6-468f-428f-b77b-ab455ae9ed85@github.com>
Message-ID: <lbGiQk65XamUn9n6mahqZjX8xOr9SEYToui614nk9cc=.9a82cc6d-71c2-47f3-b366-cf5cb920eca4@github.com>

On Tue, 20 Jun 2023 18:23:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A positive number is any number that is greater than 0. **Unlike positive integers**, which include 0

math.net seems pretty alone in this. I find the notion bizarre. There seems to be an overwhelming majority of sources that consider 0 to be neither negative nor positive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1599480422

From jiangli at openjdk.org  Tue Jun 20 21:16:18 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 20 Jun 2023 21:16:18 GMT
Subject: Withdrawn: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
Message-ID: <zzEzkcZuHQXoB4FrJrtnm3Cd9zgE4D8a4zYdpggZtjE=.32f8630c-67a9-4eee-8b0d-53ffd3a640f2@github.com>

On Fri, 28 Apr 2023 01:03:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
> 
> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
> 
> To build the statically linked executable:
> 
> 1. Configure the JDK build with --with-static-java=yes
> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
> 
>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
> 
> Following is a summary of the changes in this PR:
> 
> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
> 
> - Changes in make/Main.gmk
> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
> 
> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
> 
> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
> 
> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
> 
> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/Nativ...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13709

From mcimadamore at openjdk.org  Tue Jun 20 23:03:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Jun 2023 23:03:06 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
Message-ID: <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>

On Tue, 20 Jun 2023 14:21:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.

src/java.base/share/classes/java/lang/foreign/Linker.java line 650:

> 648:          *          function descriptor associated with a downcall linkage request}
> 649:          * <p>
> 650:          * The {@code index} value must be greater than zero, and less than or equal to the number of argument layouts

Why > 0 and not >= 0? If the list of argument layout is empty, wouldn't the first vararg be in position 0? E.g. a call to a function `m(...)` with _no_ actual arguments?

src/java.base/share/classes/java/lang/foreign/Linker.java line 652:

> 650:          * The {@code index} value must be greater than zero, and less than or equal to the number of argument layouts
> 651:          * of the function descriptor that is used in the same linkage request as this option. When the {@code index} is
> 652:          * equal to the number of argument layouts in the descriptor, it indicates a variadic function to which zero

This sentence is not clear. If index == num layouts then it means *all* arguments are variadic?

src/java.base/share/classes/java/lang/foreign/Linker.java line 659:

> 657:          * against which the index is validated is available.
> 658:          *
> 659:          * @param index the index of the first variadic argument layout in the function descriptor associated

IMHO this description is still confusing because it speaks about an index into the function descriptor argument layouts - which this thing is not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1235980081
PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1235981064
PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1235981781

From mcimadamore at openjdk.org  Tue Jun 20 23:03:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 20 Jun 2023 23:03:07 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
Message-ID: <8FJI0iyqZ_LKGWZzMEwLgWm1ezLuLEncz_SnLNn461I=.c5ce935d-1ebb-4a6f-af14-2821b58434af@github.com>

On Tue, 20 Jun 2023 22:53:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 650:
> 
>> 648:          *          function descriptor associated with a downcall linkage request}
>> 649:          * <p>
>> 650:          * The {@code index} value must be greater than zero, and less than or equal to the number of argument layouts
> 
> Why > 0 and not >= 0? If the list of argument layout is empty, wouldn't the first vararg be in position 0? E.g. a call to a function `m(...)` with _no_ actual arguments?

E.g. are we making an assumption here that if no arguments are passed, then the calling sequence won't be affected by variadic-ness - is that assumption always true?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1235983407

From jvernee at openjdk.org  Tue Jun 20 23:57:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 20 Jun 2023 23:57:05 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <8FJI0iyqZ_LKGWZzMEwLgWm1ezLuLEncz_SnLNn461I=.c5ce935d-1ebb-4a6f-af14-2821b58434af@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
 <8FJI0iyqZ_LKGWZzMEwLgWm1ezLuLEncz_SnLNn461I=.c5ce935d-1ebb-4a6f-af14-2821b58434af@github.com>
Message-ID: <Xmici98EhW7fcypFf3C13COea8-tH9MYY5s4ShGqr7E=.89878310-ee79-44da-9012-a5316267a2f5@github.com>

On Tue, 20 Jun 2023 22:59:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 650:
>> 
>>> 648:          *          function descriptor associated with a downcall linkage request}
>>> 649:          * <p>
>>> 650:          * The {@code index} value must be greater than zero, and less than or equal to the number of argument layouts
>> 
>> Why > 0 and not >= 0? If the list of argument layout is empty, wouldn't the first vararg be in position 0? E.g. a call to a function `m(...)` with _no_ actual arguments?
>
> E.g. are we making an assumption here that if no arguments are passed, then the calling sequence won't be affected by variadic-ness - is that assumption always true?

Ah, sorry, this is just a  mistake I made. It should be >= 0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1236015716

From jvernee at openjdk.org  Wed Jun 21 00:02:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 Jun 2023 00:02:05 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
Message-ID: <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>

On Tue, 20 Jun 2023 22:54:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 652:
> 
>> 650:          * The {@code index} value must be greater than zero, and less than or equal to the number of argument layouts
>> 651:          * of the function descriptor that is used in the same linkage request as this option. When the {@code index} is
>> 652:          * equal to the number of argument layouts in the descriptor, it indicates a variadic function to which zero
> 
> This sentence is not clear. If index == num layouts then it means *all* arguments are variadic?

index == 0 would mean all arguments are variadic. index == num layouts means none. (just like `"abcd".substring(4)` returns an empty string).

> src/java.base/share/classes/java/lang/foreign/Linker.java line 659:
> 
>> 657:          * against which the index is validated is available.
>> 658:          *
>> 659:          * @param index the index of the first variadic argument layout in the function descriptor associated
> 
> IMHO this description is still confusing because it speaks about an index into the function descriptor argument layouts - which this thing is not.

Right, will polish this some more as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1236016752
PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1236017428

From mcimadamore at openjdk.org  Wed Jun 21 00:06:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Jun 2023 00:06:05 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
 <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>
Message-ID: <BbLKmvUmhKUJBpogMZPiCSuM2fxccUHoG3689FmdYqY=.ae21baaa-0f61-4f3e-ab5b-ee958c218e36@github.com>

On Tue, 20 Jun 2023 23:57:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 652:
>> 
>>> 650:          * The {@code index} value must be greater than zero, and less than or equal to the number of argument layouts
>>> 651:          * of the function descriptor that is used in the same linkage request as this option. When the {@code index} is
>>> 652:          * equal to the number of argument layouts in the descriptor, it indicates a variadic function to which zero
>> 
>> This sentence is not clear. If index == num layouts then it means *all* arguments are variadic?
>
> index == 0 would mean all arguments are variadic. index == num layouts means none. (just like `"abcd".substring(4)` returns an empty string).

Yes, that's what I meant and got confused. But I missed the all-important `zero` in the javadoc - so I think that this bit of text is ok as it is. Apologize for the confusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1236019482

From darcy at openjdk.org  Wed Jun 21 00:08:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 00:08:13 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
Message-ID: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>

Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

-------------

Commit messages:
 - Fix whitespace.
 - JDK-8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives

Changes: https://git.openjdk.org/jdk/pull/14574/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310267
  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14574/head:pull/14574

PR: https://git.openjdk.org/jdk/pull/14574

From jvernee at openjdk.org  Wed Jun 21 00:08:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 Jun 2023 00:08:16 GMT
Subject: Integrated: 8310053: VarHandle and slice handle derived from layout
 are lacking alignment check
In-Reply-To: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
References: <7R-9fWgIV5LduY_rlBtTJ-8uFlUyFdGx67sPmm-0cyM=.b93820f1-4359-4581-a128-92080b09c62d@github.com>
Message-ID: <VAqM3ucOJ--G6peT9olHzC0CAI3bXpg65zZmQs-Vv0A=.8058c69f-3658-4187-a2b9-309200d2e920@github.com>

On Wed, 14 Jun 2023 19:30:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Add missing alignment checks for the alignment constraint of the root layout of a VarHandle created through `MemoryLayout::varHandle` and a MethodHandle `MemoryLayout::sliceHandle`.
> 
> Testing: `jdk_foreign` test suite

This pull request has now been integrated.

Changeset: e022e876
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e022e876543b65b531027662326f35b497861f33
Stats:     97 lines in 4 files changed: 81 ins; 4 del; 12 mod

8310053: VarHandle and slice handle derived from layout are lacking alignment check

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14475

From mcimadamore at openjdk.org  Wed Jun 21 00:11:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Jun 2023 00:11:06 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
 <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>
Message-ID: <IabUu8RcOrO1LsZko6Tm1j3X3vknyhbSxIncgCuHw7c=.b432a006-d7a0-400b-9b5f-024b8e2465a5@github.com>

On Tue, 20 Jun 2023 23:58:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 659:
>> 
>>> 657:          * against which the index is validated is available.
>>> 658:          *
>>> 659:          * @param index the index of the first variadic argument layout in the function descriptor associated
>> 
>> IMHO this description is still confusing because it speaks about an index into the function descriptor argument layouts - which this thing is not.
>
> Right, will polish this some more as well.

Possible suggestion/thing to try: use a bullet list to spell out all cases for `index`. E.g. we know there's index == 0 (all variadic). Then we know there's index = N (no variadic). Then there's index == m, 0 < m < N - which means layouts 0..m are non-variadic and m..N are variadic (where n..m denotes an interval with n included and m excluded).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1236021354

From jvernee at openjdk.org  Wed Jun 21 00:15:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 Jun 2023 00:15:16 GMT
Subject: [jdk21] RFR: 8310053: VarHandle and slice handle derived from layout
 are lacking alignment check
Message-ID: <LYK1jy-ao3BRBXTgN00NwCTkSZELYCCt76qJM3hXfjo=.9a437f15-7d5e-44ff-885f-8663b5d414c5@github.com>

Hi all,

This pull request contains a backport of commit [e022e876](https://github.com/openjdk/jdk/commit/e022e876543b65b531027662326f35b497861f33) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jorn Vernee on 21 Jun 2023 and was reviewed by Maurizio Cimadamore.

Thanks!

-------------

Commit messages:
 - Backport e022e876543b65b531027662326f35b497861f33

Changes: https://git.openjdk.org/jdk21/pull/42/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=42&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310053
  Stats: 97 lines in 4 files changed: 81 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk21/pull/42.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/42/head:pull/42

PR: https://git.openjdk.org/jdk21/pull/42

From liach at openjdk.org  Wed Jun 21 00:17:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 00:17:04 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
Message-ID: <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>

On Wed, 21 Jun 2023 00:00:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

src/java.base/share/classes/java/lang/Class.java line 818:

> 816:      * they represent, namely {@code boolean}, {@code byte},
> 817:      * {@code char}, {@code short}, {@code int},
> 818:      * {@code long}, {@code float}, and {@code double}.

Should we add `{@code void}` to the list here, as this is one of the primitive type names?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1236023720

From darcy at openjdk.org  Wed Jun 21 00:38:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 00:38:21 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
Message-ID: <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>

On Wed, 21 Jun 2023 00:13:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.
>
> src/java.base/share/classes/java/lang/Class.java line 818:
> 
>> 816:      * they represent, namely {@code boolean}, {@code byte},
>> 817:      * {@code char}, {@code short}, {@code int},
>> 818:      * {@code long}, {@code float}, and {@code double}.
> 
> Should we add `{@code void}` to the list here, as this is one of the primitive type names?

Hmm. I'll consider that. The javadoc in java.lang.Class is inconsistent in the formatting of "void" as a type name, some instances are in code markup while others are not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1236032594

From stuefe at openjdk.org  Wed Jun 21 04:59:20 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Jun 2023 04:59:20 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v3]
In-Reply-To: <Megdjl_ewrv7-1C1sqswpgG8LhQAVJJg1SQzQRp5IyE=.3e11665f-87a3-4b05-837d-d1e27d46fd19@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <JtT8c086L_oseaMtI4DjHYuRxzBAAvMh3EW6XmX4dGw=.653d66a1-b710-4724-bf39-913dbab2b246@github.com>
 <Megdjl_ewrv7-1C1sqswpgG8LhQAVJJg1SQzQRp5IyE=.3e11665f-87a3-4b05-837d-d1e27d46fd19@github.com>
Message-ID: <5TnNjPqsF0rclh7etP6XoXbqQ2iXwfBCwHjDsD98x2c=.6e905b3a-1d67-4bd4-9fd4-c982ec32d0ff@github.com>

On Tue, 20 Jun 2023 18:36:40 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback Volker and Roger
>
> Still good :)

Thanks @simonis and @RogerRiggs !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14531#issuecomment-1600070827

From stuefe at openjdk.org  Wed Jun 21 04:59:20 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Jun 2023 04:59:20 GMT
Subject: Integrated: JDK-8310265: (process) jspawnhelper should not use argv[0]
In-Reply-To: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
Message-ID: <njqNhCIO2qLIRWwgRQ09AjTEwE04-4lFmwtH518Ra1s=.c25e300e-a874-47cf-8263-b261474fdd72@github.com>

On Sat, 17 Jun 2023 18:24:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Reported by [jarabekit at gmail.com](mailto:jarabekit at gmail.com) [1] 
> 
> jspawnhelper uses argv[0] to receive the fd string from the parent. That breaks with conventions and trips over certain tools like binfmt_misc. 
> 
> For details, see linked ML discussion. 
> 
> [1] https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107738.html

This pull request has now been integrated.

Changeset: 47d00a4c
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47d00a4cbeff5d757dda9c660dfd2385c02a57d7
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8310265: (process) jspawnhelper should not use argv[0]

Reviewed-by: simonis, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14531

From asotona at openjdk.org  Wed Jun 21 06:32:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Jun 2023 06:32:13 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
Message-ID: <tljEeFn3OP_CPwsaV8VwNnlcPJszv4wn0BNMt79TFNA=.305b3b2d-11cc-4fec-b224-6c202640a7a8@github.com>

On Thu, 15 Jun 2023 17:22:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

I think we've resolved controversy about global static CHR cache (by having no global static CHR cache ;) and turned all performance issues into minor improvements. A new `ClassfileBenchmark` has been added for more precise future continuous performance monitoring.

This PR is now waiting for review to unblock all follow-up conversion work.

Thank you,
Adam

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1600258409

From jwaters at openjdk.org  Wed Jun 21 06:47:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 06:47:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <0zdhhpte62afwO6bR4wuM19NtaZ9tIUudr4f4S2sXdQ=.7ee922ac-8e24-45e5-8148-423cbbc348ee@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600271647

From liach at openjdk.org  Wed Jun 21 06:53:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 06:53:14 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
Message-ID: <GikEE5gtWmAln7XuANzUdPafagfuscv1b17uOMUuijE=.73568960-9d49-425f-ad08-a6bbb74f51e1@github.com>

On Thu, 15 Jun 2023 17:22:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

src/java.base/share/classes/jdk/internal/classfile/impl/ClassfileImpl.java line 63:

> 61:             DeadCodeOption.PATCH_DEAD_CODE,
> 62:             DeadLabelsOption.FAIL_ON_DEAD_LABELS,
> 63:             new ClassHierarchyResolverOptionImpl(ClassHierarchyResolver.defaultResolver()),

Don't users of the default context still share a non-thread-safe-cached version of the default resolver? We might still need to convert DEFAULT_CONTEXT field to a static defaultContext() method that returns a `new ClassfileImpl(...);` (the attribute mapper option can be shared).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236461953

From liach at openjdk.org  Wed Jun 21 06:57:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 06:57:17 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <GikEE5gtWmAln7XuANzUdPafagfuscv1b17uOMUuijE=.73568960-9d49-425f-ad08-a6bbb74f51e1@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
 <GikEE5gtWmAln7XuANzUdPafagfuscv1b17uOMUuijE=.73568960-9d49-425f-ad08-a6bbb74f51e1@github.com>
Message-ID: <Eg5lu-hqUZ5zS5i_nfJDC92YS9g1mzkcmE-bX0Asdmc=.295031d6-7496-4606-9425-650508abaa6e@github.com>

On Wed, 21 Jun 2023 06:50:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassfileImpl.java line 63:
> 
>> 61:             DeadCodeOption.PATCH_DEAD_CODE,
>> 62:             DeadLabelsOption.FAIL_ON_DEAD_LABELS,
>> 63:             new ClassHierarchyResolverOptionImpl(ClassHierarchyResolver.defaultResolver()),
> 
> Don't users of the default context still share a non-thread-safe-cached version of the default resolver? We might still need to convert DEFAULT_CONTEXT field to a static defaultContext() method that returns a `new ClassfileImpl(...);` (the attribute mapper option can be shared).

Please disregard this comment: Now the distinction of cache of resolvers is done in `StackMapGenerator`, meaning each stack map generation task has its own cache. Didn't see it early on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236465502

From pminborg at openjdk.org  Wed Jun 21 07:31:12 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 Jun 2023 07:31:12 GMT
Subject: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
Message-ID: <EDNwW5jRRXQnBDsq3k-Xav5ifklaJSzA2eji_x_lFFM=.8b8c93c8-f11d-4331-9c92-35ca2188cf33@github.com>

On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Yes. I recently added it. Please review.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/34#issuecomment-1600323874

From duke at openjdk.org  Wed Jun 21 07:36:15 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 07:36:15 GMT
Subject: RFR: 8310502 : optimization for UUID#toString
Message-ID: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>

By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.

The following are the test results of JMH: 

Benchmark                     Mode  Cnt      Score      Error   Units
UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

-------------

Commit messages:
 - 8310502 : optimization for UUID#toString

Changes: https://git.openjdk.org/jdk/pull/14578/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310502
  Stats: 105 lines in 1 file changed: 88 ins; 5 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From mbaesken at openjdk.org  Wed Jun 21 07:35:51 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 07:35:51 GMT
Subject: [jdk21] RFR: 8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
Message-ID: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>

8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

-------------

Commit messages:
 - Backport 4d66d977450e083214da3dba6ad4ed851c6c1cb4

Changes: https://git.openjdk.org/jdk21/pull/44/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=44&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309549
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/44/head:pull/44

PR: https://git.openjdk.org/jdk21/pull/44

From pminborg at openjdk.org  Wed Jun 21 07:37:04 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 Jun 2023 07:37:04 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid
In-Reply-To: <IabUu8RcOrO1LsZko6Tm1j3X3vknyhbSxIncgCuHw7c=.b432a006-d7a0-400b-9b5f-024b8e2465a5@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
 <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>
 <IabUu8RcOrO1LsZko6Tm1j3X3vknyhbSxIncgCuHw7c=.b432a006-d7a0-400b-9b5f-024b8e2465a5@github.com>
Message-ID: <0mgcbnkWISnn5-eS8ifzc7fx9xfkQArVTWmvchSDtL0=.60770424-7252-4617-93c6-b708d801ce2a@github.com>

On Wed, 21 Jun 2023 00:07:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Possible suggestion/thing to try: use a bullet list to spell out all cases for `index`. E.g. we know there's index == 0 (all variadic). Then we know there's index = N (no variadic). Then there's index == m, 0 < m < N - which means layouts 0..m are non-variadic and m..N are variadic (where n..m denotes an interval with n included and m excluded).

I think this is a good suggestion. It makes it much easier to understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1236509508

From djelinski at openjdk.org  Wed Jun 21 07:48:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 07:48:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
Message-ID: <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>

On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - update
>  - update
>  - update
>  - update
>  - 8308286 Fix clang warnings in linux code

Please update copyright years where they aren't at 2023 yet.

I verified these changes on Ubuntu 20.04 + clang 10; they are both necessary and sufficient to make the build pass with warnings as errors. I saw one more warning:

clang: warning: argument unused during compilation: '-static-libstdc++' [-Wunused-command-line-argument]

in `BUILD_SYSLOOKUPLIB_link.log`, but that one does not break the build.

I'm going to approve this once you fix the mentioned issues. Thanks for working on this!

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235:

> 233:         DISABLED_WARNINGS_gcc := int-to-pointer-cast, \
> 234:         DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \
> 235:         DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \

please group the disabled warnings by compiler (gcc, then clang, then clang_aix)

-------------

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1489972241
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1236510850

From dholmes at openjdk.org  Wed Jun 21 07:58:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jun 2023 07:58:12 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <_eBMP61aNZ7vhnYC0AhINpG7Qwxm4Zj_-pVn5OsQPQ4=.1b0887cc-9c2c-40a6-a92b-381c8502b6a3@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
 <1D5LsOe2qB-UQ-NH3tjX6y1NgiMLlEWHj9KwHhnOI_8=.342da45f-0237-4af8-84e1-f4fe65dc208d@github.com>
 <zmAAqodm-Kf5w90_IwRA6_zWh4kYA9hDaot3htWvo4M=.013f129f-973f-494c-acff-c750230bb610@github.com>
 <_eBMP61aNZ7vhnYC0AhINpG7Qwxm4Zj_-pVn5OsQPQ4=.1b0887cc-9c2c-40a6-a92b-381c8502b6a3@github.com>
Message-ID: <dlWMTDkBAlE14HqDGGqiJaFOTxq6arA6Q0uF6JNoZCk=.8f10466d-1f4a-4e8b-ab81-82edba91ec47@github.com>

On Tue, 20 Jun 2023 16:27:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I wondered about this, it looked so deliberate. So I wondered whether jspawnhelper is used outside of the posix_spawn context, but cannot find anything. Maybe historic?
>
> I'm not aware of any other uses either; its not intended to be used outside of ProcessImpl especially since the addition of the new protocol to communicate parameters and confirm launching of the child.

This curiosity has been present since Rob's first version:
https://mail.openjdk.org/pipermail/core-libs-dev/2012-November/012417.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14531#discussion_r1236549488

From alanb at openjdk.org  Wed Jun 21 08:01:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 08:01:05 GMT
Subject: RFR: 8310502 : optimization for UUID#toString
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>

On Wed, 21 Jun 2023 07:28:54 GMT, ??? <duke at openjdk.org> wrote:

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

src/java.base/share/classes/java/lang/Long.java line 97:

> 95:                     + (lo < 10 ? '0' + lo : 'a' + lo - 10));
> 96:         }
> 97:     }

Are you checking the impact on startup? I guess I would have expected to see it loaded from the CDS archive. Given that the usage is just UUID::toString then maybe you could move this to a holder class containing a Stable array, at least until there is a better way to have lazily computed constants. Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1236556426

From stuefe at openjdk.org  Wed Jun 21 08:06:16 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 21 Jun 2023 08:06:16 GMT
Subject: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0]
 [v2]
In-Reply-To: <dlWMTDkBAlE14HqDGGqiJaFOTxq6arA6Q0uF6JNoZCk=.8f10466d-1f4a-4e8b-ab81-82edba91ec47@github.com>
References: <MVSnqYti2IRQ6K2i9bBbigCnKJkmwyaxrrpYUzbRAsY=.95864cce-7d68-4bd2-ab3d-3d56254c104f@github.com>
 <xqW41deCcKR9ZIQhPhlFBKBQa61x3p7pH8fFJUKCOv0=.5b8e1a30-17f1-4986-83d3-5da8b012f256@github.com>
 <1D5LsOe2qB-UQ-NH3tjX6y1NgiMLlEWHj9KwHhnOI_8=.342da45f-0237-4af8-84e1-f4fe65dc208d@github.com>
 <zmAAqodm-Kf5w90_IwRA6_zWh4kYA9hDaot3htWvo4M=.013f129f-973f-494c-acff-c750230bb610@github.com>
 <_eBMP61aNZ7vhnYC0AhINpG7Qwxm4Zj_-pVn5OsQPQ4=.1b0887cc-9c2c-40a6-a92b-381c8502b6a3@github.com>
 <dlWMTDkBAlE14HqDGGqiJaFOTxq6arA6Q0uF6JNoZCk=.8f10466d-1f4a-4e8b-ab81-82edba91ec47@github.com>
Message-ID: <GJGqkgHsVezb8piK-fvcTIrkihB8jiUyhq_z3ckefM0=.2c4e24a4-84fb-4812-9f2f-460bd5314fe9@github.com>

On Wed, 21 Jun 2023 07:55:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm not aware of any other uses either; its not intended to be used outside of ProcessImpl especially since the addition of the new protocol to communicate parameters and confirm launching of the child.
>
> This curiosity has been present since Rob's first version:
> https://mail.openjdk.org/pipermail/core-libs-dev/2012-November/012417.html

I assumed that at some point in its life, maybe just in the first unpublished versions, the jspawnhelper had a variable number of arguments, possibly from different callers. But the fd-string was always supposed to be the last one. Then this would have made perfect sense.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14531#discussion_r1236569635

From mcimadamore at openjdk.org  Wed Jun 21 08:08:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Jun 2023 08:08:12 GMT
Subject: [jdk21] RFR: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
Message-ID: <qLm_MHu2zlcwsx11eUbnbtBqkvh_dgwzbAQ2BYtxyUU=.2d07d587-b35c-4ab2-a80a-04f81f0833c0@github.com>

On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/34#pullrequestreview-1490063531

From liach at openjdk.org  Wed Jun 21 08:10:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 08:10:17 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
Message-ID: <uyyUFf2zLihyCnma261PNzyX-OWWAxZm9swU_ence_g=.ceba6b83-59bf-4e26-8ed5-25b2fdf7a3ff@github.com>

On Thu, 15 Jun 2023 17:22:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 57:

> 55: 
> 56:     /**
> 57:      * {@return a new context with default options}

Suggestion:

     * {@return a context with default options}

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 272:

> 270:     /**
> 271:      * Build a classfile into a file using the provided constant pool
> 272:      * builder (which encapsulates classfile processing options.)

The CP is now simply a data holder; it no longer holds the processing options. Same update is needed for the other few build methods taking a CP instance.
Suggestion:

     * builder.

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 340:

> 338:      *
> 339:      * @implNote
> 340:      * <p>This method behaves as if:

Suggestion:

     * This method behaves as if:

Redundant break

src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 343:

> 341:      * {@snippet lang=java :
> 342:      *     Classfile.of().build(thisClass(), ConstantPoolBuilder.of(this),
> 343:      *                     b -> b.transform(this, transform));

Suggestion:

     *     this.build(model.thisClass(), ConstantPoolBuilder.of(model),
     *                     b -> b.transform(model, transform));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236575941
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236572387
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236548304
PR Review Comment: https://git.openjdk.org/jdk/pull/14180#discussion_r1236570476

From pminborg at openjdk.org  Wed Jun 21 08:16:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 Jun 2023 08:16:06 GMT
Subject: [jdk21] Integrated: 8309937: Add @sealedGraph for some Panama FFM
 interfaces
In-Reply-To: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
References: <cKDTJVoM3eM3MT8J9k3LYm7PVTKgW4plSkFAWDvHU2o=.129ab7c4-a459-4bfa-9674-9d2ddb416f0c@github.com>
Message-ID: <96UHOsf39jPANxeDdkhC3LzfmwEQnCOo7debtrg-6v8=.a6408015-e7b3-4dc6-97be-9810335c4c55@github.com>

On Mon, 19 Jun 2023 14:58:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [b412fc79](https://github.com/openjdk/jdk/commit/b412fc79c3c2548df10918090beedaf6b2d08d96) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 16 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ef0357f6
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/ef0357f6cbb23f22a60266206f8937f1ad23d85c
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8309937: Add @sealedGraph for some Panama FFM interfaces

Reviewed-by: mcimadamore
Backport-of: b412fc79c3c2548df10918090beedaf6b2d08d96

-------------

PR: https://git.openjdk.org/jdk21/pull/34

From jwaters at openjdk.org  Wed Jun 21 08:22:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 08:22:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <8mSr3SYUR0t4eP-T6eJxu4EM4jhnz-2YMO8RBtrAoIQ=.99c452b4-dc5c-4579-a89b-d46d744a6579@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600400436

From mbaesken at openjdk.org  Wed Jun 21 08:34:22 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 08:34:22 GMT
Subject: [jdk21] RFR: 8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
Message-ID: <wRrs7LMauKh8RLJTE9OEKaKlQ9j44g2u9Dub66tqsqs=.3c98bd9d-1a9b-480a-a279-a733acfd49e0@github.com>

8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX

-------------

Commit messages:
 - Backport 6a63badd8ea3e79cd9fc3cb33aff499fc9a6d3f1

Changes: https://git.openjdk.org/jdk21/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=45&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310191
  Stats: 20 lines in 1 file changed: 8 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk21/pull/45

From duke at openjdk.org  Wed Jun 21 08:43:04 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 08:43:04 GMT
Subject: RFR: 8310502 : optimization for UUID#toString
In-Reply-To: <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
Message-ID: <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>

On Wed, 21 Jun 2023 07:58:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> src/java.base/share/classes/java/lang/Long.java line 97:
> 
>> 95:                     + (lo < 10 ? '0' + lo : 'a' + lo - 10));
>> 96:         }
>> 97:     }
> 
> Are you checking the impact on startup? I guess I would have expected to see it loaded from the CDS archive. Given that the usage is just UUID::toString then maybe you could move this to a holder class containing a Stable array, at least until there is a better way to have lazily computed constants. Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.

1. HEX256 can be used to optimize all integers to hex strings, such as Integer#toHexString and Long#toHexString and byte [] to hexstring.

2. i am a newcomer, and i don't understand what 'loaded from the CDS archive' means, do you mean to use constants instead? such as

HEX256 = new char[]{
        12336, 12337, 12338, 12339, 12340, 12341, 12342, 12343, 12344, 12345,
        12385, 12386, 12387, 12388, 12389, 12390, 12592, 12593, 12594, 12595,
        12596, 12597, 12598, 12599, 12600, 12601, 12641, 12642, 12643, 12644,
        12645, 12646, 12848, 12849, 12850, 12851, 12852, 12853, 12854, 12855,
        12856, 12857, 12897, 12898, 12899, 12900, 12901, 12902, 13104, 13105,
        13106, 13107, 13108, 13109, 13110, 13111, 13112, 13113, 13153, 13154,
        13155, 13156, 13157, 13158, 13360, 13361, 13362, 13363, 13364, 13365,
        13366, 13367, 13368, 13369, 13409, 13410, 13411, 13412, 13413, 13414,
        13616, 13617, 13618, 13619, 13620, 13621, 13622, 13623, 13624, 13625,
        13665, 13666, 13667, 13668, 13669, 13670, 13872, 13873, 13874, 13875,
        13876, 13877, 13878, 13879, 13880, 13881, 13921, 13922, 13923, 13924,
        13925, 13926, 14128, 14129, 14130, 14131, 14132, 14133, 14134, 14135,
        14136, 14137, 14177, 14178, 14179, 14180, 14181, 14182, 14384, 14385,
        14386, 14387, 14388, 14389, 14390, 14391, 14392, 14393, 14433, 14434,
        14435, 14436, 14437, 14438, 14640, 14641, 14642, 14643, 14644, 14645,
        14646, 14647, 14648, 14649, 14689, 14690, 14691, 14692, 14693, 14694,
        24880, 24881, 24882, 24883, 24884, 24885, 24886, 24887, 24888, 24889,
        24929, 24930, 24931, 24932, 24933, 24934, 25136, 25137, 25138, 25139,
        25140, 25141, 25142, 25143, 25144, 25145, 25185, 25186, 25187, 25188,
        25189, 25190, 25392, 25393, 25394, 25395, 25396, 25397, 25398, 25399,
        25400, 25401, 25441, 25442, 25443, 25444, 25445, 25446, 25648, 25649,
        25650, 25651, 25652, 25653, 25654, 25655, 25656, 25657, 25697, 25698,
        25699, 25700, 25701, 25702, 25904, 25905, 25906, 25907, 25908, 25909,
        25910, 25911, 25912, 25913, 25953, 25954, 25955, 25956, 25957, 25958,
        26160, 26161, 26162, 26163, 26164, 26165, 26166, 26167, 26168, 26169,
        26209, 26210, 26211, 26212, 26213, 26214
};

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1236632961

From liach at openjdk.org  Wed Jun 21 09:02:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 09:02:04 GMT
Subject: RFR: 8310502 : optimization for UUID#toString
In-Reply-To: <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
 <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
Message-ID: <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>

On Wed, 21 Jun 2023 08:40:43 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Long.java line 97:
>> 
>>> 95:                     + (lo < 10 ? '0' + lo : 'a' + lo - 10));
>>> 96:         }
>>> 97:     }
>> 
>> Are you checking the impact on startup? I guess I would have expected to see it loaded from the CDS archive. Given that the usage is just UUID::toString then maybe you could move this to a holder class containing a Stable array, at least until there is a better way to have lazily computed constants. Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.
>
> 1. HEX256 can be used to optimize all integers to hex strings, such as Integer#toHexString and Long#toHexString and byte [] to hexstring.
> 
> 2. i am a newcomer, and i don't understand what 'loaded from the CDS archive' means, do you mean to use constants instead? such as
> 
> HEX256 = new char[]{
>         12336, 12337, 12338, 12339, 12340, 12341, 12342, 12343, 12344, 12345,
>         12385, 12386, 12387, 12388, 12389, 12390, 12592, 12593, 12594, 12595,
>         12596, 12597, 12598, 12599, 12600, 12601, 12641, 12642, 12643, 12644,
>         12645, 12646, 12848, 12849, 12850, 12851, 12852, 12853, 12854, 12855,
>         12856, 12857, 12897, 12898, 12899, 12900, 12901, 12902, 13104, 13105,
>         13106, 13107, 13108, 13109, 13110, 13111, 13112, 13113, 13153, 13154,
>         13155, 13156, 13157, 13158, 13360, 13361, 13362, 13363, 13364, 13365,
>         13366, 13367, 13368, 13369, 13409, 13410, 13411, 13412, 13413, 13414,
>         13616, 13617, 13618, 13619, 13620, 13621, 13622, 13623, 13624, 13625,
>         13665, 13666, 13667, 13668, 13669, 13670, 13872, 13873, 13874, 13875,
>         13876, 13877, 13878, 13879, 13880, 13881, 13921, 13922, 13923, 13924,
>         13925, 13926, 14128, 14129, 14130, 14131, 14132, 14133, 14134, 14135,
>         14136, 14137, 14177, 14178, 14179, 14180, 14181, 14182, 14384, 14385,
>         14386, 14387, 14388, 14389, 14390, 14391, 14392, 14393, 14433, 14434,
>         14435, 14436, 14437, 14438, 14640, 14641, 14642, 14643, 14644, 14645,
>         14646, 14647, 14648, 14649, 14689, 14690, 14691, 14692, 14693, 14694,
>         24880, 24881, 24882, 24883, 24884, 24885, 24886, 24887, 24888, 24889,
>         24929, 24930, 24931, 24932, 24933, 24934, 25136, 25137, 25138, 25139,
>         25140, 25141, 25142, 25143, 25144, 25145, 25185, 25186, 25187, 25188,
>         25189, 25190, 25392, 25393, 25394, 25395, 25396, 25397, 25398, 25399,
>         25400, 25401, 25441, 25442, 25443, 25444, 25445, 25446, 25648, 25649,
>         25650, 25651, 25652, 25653, 25654, 25655, 25656, 25657, 25697, 25698,
>         25699, 25700, 25701, 25702, 25904, 25905, 25906, 25907, 25908, 25909,
>         25910, 25911, 25912, 25913, 25953, 25954, 25955, 25956, 25957, 25958,
>         26160, 26161, 26162, 26163, 26164, 26165, 26166, 26167, 26168, 26169,
>         26209, 26210, 26211, 26212, 26213, 26214
> };

> Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.

A note about `@Stable`: `Integer.digits` and `HEX256` are not, and they might see performance improvements and change the benchmark results if they are declared so.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1236656177

From asotona at openjdk.org  Wed Jun 21 09:25:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 21 Jun 2023 09:25:25 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v22]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <J3tCGZ395B5j0PcKO4b7NuNJr1iaA9UwLBAZi0Gl6D8=.a3febbd7-245c-48ff-a323-9b0fd03ed8ee@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/baa01584..4017e28b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=20-21

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From djelinski at openjdk.org  Wed Jun 21 09:27:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 09:27:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <R47GRCPHRK2m8lVzMN5eoW773ZqoCidoSBKImdqwTTk=.9c7be02e-cc55-44e7-928d-5b39420a5371@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 475:

> 473:         topLevelWindow = hwnd;
> 474:     } else {
> 475:         EnumChildWindows(hwnd, (WNDENUMPROC) EnumChildProc, nullptr);

Did you try to compile this?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1236688830

From duke at openjdk.org  Wed Jun 21 09:52:02 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 09:52:02 GMT
Subject: RFR: 8310502 : optimization for UUID#toString
In-Reply-To: <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
 <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
 <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>
Message-ID: <1i7Lw0AGawydZ16lB7vTPuY3rCnR4xIIe_aRKMlRqUY=.5bc69a6f-4e18-4d19-ba4c-7e775d457df8@github.com>

On Wed, 21 Jun 2023 08:58:53 GMT, Chen Liang <liach at openjdk.org> wrote:

> > Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.
> 
> A note about `@Stable`: `Integer.digits` and `HEX256` are not, and they might see performance improvements and change the benchmark results if they are declared so.

use HEX256 optimize Integer.toHexString
https://github.com/wenshao/jdk_8310502_test/blob/main/src/main/java/com/alibaba/openjdk/HexUtils.java

       char[] hex256 = UUIDUtils.HEX256;

        int i0 = (i >> 24) & 255;
        int i1 = (i >> 16) & 255;
        int i2 = (i >> 8) & 255;
        int i3 = i & 255;

        char c0 = hex256[i0];
        char c1 = hex256[i1];
        char c2 = hex256[i2];
        char c3 = hex256[i3];

        byte[] bytes;
        if (COMPACT_STRINGS) {
            if ((i >> 4) == 0) {
                bytes = new byte[1];
                bytes[0] = (byte) c3;
            } else if ((i >> 8) == 0) {
                bytes = new byte[2];
                bytes[0] = (byte) (c3 >> 8);
                bytes[1] = (byte) c3;
            } else if ((i >> 12) == 0) {
                bytes = new byte[3];
                bytes[0] = (byte) c2;
                bytes[1] = (byte) (c3 >> 8);
                bytes[2] = (byte) c3;
            } else if ((i >> 16) == 0) {
                bytes = new byte[4];
                bytes[0] = (byte) (c2 >> 8);
                bytes[1] = (byte) c2;
                bytes[2] = (byte) (c3 >> 8);
                bytes[3] = (byte) c3;
            } else if ((i >> 20) == 0) {
                bytes = new byte[5];
                bytes[0] = (byte) c1;
                bytes[1] = (byte) (c2 >> 8);
                bytes[2] = (byte) c2;
                bytes[3] = (byte) (c3 >> 8);
                bytes[4] = (byte) c3;
            } else if ((i >> 24) == 0) {
                bytes = new byte[6];
                bytes[0] = (byte) (c1 >> 8);
                bytes[1] = (byte) c1;
                bytes[2] = (byte) (c2 >> 8);
                bytes[3] = (byte) c2;
                bytes[4] = (byte) (c3 >> 8);
                bytes[5] = (byte) c3;
            } else if ((i >> 28) == 0) {
                bytes = new byte[7];
                bytes[0] = (byte) c0;
                bytes[1] = (byte) (c1 >> 8);
                bytes[2] = (byte) c1;
                bytes[3] = (byte) (c2 >> 8);
                bytes[4] = (byte) c2;
                bytes[5] = (byte) (c3 >> 8);
                bytes[6] = (byte) c3;
            } else {
                bytes = new byte[8];
                bytes[0] = (byte) (c0 >> 8);
                bytes[1] = (byte) c0;
                bytes[2] = (byte) (c1 >> 8);
                bytes[3] = (byte) c1;
                bytes[4] = (byte) (c2 >> 8);
                bytes[5] = (byte) c2;
                bytes[6] = (byte) (c3 >> 8);
                bytes[7] = (byte) c3;
            }

            return new Stringbytes, LATIN1);
      }
      // ....


* benchmark code
https://github.com/wenshao/jdk_8310502_test/blob/main/src/main/java/com/alibaba/openjdk/HexUtilsBenchmark.java

* benchmark result

Benchmark                Mode  Cnt     Score    Error   Units
HexUtilsBenchmark.fast  thrpt    5  2910.332 ? 20.051  ops/ms
HexUtilsBenchmark.jdk   thrpt    5  1966.712 ? 48.141  ops/ms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1236721668

From alanb at openjdk.org  Wed Jun 21 09:58:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 09:58:06 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <gL59tX6QJ53qJldSg6MT4TM-KmtJpRgnegAkwvMJCCg=.f99c53dd-a144-4d54-a1ff-895729513638@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
 <TeHXYnEHfkamyj7HVyXRxDZtRQ40rriaWSxGOZbo4QA=.9719c25a-cf82-4b5d-9083-afac801269a6@github.com>
 <gL59tX6QJ53qJldSg6MT4TM-KmtJpRgnegAkwvMJCCg=.f99c53dd-a144-4d54-a1ff-895729513638@github.com>
Message-ID: <MMubeb7mIk2-ok46xm64tq3QxjazBmPTU2cS8nRMHqA=.974492bd-675c-4790-81c7-a30a76441990@github.com>

On Tue, 20 Jun 2023 17:45:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Binary name is a long-standing behavior. It's a spec bug.

Yes, I view this PR as just specifying long standing behavior. The name used for array class may be surprising but I don't think it can be changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1236728781

From liach at openjdk.org  Wed Jun 21 10:04:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 10:04:05 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v4]
In-Reply-To: <MMubeb7mIk2-ok46xm64tq3QxjazBmPTU2cS8nRMHqA=.974492bd-675c-4790-81c7-a30a76441990@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <6zmFWy1OvcHLVKLohwQqQy66KZtGiwhYT92lsrjOfzE=.5f11ea49-e212-459a-8204-4d5519c26178@github.com>
 <_ngXfkn62R3AbuLx0fPJL7cwdZ59F43xsgCDCPUAbbg=.5adee83f-4913-46ac-8b96-e394829a8a7a@github.com>
 <TeHXYnEHfkamyj7HVyXRxDZtRQ40rriaWSxGOZbo4QA=.9719c25a-cf82-4b5d-9083-afac801269a6@github.com>
 <gL59tX6QJ53qJldSg6MT4TM-KmtJpRgnegAkwvMJCCg=.f99c53dd-a144-4d54-a1ff-895729513638@github.com>
 <MMubeb7mIk2-ok46xm64tq3QxjazBmPTU2cS8nRMHqA=.974492bd-675c-4790-81c7-a30a76441990@github.com>
Message-ID: <mvBfSeSd79npTyx9gVYQOyG4WBv-HmnP2WHUszO41d8=.3335ba84-05f5-4796-8dc0-a57359355b89@github.com>

On Wed, 21 Jun 2023 09:54:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Binary name is a long-standing behavior.  It's a spec bug.
>
>> Binary name is a long-standing behavior. It's a spec bug.
> 
> Yes, I view this PR as just specifying long standing behavior. The name used for array class may be surprising but I don't think it can be changed.

Such array names and binary name for nested/inner classes have always been returned by `Class::getName` as well, so they shouldn't be too surprising considering the old specification mentions it reuses the `getName` format.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1236736162

From duke at openjdk.org  Wed Jun 21 10:11:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 10:11:09 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v2]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <FNIFW1e-nxa0MyMWqWUghHM2M1tncbpifoiDdIaVTBI=.8450bbe4-6d9f-4f5a-9ba5-3d788ae27144@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  8310502 : HEX256 initialization use constant values improved jvm startup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/14592810..35af153a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=00-01

  Stats: 40 lines in 1 file changed: 30 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From rgiulietti at openjdk.org  Wed Jun 21 10:20:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 21 Jun 2023 10:20:07 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v2]
In-Reply-To: <FNIFW1e-nxa0MyMWqWUghHM2M1tncbpifoiDdIaVTBI=.8450bbe4-6d9f-4f5a-9ba5-3d788ae27144@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <FNIFW1e-nxa0MyMWqWUghHM2M1tncbpifoiDdIaVTBI=.8450bbe4-6d9f-4f5a-9ba5-3d788ae27144@github.com>
Message-ID: <IPrA9BX1L3BojDRczwNqgDpB55eeBc90dGA8Y_rgKVE=.f284486b-12f0-4ee2-b95d-86961861bcb1@github.com>

On Wed, 21 Jun 2023 10:11:09 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8310502 : HEX256 initialization use constant values improved jvm startup

src/java.base/share/classes/java/lang/Long.java line 128:

> 126:         26209, 26210, 26211, 26212, 26213, 26214
> 127:     };
> 128: 

Can we perhaps have hex literals here? I think they are easier to visually check than decimals.

static final char[] HEX256 = new char[]{
        0x3030, 0x3031, 0x3032, 0x3033, 0x3034, 0x3035, 0x3036, 0x3037, ...

or

static final char[] HEX256 = new char[]{
        0x30_30, 0x30_31, 0x30_32, 0x30_33, 0x30_34, 0x30_35, 0x30_36, 0x30_37, ...

src/java.base/share/classes/java/lang/Long.java line 492:

> 490:         final char[] hex256 = HEX256;
> 491: 
> 492:         char i = hex256[((int) (msb >> 56)) & 255];

Masks are easier to read when expressed as hex literals.

char i = hex256[((int) (msb >> 56)) & 0xFF];
...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1236753357
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1236753461

From duke at openjdk.org  Wed Jun 21 11:06:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 11:06:08 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v3]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <SGDgNC7WpdFADu8WrNLBpOtvVtQHd3bE8x7kC7iQgV0=.d63801a4-58ab-4105-8809-fc465302da08@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  8310502 : hex literal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/35af153a..8bc49c9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=01-02

  Stats: 47 lines in 1 file changed: 0 ins; 0 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From prappo at openjdk.org  Wed Jun 21 11:42:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 21 Jun 2023 11:42:04 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <CJIjOczqDb2lW0K2bwOAXal462WtcDN6EFRTHP6Orww=.752d8e2e-e1da-49d5-b060-fd227d7ee8a4@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

src/java.base/share/classes/java/lang/Object.java line 260:

> 258:      * }
> 259:      * The {@link java.util.Objects#toIdentityString(Object)
> 260:      * Objects.toIdentityString} method returns the string for an

That last sentence doesn't feel like it needs to be part of `@implSpec`, although there's definitely a connection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1236859323

From prappo at openjdk.org  Wed Jun 21 11:53:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 21 Jun 2023 11:53:03 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <xUViJZuBt9MeuvS1QYqMP4hZuHvz5QnSR4Np4jpNV2g=.084aecf7-e114-4f2e-94cb-265675c08a3b@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

src/java.base/share/classes/java/lang/Object.java line 260:

> 258:      * }
> 259:      * The {@link java.util.Objects#toIdentityString(Object)
> 260:      * Objects.toIdentityString} method returns the string for an

Separately, is it just me or this sentence could be rephrased to not read like `toIdentityString(Object)` accepts an object equal to the string (that would ...)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1236870099

From prappo at openjdk.org  Wed Jun 21 11:53:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 21 Jun 2023 11:53:05 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <CJIjOczqDb2lW0K2bwOAXal462WtcDN6EFRTHP6Orww=.752d8e2e-e1da-49d5-b060-fd227d7ee8a4@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
 <CJIjOczqDb2lW0K2bwOAXal462WtcDN6EFRTHP6Orww=.752d8e2e-e1da-49d5-b060-fd227d7ee8a4@github.com>
Message-ID: <pRSU6nrByPhQR9cHFdRohYAL-2vpBMsf5PH4Yc3MzNM=.86694ac5-5d83-49f7-bf22-1c11d893d291@github.com>

On Wed, 21 Jun 2023 11:39:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
>> 
>> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
>> 
>> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.
>
> src/java.base/share/classes/java/lang/Object.java line 260:
> 
>> 258:      * }
>> 259:      * The {@link java.util.Objects#toIdentityString(Object)
>> 260:      * Objects.toIdentityString} method returns the string for an
> 
> That last sentence doesn't feel like it needs to be part of `@implSpec`, although there's definitely a connection.

That is, a clear connection to what's being described by that `@implSpec`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1236873033

From prappo at openjdk.org  Wed Jun 21 11:58:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 21 Jun 2023 11:58:06 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <L4hQ4t4s_7gA1IklrR2qaWxzh5WG5QM24dHdkTJpFsg=.eae19715-38e0-4ffd-a87e-4821eb5ea319@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

While it's out of scope of this PR, I note that we could also use the inline variant of `@return` in those methods of `Objects` that the `Object` refers to: `hash(Object)`, `hashCode(Object...)`, and `equals(Object, Object)`. In fact, I think they are crying for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14567#issuecomment-1600698509

From djelinski at openjdk.org  Wed Jun 21 12:07:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 12:07:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <lGA7o7ITfyNyU_WFY_Yz48yh32hIZn_JtEBNkdXsX7w=.ff33e800-c509-48e6-b3d9-2739a88dace4@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Compilation should be a good enough test for the `long` -> `jint` changes. These changes are supposed to address [this difference](https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#overload-resolution-involving-integral-overloads-and-long-arguments) between MSVC behavior and the C++ standard. When compiled with `-permissive-` or with a compiler that puts more emphasis on standards conformance (like clang), the current code fails to compile.

I verified some of the generated binaries by comparing the results of `dumpbin /all` before and after the change. Most of the time the changes were limited to timestamp, UUID and mangled function names. `Jaccesswalker.exe` had a few more changes because of a changed format string. None of the changed function names in client libs area are externally visible, but there are some observable changes to `c2v` functions exported from jvm.dll.

I had to revert some of the `NULL`->`nullptr` changes to get this to compile; I assume this will be addressed before this PR is merged. Judging by the PR title, these changes don't belong here anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600710570

From jwaters at openjdk.org  Wed Jun 21 12:13:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 21 Jun 2023 12:13:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
Message-ID: <IzXWSLSA_0wc-cCWzaQ63uRX8-IzeIpMXOndG3R9wPY=.910d85fe-8ab7-4d4c-8588-863cc67468c8@github.com>

On Thu, 1 Jun 2023 11:49:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the code that is actually warning

Yeah, those were code cleanups I thought I could do out of convenience, I'll revert them all before this goes in

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1600719023

From alanb at openjdk.org  Wed Jun 21 12:37:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 12:37:24 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
Message-ID: <A08UyJFJD0qu4buXohVyyjCkWJJInXL4RfbJeZrX_tU=.f1e7e769-8726-4401-a672-b26b96aba39b@github.com>

On Wed, 21 Jun 2023 00:00:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

src/java.base/share/classes/java/lang/Class.java line 823:

> 821:      *
> 822:      * @apiNote
> 823:      * These {@code Class} objects can be accessed via the {@code

It might be clearer if the API note starts with something like "A Class object representing a primitive type" rather than "These Class objects".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1236929019

From alanb at openjdk.org  Wed Jun 21 13:32:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 13:32:09 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <pRSU6nrByPhQR9cHFdRohYAL-2vpBMsf5PH4Yc3MzNM=.86694ac5-5d83-49f7-bf22-1c11d893d291@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
 <CJIjOczqDb2lW0K2bwOAXal462WtcDN6EFRTHP6Orww=.752d8e2e-e1da-49d5-b060-fd227d7ee8a4@github.com>
 <pRSU6nrByPhQR9cHFdRohYAL-2vpBMsf5PH4Yc3MzNM=.86694ac5-5d83-49f7-bf22-1c11d893d291@github.com>
Message-ID: <n3psAbThZxm_HLA2mV3-3lBX8_atRoRzBSJCufveEi0=.c971cf60-787f-4269-b0c0-f651b22fe3b1@github.com>

On Wed, 21 Jun 2023 11:49:54 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Object.java line 260:
>> 
>>> 258:      * }
>>> 259:      * The {@link java.util.Objects#toIdentityString(Object)
>>> 260:      * Objects.toIdentityString} method returns the string for an
>> 
>> That last sentence doesn't feel like it needs to be part of `@implSpec`, although there's definitely a connection.
>
> That is, a clear connection to what's being described by that `@implSpec`.

This method has an existing apiNote and implSpec. I suspect Joe meant to add this sentence to the apiNote, not the implSpec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1236963868

From duke at openjdk.org  Wed Jun 21 13:35:05 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 13:35:05 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v3]
In-Reply-To: <SGDgNC7WpdFADu8WrNLBpOtvVtQHd3bE8x7kC7iQgV0=.d63801a4-58ab-4105-8809-fc465302da08@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SGDgNC7WpdFADu8WrNLBpOtvVtQHd3bE8x7kC7iQgV0=.d63801a4-58ab-4105-8809-fc465302da08@github.com>
Message-ID: <hvZtu2hjLgVeJemUoLduxZ1ngXqXyLhjkbBiTZyiuyY=.6bc410cb-bbb9-440b-aded-1774af61708b@github.com>

On Wed, 21 Jun 2023 11:06:08 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8310502 : hex literal

* benchmark code
https://github.com/wenshao/jdk_8310502_test/blob/main/src/main/java/com/alibaba/openjdk/UUIDUtilsBenchmark.java

* benchmark result

Benchmark                 Mode  Cnt     Score    Error   Units
HexUtilsBenchmark.fast   thrpt    5  2971.864 ? 17.277  ops/ms
HexUtilsBenchmark.jdk    thrpt    5  1984.653 ? 11.733  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1600843797

From liach at openjdk.org  Wed Jun 21 14:05:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 14:05:10 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <settcOJELxu9x4qeXE_uxvedv0-QfAhGyza1JwNsdns=.575ecf46-de82-4cca-b434-dc803fa1115d@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

src/java.base/share/classes/java/lang/Object.java line 160:

> 158:      * general contract for the {@code hashCode} method, which states
> 159:      * that equal objects must have equal hash codes.
> 160:      * <p>The two-argument {@link java.util.Objects#equals(Object,

I recommend a blank line before to make the paragraph break more obvious.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1237051269

From mcimadamore at openjdk.org  Wed Jun 21 14:07:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 21 Jun 2023 14:07:12 GMT
Subject: [jdk21] RFR: 8310053: VarHandle and slice handle derived from
 layout are lacking alignment check
In-Reply-To: <LYK1jy-ao3BRBXTgN00NwCTkSZELYCCt76qJM3hXfjo=.9a437f15-7d5e-44ff-885f-8663b5d414c5@github.com>
References: <LYK1jy-ao3BRBXTgN00NwCTkSZELYCCt76qJM3hXfjo=.9a437f15-7d5e-44ff-885f-8663b5d414c5@github.com>
Message-ID: <_K1x6aNMOvG_SHI8iMoGlJe0NOhs3YlT-gqJg5o_f-Q=.c3019122-3595-4bf4-bcf7-e91281cb0620@github.com>

On Wed, 21 Jun 2023 00:08:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e022e876](https://github.com/openjdk/jdk/commit/e022e876543b65b531027662326f35b497861f33) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 21 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/42#pullrequestreview-1490837380

From stsypanov at openjdk.org  Wed Jun 21 14:09:21 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 21 Jun 2023 14:09:21 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily
Message-ID: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>

Just a tiny clean-up to remove racy read within synchronized method

-------------

Commit messages:
 - 8310530: PipedOutputStream.flush() accesses sink racily

Changes: https://git.openjdk.org/jdk/pull/14589/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14589&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310530
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14589/head:pull/14589

PR: https://git.openjdk.org/jdk/pull/14589

From liach at openjdk.org  Wed Jun 21 14:09:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 14:09:21 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily
In-Reply-To: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
Message-ID: <5uQb42QmjGtiQXy6MsepPrUWOFIViMNi9wWS92gEzN8=.a52dcf79-6b1f-485e-b4be-c8d3828578a8@github.com>

On Wed, 21 Jun 2023 14:01:33 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Just a tiny clean-up to remove racy read within synchronized method

src/java.base/share/classes/java/io/PipedOutputStream.java line 166:

> 164:     @Override
> 165:     public synchronized void flush() throws IOException {
> 166:         PipedInputStream sink = this.sink;

Suggestion:

        var sink = this.sink;

As seen in other methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14589#discussion_r1237059920

From pminborg at openjdk.org  Wed Jun 21 14:16:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 21 Jun 2023 14:16:17 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v3]
In-Reply-To: <1i7Lw0AGawydZ16lB7vTPuY3rCnR4xIIe_aRKMlRqUY=.5bc69a6f-4e18-4d19-ba4c-7e775d457df8@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
 <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
 <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>
 <1i7Lw0AGawydZ16lB7vTPuY3rCnR4xIIe_aRKMlRqUY=.5bc69a6f-4e18-4d19-ba4c-7e775d457df8@github.com>
Message-ID: <giul8FbzVUlryZ26tX2wCqg_GR_jgfhRZNqSRpIUKs8=.8e907e96-eedd-4704-a360-7e88ad52a530@github.com>

On Wed, 21 Jun 2023 09:48:54 GMT, ??? <duke at openjdk.org> wrote:

>>> Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.
>> 
>> A note about `@Stable`: `Integer.digits` and `HEX256` are not, and they might see performance improvements and change the benchmark results if they are declared so.
>
>> > Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.
>> 
>> A note about `@Stable`: `Integer.digits` and `HEX256` are not, and they might see performance improvements and change the benchmark results if they are declared so.
> 
> use HEX256 optimize Integer.toHexString
> https://github.com/wenshao/jdk_8310502_test/blob/main/src/main/java/com/alibaba/openjdk/HexUtils.java
> 
>        char[] hex256 = UUIDUtils.HEX256;
> 
>         int i0 = (i >> 24) & 255;
>         int i1 = (i >> 16) & 255;
>         int i2 = (i >> 8) & 255;
>         int i3 = i & 255;
> 
>         char c0 = hex256[i0];
>         char c1 = hex256[i1];
>         char c2 = hex256[i2];
>         char c3 = hex256[i3];
> 
>         byte[] bytes;
>         if (COMPACT_STRINGS) {
>             if ((i >> 4) == 0) {
>                 bytes = new byte[1];
>                 bytes[0] = (byte) c3;
>             } else if ((i >> 8) == 0) {
>                 bytes = new byte[2];
>                 bytes[0] = (byte) (c3 >> 8);
>                 bytes[1] = (byte) c3;
>             } else if ((i >> 12) == 0) {
>                 bytes = new byte[3];
>                 bytes[0] = (byte) c2;
>                 bytes[1] = (byte) (c3 >> 8);
>                 bytes[2] = (byte) c3;
>             } else if ((i >> 16) == 0) {
>                 bytes = new byte[4];
>                 bytes[0] = (byte) (c2 >> 8);
>                 bytes[1] = (byte) c2;
>                 bytes[2] = (byte) (c3 >> 8);
>                 bytes[3] = (byte) c3;
>             } else if ((i >> 20) == 0) {
>                 bytes = new byte[5];
>                 bytes[0] = (byte) c1;
>                 bytes[1] = (byte) (c2 >> 8);
>                 bytes[2] = (byte) c2;
>                 bytes[3] = (byte) (c3 >> 8);
>                 bytes[4] = (byte) c3;
>             } else if ((i >> 24) == 0) {
>                 bytes = new byte[6];
>                 bytes[0] = (byte) (c1 >> 8);
>                 bytes[1] = (byte) c1;
>                 bytes[2] = (byte) (c2 >> 8);
>                 bytes[3] = (byte) c2;
>                 bytes[4] = (byte) (c3 >> 8);
>                 bytes[5] = (byte) c3;
>             } else if ((i >> 28) == 0) {
>                 bytes = new byte[7];
>                 bytes[0] = (byte) c0;
>                 bytes[1] = (byte) (c1 >> 8);
>                 bytes[2] = (byte) c1;
>                 bytes[3] = (byte) (c2 >> 8);
>                 bytes[4] = (byte) c2;
>                 bytes[5] = (byte) (c3 >> 8);
>                 bytes[6] = (byte) c3;
>       ...

Not sure if this can be applied but some months ago, I optimized Bits to use VarHandles rather than explicitly shifting bits around. This gave us a significant performance increase:

https://github.com/openjdk/jdk/pull/11840/files

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237075217

From liach at openjdk.org  Wed Jun 21 14:30:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 14:30:04 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily
In-Reply-To: <5uQb42QmjGtiQXy6MsepPrUWOFIViMNi9wWS92gEzN8=.a52dcf79-6b1f-485e-b4be-c8d3828578a8@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <5uQb42QmjGtiQXy6MsepPrUWOFIViMNi9wWS92gEzN8=.a52dcf79-6b1f-485e-b4be-c8d3828578a8@github.com>
Message-ID: <6LMAYRo_gj99F4LzYwcyErnCHTFrj1Em4ajCx9Sp8XA=.c2b6bd40-370e-4fe1-a5b7-dbe05e822297@github.com>

On Wed, 21 Jun 2023 14:03:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> src/java.base/share/classes/java/io/PipedOutputStream.java line 166:
> 
>> 164:     @Override
>> 165:     public synchronized void flush() throws IOException {
>> 166:         PipedInputStream sink = this.sink;
> 
> Suggestion:
> 
>         var sink = this.sink;
> 
> As seen in other methods.

On second thought, this is probably not necessary; write to the sink field is in another synchronized method, and this method is synchronized already. Is the goal here to remove the synchronized on flush?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14589#discussion_r1237103593

From duke at openjdk.org  Wed Jun 21 14:39:18 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 14:39:18 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  add annotation Stable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/8bc49c9e..a952e10c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From liach at openjdk.org  Wed Jun 21 14:39:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 Jun 2023 14:39:19 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <giul8FbzVUlryZ26tX2wCqg_GR_jgfhRZNqSRpIUKs8=.8e907e96-eedd-4704-a360-7e88ad52a530@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
 <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
 <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>
 <1i7Lw0AGawydZ16lB7vTPuY3rCnR4xIIe_aRKMlRqUY=.5bc69a6f-4e18-4d19-ba4c-7e775d457df8@github.com>
 <giul8FbzVUlryZ26tX2wCqg_GR_jgfhRZNqSRpIUKs8=.8e907e96-eedd-4704-a360-7e88ad52a530@github.com>
Message-ID: <ftr7K0MuRTz_Ob9Scar7AXD6MFKB-uMf_61tbgHpb0o=.bd648a28-9415-4393-a42a-504866adc2d4@github.com>

On Wed, 21 Jun 2023 14:13:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> > Another thing to try is moving fastUUID out of Long - moving to an array of precomputed hex values means it is not tied to Long internals anymore.
>>> 
>>> A note about `@Stable`: `Integer.digits` and `HEX256` are not, and they might see performance improvements and change the benchmark results if they are declared so.
>> 
>> use HEX256 optimize Integer.toHexString
>> https://github.com/wenshao/jdk_8310502_test/blob/main/src/main/java/com/alibaba/openjdk/HexUtils.java
>> 
>>        char[] hex256 = UUIDUtils.HEX256;
>> 
>>         int i0 = (i >> 24) & 255;
>>         int i1 = (i >> 16) & 255;
>>         int i2 = (i >> 8) & 255;
>>         int i3 = i & 255;
>> 
>>         char c0 = hex256[i0];
>>         char c1 = hex256[i1];
>>         char c2 = hex256[i2];
>>         char c3 = hex256[i3];
>> 
>>         byte[] bytes;
>>         if (COMPACT_STRINGS) {
>>             if ((i >> 4) == 0) {
>>                 bytes = new byte[1];
>>                 bytes[0] = (byte) c3;
>>             } else if ((i >> 8) == 0) {
>>                 bytes = new byte[2];
>>                 bytes[0] = (byte) (c3 >> 8);
>>                 bytes[1] = (byte) c3;
>>             } else if ((i >> 12) == 0) {
>>                 bytes = new byte[3];
>>                 bytes[0] = (byte) c2;
>>                 bytes[1] = (byte) (c3 >> 8);
>>                 bytes[2] = (byte) c3;
>>             } else if ((i >> 16) == 0) {
>>                 bytes = new byte[4];
>>                 bytes[0] = (byte) (c2 >> 8);
>>                 bytes[1] = (byte) c2;
>>                 bytes[2] = (byte) (c3 >> 8);
>>                 bytes[3] = (byte) c3;
>>             } else if ((i >> 20) == 0) {
>>                 bytes = new byte[5];
>>                 bytes[0] = (byte) c1;
>>                 bytes[1] = (byte) (c2 >> 8);
>>                 bytes[2] = (byte) c2;
>>                 bytes[3] = (byte) (c3 >> 8);
>>                 bytes[4] = (byte) c3;
>>             } else if ((i >> 24) == 0) {
>>                 bytes = new byte[6];
>>                 bytes[0] = (byte) (c1 >> 8);
>>                 bytes[1] = (byte) c1;
>>                 bytes[2] = (byte) (c2 >> 8);
>>                 bytes[3] = (byte) c2;
>>                 bytes[4] = (byte) (c3 >> 8);
>>                 bytes[5] = (byte) c3;
>>             } else if ((i >> 28) == 0) {
>>                 bytes = new byte[7];
>>                 bytes[0] = (byte) c0;
>>                 bytes[1] = (byte) (c1 >> 8);
>>                 bytes[2] = (byte) c1;
>>                 bytes[3] = (byte) (c2 >> 8);
>>         ...
>
> Not sure if this can be applied but some months ago, I optimized Bits to use VarHandles rather than explicitly shifting bits around. This gave us a significant performance increase:
> 
> https://github.com/openjdk/jdk/pull/11840/files

The key to the optimization was MethodHandles.byteArrayViewVarHandle. Don't know if StringUTF16.putChar and StringUTF16.getChar can benefit from such an update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237109343

From rriggs at openjdk.org  Wed Jun 21 14:56:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 Jun 2023 14:56:06 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>
Message-ID: <8SWfKBBDAGvyzwpGfDGA--lLRrnemrKVNE9xfdb8U2g=.f41f7d44-0f60-4215-ac9a-71267bfe990d@github.com>

On Wed, 21 Jun 2023 14:39:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add annotation Stable

src/java.base/share/classes/java/lang/Long.java line 563:

> 561:             StringUTF16.putChar(buf, 7, (byte) i3);
> 562:             StringUTF16.putChar(buf, 8, '-');
> 563:             StringUTF16.putChar(buf, 9, (byte) (i4 >> 8));

This might be cheating but you could avoid a store of 0 to the high byte (its already zero) by inlining the code from StringUTF16.putChar();  just double the index on the store of the byte.

            buf[0] = (byte) (i0 >> 8);
            buf[2] = (byte) i0;
            buf[4] = (byte) (i1 >> 8);
            buf[6] = (byte) i1;
            buf[8] = (byte) (i2 >> 8);
...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237143688

From jvernee at openjdk.org  Wed Jun 21 14:57:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 Jun 2023 14:57:06 GMT
Subject: [jdk21] Integrated: 8310053: VarHandle and slice handle derived from
 layout are lacking alignment check
In-Reply-To: <LYK1jy-ao3BRBXTgN00NwCTkSZELYCCt76qJM3hXfjo=.9a437f15-7d5e-44ff-885f-8663b5d414c5@github.com>
References: <LYK1jy-ao3BRBXTgN00NwCTkSZELYCCt76qJM3hXfjo=.9a437f15-7d5e-44ff-885f-8663b5d414c5@github.com>
Message-ID: <7u023edJ5xhfGlgiXtPAnEMfRpInCRIjr6zeAfw-Jmo=.116f63c6-60f7-4e4b-8b16-8ad03d3beffa@github.com>

On Wed, 21 Jun 2023 00:08:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [e022e876](https://github.com/openjdk/jdk/commit/e022e876543b65b531027662326f35b497861f33) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 21 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3985a4d5
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/3985a4d534a697d6ec0d61ac8cf80e5cbb55cf94
Stats:     97 lines in 4 files changed: 81 ins; 4 del; 12 mod

8310053: VarHandle and slice handle derived from layout are lacking alignment check

Reviewed-by: mcimadamore
Backport-of: e022e876543b65b531027662326f35b497861f33

-------------

PR: https://git.openjdk.org/jdk21/pull/42

From stsypanov at openjdk.org  Wed Jun 21 15:03:12 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 21 Jun 2023 15:03:12 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
Message-ID: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>

> Just a tiny clean-up to remove racy read within synchronized method

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/io/PipedOutputStream.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14589/files
  - new: https://git.openjdk.org/jdk/pull/14589/files/c97cdfc2..4c98ddce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14589&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14589&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14589.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14589/head:pull/14589

PR: https://git.openjdk.org/jdk/pull/14589

From dfuchs at openjdk.org  Wed Jun 21 15:03:13 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 Jun 2023 15:03:13 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <6LMAYRo_gj99F4LzYwcyErnCHTFrj1Em4ajCx9Sp8XA=.c2b6bd40-370e-4fe1-a5b7-dbe05e822297@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <5uQb42QmjGtiQXy6MsepPrUWOFIViMNi9wWS92gEzN8=.a52dcf79-6b1f-485e-b4be-c8d3828578a8@github.com>
 <6LMAYRo_gj99F4LzYwcyErnCHTFrj1Em4ajCx9Sp8XA=.c2b6bd40-370e-4fe1-a5b7-dbe05e822297@github.com>
Message-ID: <Jd-PqHvj7s7SuiH_Q4xXnH2HKVlLYG-SR41tbQlUry8=.66e77fdf-4ee5-47b6-8b01-b8936519e685@github.com>

On Wed, 21 Jun 2023 14:27:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/PipedOutputStream.java line 166:
>> 
>>> 164:     @Override
>>> 165:     public synchronized void flush() throws IOException {
>>> 166:         PipedInputStream sink = this.sink;
>> 
>> Suggestion:
>> 
>>         var sink = this.sink;
>> 
>> As seen in other methods.
>
> On second thought, this is probably not necessary; write to the sink field is in another synchronized method, and this method is synchronized already. Is the goal here to remove the synchronized on flush?

Good observation. Removing `synchronized` on flush might be a worthwhile goal but possible side effects (including on potential subclasses) should be carefully considered.
I support stashing `sink` in a local variable though, even if the pointer can't be concurrently modified, just to make it clear that we only have one volatile read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14589#discussion_r1237152608

From lucy at openjdk.org  Wed Jun 21 15:22:05 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 21 Jun 2023 15:22:05 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <n8JJ3yH2Oc3GZUEfGFN3zo-LOUyiDsf9UkMLHXaC8V8=.0bdb56e4-09cc-4501-a7ae-406f036e68d9@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

LGTM.
Thanks for enhancing test analysis.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491050558

From rriggs at openjdk.org  Wed Jun 21 15:24:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 Jun 2023 15:24:10 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <ftr7K0MuRTz_Ob9Scar7AXD6MFKB-uMf_61tbgHpb0o=.bd648a28-9415-4393-a42a-504866adc2d4@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
 <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
 <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>
 <1i7Lw0AGawydZ16lB7vTPuY3rCnR4xIIe_aRKMlRqUY=.5bc69a6f-4e18-4d19-ba4c-7e775d457df8@github.com>
 <giul8FbzVUlryZ26tX2wCqg_GR_jgfhRZNqSRpIUKs8=.8e907e96-eedd-4704-a360-7e88ad52a530@github.com>
 <ftr7K0MuRTz_Ob9Scar7AXD6MFKB-uMf_61tbgHpb0o=.bd648a28-9415-4393-a42a-504866adc2d4@github.com>
Message-ID: <QeA5TFXQM-ETfwDHIrcSlC5slr4ZoA4gs7djI9vSHl0=.f14dd2bf-7eea-4962-a79a-2b1ae2c1acb7@github.com>

On Wed, 21 Jun 2023 14:31:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Not sure if this can be applied but some months ago, I optimized Bits to use VarHandles rather than explicitly shifting bits around. This gave us a significant performance increase:
>> 
>> https://github.com/openjdk/jdk/pull/11840/files
>
> The key to the optimization was MethodHandles.byteArrayViewVarHandle. Don't know if StringUTF16.putChar and StringUTF16.getChar can benefit from such an update.

CDS can initialize arrays efficiently.  The Long class already uses CDS to initialize the cache of Long values.
See the LongCache code for an example of initializing from CDS with a fallback to direct initialization.
You could move the HEX256 array to the LongCache holder class and avoid any performance hit on startup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237189484

From mbaesken at openjdk.org  Wed Jun 21 15:26:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 15:26:16 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
Message-ID: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>

There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

-------------

Commit messages:
 - JDK-8310550

Changes: https://git.openjdk.org/jdk/pull/14593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310550
  Stats: 14 lines in 12 files changed: 0 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

PR: https://git.openjdk.org/jdk/pull/14593

From clanger at openjdk.org  Wed Jun 21 15:29:21 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 21 Jun 2023 15:29:21 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <P0OBubziQAeWtqlOFA7qMWjTCxZtkPgDNqD1mt2OSWk=.85ab4ce6-dc69-43c4-b32f-8e0b6b850b2b@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

I made a few review suggestions. Does the symptom happen on both, arm64 and x64?

test/lib/jdk/test/lib/Platform.java line 267:

> 265:         // Find the path to the java binary.
> 266:         String jdkPath = System.getProperty("java.home");
> 267:         Path javaPath = Paths.get(jdkPath + "/bin/java");

You could do it more concisely:

Path javaPath = Paths.get(System.getProperty("java.home") + "/bin/java");
if (Files.notExists(javaPath)) {
    throw new FileNotFoundException("Could not find file " + javaPath.toAbsolutePath().toString());

test/lib/jdk/test/lib/Platform.java line 274:

> 272: 
> 273:         // Run codesign on the java binary.
> 274:         ProcessBuilder pb = new ProcessBuilder("codesign", "--display", "--verbose", javaFileName);

And then here 'ProcessBuilder pb = new ProcessBuilder("codesign", "--display", "--verbose", javaPath.toAbsolutePath().toString());`

test/lib/jdk/test/lib/Platform.java line 277:

> 275:         pb.redirectErrorStream(true); // redirect stderr to stdout
> 276:         Process codesignProcess = pb.start();
> 277:         BufferedReader is = new BufferedReader(new InputStreamReader(codesignProcess.getInputStream()));

Maybe do the BufferedReader stuff in a try-with-resources and then return false instead of potentially throwing an IOException?

test/lib/jdk/test/lib/Platform.java line 280:

> 278:         String line;
> 279:         while ((line = is.readLine()) != null) {
> 280:             System.out.println("STDOUT: " + line);

This output is for every line seems too much. Maybe just print the lines where you find "Info.plist=not bound" or "Info.plist entries="?

test/lib/jdk/test/lib/util/CoreUtils.java line 153:

> 151:                     throw new SkippedException("Cannot produce core file with hardened binary on OSX 10.15 and later");
> 152:                 }
> 153:             } else {

Maybe you could do just one case here:
`else if (!Platform.hasPlistEntriesOSX()) {`...

-------------

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491050995
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237190071
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237190832
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237191976
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237194492
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237184922

From rriggs at openjdk.org  Wed Jun 21 15:54:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 Jun 2023 15:54:07 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <eAdM3cKHLYj8n7Fzt5C0fKDdokpupARuFfT5NI1qpRQ=.4fea0b15-7a84-4d60-9a02-725cf71a508e@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
 <eAdM3cKHLYj8n7Fzt5C0fKDdokpupARuFfT5NI1qpRQ=.4fea0b15-7a84-4d60-9a02-725cf71a508e@github.com>
Message-ID: <Lc3AP7osKvzC34PF-8-vy16c5Cj1TyKFH4yn7ZU-nhA=.4433f58c-2185-491c-9519-5250c73c9de7@github.com>

On Sun, 18 Jun 2023 20:24:07 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Use {@code xxx} to highlight the comparison against the arg.
>>    Update copyrights.
>>  - Merge branch 'master' into 8310033-time-compareto
>>  - Clarify for Duration, AbstractChronology, and Chronology
>>  - Correct javadoc of compareInstant
>>  - 8310033: Improve Instant.compareTo javadoc to mention before and after
>>    Refine timeline order to mention before and after
>>    Add javadoc @see tags to isBefore and isAfter methods
>
> src/java.base/share/classes/java/time/MonthDay.java line 678:
> 
>> 676:      *
>> 677:      * @param other  the other month-day to compare to, not null
>> 678:      * @return the comparator value is less than zero if the {@code other} is before,
> 
> Using before/after here could be confusing, as January could be considered to be before or after July (since the year is not defined).

The `isBefore` and `isAfter` methods use that terminology and Month is an enum with defined order January thru December and use the `compareTo` method to compute before/after.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14479#discussion_r1237231956

From rriggs at openjdk.org  Wed Jun 21 16:29:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 21 Jun 2023 16:29:40 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v3]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <YBcaptP9c3hy3LU_sEcojXFwMsR6rlur041f4Jbr-IQ=.5f06bb59-32c3-4151-9ab3-49fdbe03bafd@github.com>

> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
> Add javadoc @see tags to isBefore and isAfter methods
> 
> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
> The term "positive" is ambiguous, zero is considered positive and indicates equality.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Clarify return values of date time classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/cd997ede..a0acac19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=01-02

  Stats: 38 lines in 13 files changed: 6 ins; 5 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/14479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14479/head:pull/14479

PR: https://git.openjdk.org/jdk/pull/14479

From darcy at openjdk.org  Wed Jun 21 16:33:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 16:33:03 GMT
Subject: RFR: 8309853: StructuredTaskScope.join description improvements
In-Reply-To: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>
References: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>
Message-ID: <xe7_zsMWEsFx_AaubKwQMIOsos3KfAM4iDOwc23qyUo=.818c9899-4c4e-452f-ab97-1e9feae57e55@github.com>

On Mon, 12 Jun 2023 14:32:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope's class description introduces the join method as waiting for all subtasks to finish but the API docs for join/joinUntil are phrased in terms of waiting for all threads to finish. ShutdownOnXXX join/joinUntil inherit this description but would be clearer if their description said they wait until all subtasks finished or a subtask to succeed or fail.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14419#pullrequestreview-1491208534

From erikj at openjdk.org  Wed Jun 21 17:01:04 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jun 2023 17:01:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <wNaBmeQdT388fGPZljNxxG_k4sROzgMRPxAN90lq4_Q=.c3057546-4179-4745-b99b-73d740091d5b@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

The update to Java.gmk is good.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491263836

From kcr at openjdk.org  Wed Jun 21 17:13:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Jun 2023 17:13:09 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <HbsHC3E8CinoVLW0vSv5COfq8Shw35pmy3FWIlcyv2U=.ee864855-b456-4ed8-a1d6-aabd02820ef3@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

Since this Enhancement was rejected for JDK 21, this PR should be closed.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1601253343

From jiangli at openjdk.org  Wed Jun 21 17:19:06 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 Jun 2023 17:19:06 GMT
Subject: [jdk21] RFR: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <HbsHC3E8CinoVLW0vSv5COfq8Shw35pmy3FWIlcyv2U=.ee864855-b456-4ed8-a1d6-aabd02820ef3@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
 <HbsHC3E8CinoVLW0vSv5COfq8Shw35pmy3FWIlcyv2U=.ee864855-b456-4ed8-a1d6-aabd02820ef3@github.com>
Message-ID: <B5qoJt6AwrzqfvIK_DckqutqvD9PcfV-6St1jm1mkkg=.9b0ace3c-2f48-43ed-8a63-b8d22d36ee09@github.com>

On Wed, 21 Jun 2023 17:09:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Since this Enhancement was rejected for JDK 21, this PR should be closed.

Closing without integration accordingly, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/26#issuecomment-1601273074

From jiangli at openjdk.org  Wed Jun 21 17:19:07 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 21 Jun 2023 17:19:07 GMT
Subject: [jdk21] Withdrawn: 8307858: [REDO] JDK-8307194 Add make target for
 optionally building a complete set of all JDK and hotspot libjvm static
 libraries
In-Reply-To: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
References: <Bl6sMmBAKFsEqbXFv5eAuJRDpjEL70YvpAkNtW9wi-I=.b78bdc0b-b5f9-4347-af6b-03e76d28edc7@github.com>
Message-ID: <Fkl5WrrIC4tFAP3ThQCibl1ckqrEfW7I6dCGBFWyCsQ=.7e6eae76-9409-4726-9d67-077b2e82732f@github.com>

On Fri, 16 Jun 2023 20:36:07 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> 8307858: [REDO] JDK-8307194 Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk21/pull/26

From darcy at openjdk.org  Wed Jun 21 17:28:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 21 Jun 2023 17:28:03 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <n3psAbThZxm_HLA2mV3-3lBX8_atRoRzBSJCufveEi0=.c971cf60-787f-4269-b0c0-f651b22fe3b1@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
 <CJIjOczqDb2lW0K2bwOAXal462WtcDN6EFRTHP6Orww=.752d8e2e-e1da-49d5-b060-fd227d7ee8a4@github.com>
 <pRSU6nrByPhQR9cHFdRohYAL-2vpBMsf5PH4Yc3MzNM=.86694ac5-5d83-49f7-bf22-1c11d893d291@github.com>
 <n3psAbThZxm_HLA2mV3-3lBX8_atRoRzBSJCufveEi0=.c971cf60-787f-4269-b0c0-f651b22fe3b1@github.com>
Message-ID: <rphq_MlQL2R0113hDOlvM8ct7RX6lgAsC6IaCBF0-VY=.96a78550-038b-4526-ab75-db1187d8e288@github.com>

On Wed, 21 Jun 2023 13:00:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> That is, a clear connection to what's being described by that `@implSpec`.
>
> This method has an existing apiNote and implSpec. I suspect Joe meant to add this sentence to the apiNote, not the implSpec.

I did mean to add the cross-reference to Objects.toIdentityString to the implSpec section since earlier in the implSpec section the expression that is the basis for Objects.toIdentityString is listed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1237347781

From duke at openjdk.org  Wed Jun 21 19:06:06 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 21 Jun 2023 19:06:06 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <8SWfKBBDAGvyzwpGfDGA--lLRrnemrKVNE9xfdb8U2g=.f41f7d44-0f60-4215-ac9a-71267bfe990d@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>
 <8SWfKBBDAGvyzwpGfDGA--lLRrnemrKVNE9xfdb8U2g=.f41f7d44-0f60-4215-ac9a-71267bfe990d@github.com>
Message-ID: <dcqe1y-LKtelyS8Mvp1b24sgCyNz8nbAKuDQa9p3nuc=.1643d8fb-e886-40d6-8900-248f2736bef5@github.com>

On Wed, 21 Jun 2023 14:53:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add annotation Stable
>
> src/java.base/share/classes/java/lang/Long.java line 563:
> 
>> 561:             StringUTF16.putChar(buf, 7, (byte) i3);
>> 562:             StringUTF16.putChar(buf, 8, '-');
>> 563:             StringUTF16.putChar(buf, 9, (byte) (i4 >> 8));
> 
> This might be cheating but you could avoid a store of 0 to the high byte (its already zero) by inlining the code from StringUTF16.putChar();  just double the index on the store of the byte.
> 
>             buf[0] = (byte) (i0 >> 8);
>             buf[2] = (byte) i0;
>             buf[4] = (byte) (i1 >> 8);
>             buf[6] = (byte) i1;
>             buf[8] = (byte) (i2 >> 8);
> ...

Note?that `StringUTF16::putChar` takes?endian?ness into?account, so?the?above?code would?only be?correct on?half of?the?supported endian?types.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237483291

From duke at openjdk.org  Wed Jun 21 19:24:05 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 21 Jun 2023 19:24:05 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>
Message-ID: <rP2fNMhUeP9si_TwhUkBeT24cy7dJnLniDTSrHB9LnU=.7531e562-f0a5-4911-a385-ca7963f32270@github.com>

On Wed, 21 Jun 2023 14:39:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add annotation Stable

src/java.base/share/classes/java/lang/Long.java line 548:

> 546:             buf[33] = (byte) i14;
> 547:             buf[34] = (byte) (i15 >> 8);
> 548:             buf[35] = (byte) i15;

You may be able to use `jdk.internal.util.ByteArray` to simplify code and improve performance:

Suggestion:

            ByteArray.setChar(buf, 0, i0);
            ByteArray.setChar(buf, 2, i1);
            ByteArray.setChar(buf, 4, i2);
            ByteArray.setChar(buf, 6, i3);
            buf[8] = '-';
            ByteArray.setChar(buf, 9, i4);
            ByteArray.setChar(buf, 11, i5);
            buf[13] = '-';
            ByteArray.setChar(buf, 14, i6);
            ByteArray.setChar(buf, 16, i7);
            buf[18] = '-';
            ByteArray.setChar(buf, 19, i8);
            ByteArray.setChar(buf, 21, i9);
            buf[23] = '-';
            ByteArray.setChar(buf, 24, i10);
            ByteArray.setChar(buf, 26, i11);
            ByteArray.setChar(buf, 28, i12);
            ByteArray.setChar(buf, 30, i13);
            ByteArray.setChar(buf, 32, i14);
            ByteArray.setChar(buf, 34, i15);


I measured the throughput of `UUID::toString()` using JMH on my linux server (CPU: R7-5800X):


  Benchmark                 Mode  Cnt      Score     Error   Units
- UUIDUtilsBenchmark.test  thrpt    5  76117.237 ? 461.679  ops/ms
+ UUIDUtilsBenchmark.test  thrpt    5  87291.496 ? 729.527  ops/ms


The result of this benchmark test is that using `ByteArray` can improve peak throughput by nearly 15%.

Note: `ByteArray` uses `VarHandle` internally, and the impact on startup time is unknown, so more testing is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237573456

From cjplummer at openjdk.org  Wed Jun 21 19:47:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 19:47:09 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <2hTz6Ylp5KA89yQymiGug9j251kWEWeEYKL01an3gqM=.b270bd6f-0c69-4bec-8a6b-b423dc6d70d9@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Copyrights need updating.

test/lib/jdk/test/lib/Platform.java line 264:

> 262: 
> 263: 
> 264:     public static boolean hasPlistEntriesOSX() throws IOException {

Almost all of this is replicated from `isHardenedOSX()`. I wonder if there is a way to do some sharing while still maintaining separate APIs. Combining them into one API might make it harder to understand the code. Maybe a `launchCodesign()` API that returns the BufferedReader would help.

test/lib/jdk/test/lib/Platform.java line 288:

> 286:             }
> 287:         }
> 288:         return false;

Probably would be good to log that no Info.plist entry was found.

test/lib/jdk/test/lib/util/CoreUtils.java line 131:

> 129:             return coreFileLocation; // success!
> 130:         } else {
> 131:             System.out.println("Core file not found, try to find a reason for this");

Suggestion:

            System.out.println("Core file not found. Trying to find a reason why...");

-------------

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491685114
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237602062
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237587271
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237590277

From duke at openjdk.org  Wed Jun 21 20:22:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 20:22:08 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v5]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <198qa69w2KHRsk8Kb-MP6qRmRXbhSREcP1Pbt8yrSvQ=.1137bdd5-7a19-412d-8ebb-14681b4da722@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/a952e10c..c73f7ed1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=03-04

  Stats: 86 lines in 1 file changed: 7 ins; 38 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Wed Jun 21 20:27:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 20:27:08 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v6]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <W8vQrgY0S5ViwaPQqJQYTeuEl_d9i0MiF-sS1elVd4c=.f9635dc4-3d2a-4af1-8bfc-be9b8ded5538@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  import ByteOrder

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/c73f7ed1..ad53343f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Wed Jun 21 20:27:29 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 21 Jun 2023 20:27:29 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v4]
In-Reply-To: <dcqe1y-LKtelyS8Mvp1b24sgCyNz8nbAKuDQa9p3nuc=.1643d8fb-e886-40d6-8900-248f2736bef5@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <6fGM6NU4rT9A-8ndQ6K0il1V4mFJnu1d-awLMTP8ofo=.64f21573-0a01-4b71-afa8-0c8f33915619@github.com>
 <8SWfKBBDAGvyzwpGfDGA--lLRrnemrKVNE9xfdb8U2g=.f41f7d44-0f60-4215-ac9a-71267bfe990d@github.com>
 <dcqe1y-LKtelyS8Mvp1b24sgCyNz8nbAKuDQa9p3nuc=.1643d8fb-e886-40d6-8900-248f2736bef5@github.com>
Message-ID: <79Gj59hzGm_BazT6D1HEQYq9z399S08IT7TUX1O8D-w=.0d4f3f72-bab0-4411-9f42-93a844c1475f@github.com>

On Wed, 21 Jun 2023 19:02:59 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Long.java line 563:
>> 
>>> 561:             StringUTF16.putChar(buf, 7, (byte) i3);
>>> 562:             StringUTF16.putChar(buf, 8, '-');
>>> 563:             StringUTF16.putChar(buf, 9, (byte) (i4 >> 8));
>> 
>> This might be cheating but you could avoid a store of 0 to the high byte (its already zero) by inlining the code from StringUTF16.putChar();  just double the index on the store of the byte.
>> 
>>             buf[0] = (byte) (i0 >> 8);
>>             buf[2] = (byte) i0;
>>             buf[4] = (byte) (i1 >> 8);
>>             buf[6] = (byte) i1;
>>             buf[8] = (byte) (i2 >> 8);
>> ...
>
> Note?that `StringUTF16::putChar` takes?endian?ness into?account, so?the?above?code would?only be?correct on?half of?the?supported endian?types.

i have simplified the code using ENDIAN and COMPACT_STRINGS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237641739

From cjplummer at openjdk.org  Wed Jun 21 20:42:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 20:42:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <h6xqXB9Y9mE68Xmc0mgx8ILnrcukS2nxvWCaa2XCseE=.2bd1a494-ddec-4077-8ad4-28aa14f5c47f@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Copyrights need updating.

-------------

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491822264

From cjplummer at openjdk.org  Wed Jun 21 20:55:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 20:55:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <3m7KbhMvjSVURD5Yaaa2uyZj1exZbaGym0OMR6Owwuw=.588185b3-b494-4fd0-9e6d-218da1155448@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

`jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java` is failing due to the new API in Platform.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1601655977

From dcubed at openjdk.org  Wed Jun 21 21:11:15 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 21 Jun 2023 21:11:15 GMT
Subject: Integrated: 8310586: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on
 linux-all
Message-ID: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>

A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all

-------------

Commit messages:
 - 8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all

Changes: https://git.openjdk.org/jdk/pull/14606/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14606&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310586
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14606.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14606/head:pull/14606

PR: https://git.openjdk.org/jdk/pull/14606

From dholmes at openjdk.org  Wed Jun 21 21:11:16 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jun 2023 21:11:16 GMT
Subject: Integrated: 8310586: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on
 linux-all
In-Reply-To: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
References: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
Message-ID: <FuyeZBijUfWBrYmf1_LPdNRJ6Sbe9EUFVsQx_D2DssY=.8669b10d-50a9-49e6-a019-4156a1cfab22@github.com>

On Wed, 21 Jun 2023 20:59:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14606#pullrequestreview-1491869387

From mikael at openjdk.org  Wed Jun 21 21:11:16 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 21 Jun 2023 21:11:16 GMT
Subject: Integrated: 8310586: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on
 linux-all
In-Reply-To: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
References: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
Message-ID: <vn-6LO4Mkpi5vv8sPbecqjIjVrqu12QJOVHHy8MWVBg=.f9854b5b-5d72-4f08-904a-638254b4811b@github.com>

On Wed, 21 Jun 2023 20:59:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all

Marked as reviewed by mikael (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14606#pullrequestreview-1491873353

From dcubed at openjdk.org  Wed Jun 21 21:11:17 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 21 Jun 2023 21:11:17 GMT
Subject: Integrated: 8310586: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on
 linux-all
In-Reply-To: <FuyeZBijUfWBrYmf1_LPdNRJ6Sbe9EUFVsQx_D2DssY=.8669b10d-50a9-49e6-a019-4156a1cfab22@github.com>
References: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
 <FuyeZBijUfWBrYmf1_LPdNRJ6Sbe9EUFVsQx_D2DssY=.8669b10d-50a9-49e6-a019-4156a1cfab22@github.com>
Message-ID: <qfhsq4NwXTMjvloFnm0-GrcPg1_xJBBaKr9TCTZf_64=.fd175396-7e2e-4fb4-81f6-2ae069d7c6b8@github.com>

On Wed, 21 Jun 2023 21:02:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the lightning fast review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14606#issuecomment-1601676432

From dcubed at openjdk.org  Wed Jun 21 21:11:18 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 21 Jun 2023 21:11:18 GMT
Subject: Integrated: 8310586: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on
 linux-all
In-Reply-To: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
References: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
Message-ID: <_sHC3DDUBvTIQ-xEYHP0OQKftMNA6WphBHLmTRLzKqs=.8d408f0b-ff9b-477f-8671-b177cf3b4b11@github.com>

On Wed, 21 Jun 2023 20:59:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all

This pull request has now been integrated.

Changeset: ac44ef19
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac44ef19d5a129c41a8e89e667a28cff38acdd42
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8310586: ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all

Reviewed-by: dholmes, mikael

-------------

PR: https://git.openjdk.org/jdk/pull/14606

From dcubed at openjdk.org  Wed Jun 21 21:18:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 21 Jun 2023 21:18:10 GMT
Subject: Integrated: 8310586: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on
 linux-all
In-Reply-To: <vn-6LO4Mkpi5vv8sPbecqjIjVrqu12QJOVHHy8MWVBg=.f9854b5b-5d72-4f08-904a-638254b4811b@github.com>
References: <iVjQUatmlUbz1bEu7247hJOz181E78nhhIn7wK0XUyw=.edf81245-bbaa-4643-9833-fc60e020ce43@github.com>
 <vn-6LO4Mkpi5vv8sPbecqjIjVrqu12QJOVHHy8MWVBg=.f9854b5b-5d72-4f08-904a-638254b4811b@github.com>
Message-ID: <euquHvOWh8LzLsj1-EJLV9qDt5K4xL7slXs4s1PdCzA=.135cf102-019c-4b7c-9ce6-588f2f91cee6@github.com>

On Wed, 21 Jun 2023 21:05:11 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java#default with virtual threads on linux-all
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for your review also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14606#issuecomment-1601686797

From dholmes at openjdk.org  Wed Jun 21 21:51:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jun 2023 21:51:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Mostly seems okay - a couple of things need further adjusting I think.

Thanks.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:

> 194: 
> 195:     /**
> 196:      * Set whether or not to use ct.sym as an alternate

As an alternate to what? This needs something else.

test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:

> 1: /*

The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491961660
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237747922
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237749197

From mchung at openjdk.org  Wed Jun 21 22:02:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 21 Jun 2023 22:02:16 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v6]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request with a new target base 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:

 - improve the specification of forName
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
 - Review comment.  Add a test
 - missing 'L' for the array class name
 - review comment
 - Clarify for an array class of primitive type
 - 8310242: Clarify the name parameter to Class::forName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/a75542ff..39e218ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=04-05

  Stats: 9202 lines in 408 files changed: 4713 ins; 1982 del; 2507 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Wed Jun 21 22:18:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 21 Jun 2023 22:18:07 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v6]
In-Reply-To: <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
Message-ID: <MXmp7zIVoEeP42lMza9nkKEjCBfbCtiWWnzELGgV8lg=.61f6d43b-0122-43ee-99d3-c3569723eb78@github.com>

On Wed, 21 Jun 2023 22:02:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request with a new target base 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:
> 
>  - improve the specification of forName
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>  - Review comment.  Add a test
>  - missing 'L' for the array class name
>  - review comment
>  - Clarify for an array class of primitive type
>  - 8310242: Clarify the name parameter to Class::forName

I improved the spec of `forName` to make it clear of the name for nested types and array types.   It now refers to the table in `getName` about the name of an array class.   

@dholmes-ora does that clarify and address the concerns you had?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14528#issuecomment-1601750566

From tprinzing at openjdk.org  Wed Jun 21 22:46:20 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 21 Jun 2023 22:46:20 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror events
Message-ID: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>

The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.

JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.

In the java.base module:
Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.

In the jdk.jfr module:
jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.

The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
Passed: jdk/jfr/event/io/TestSocketEvents.java

I added a micro benchmark which measures the overhead of handling the jfr socket events.
test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

-------------

Commit messages:
 - some changes from review.
 - fix copyright date
 - Added micro benchmark to measure socket event overhead.
 - Some changes from review.
 - remove unnecessary cast
 - 8308995: Update Network IO JFR events to be static mirror events

Changes: https://git.openjdk.org/jdk/pull/14342/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308995
  Stats: 896 lines in 12 files changed: 523 ins; 367 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

PR: https://git.openjdk.org/jdk/pull/14342

From alanb at openjdk.org  Wed Jun 21 22:46:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 22:46:24 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <Szmpu-UifvnljGMg0Ddt5StvwPNujRsuzDzMjA6DVHw=.0e63f68a-b86f-48c7-99e4-6efad007d33e@github.com>

On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

src/java.base/share/classes/java/net/Socket.java line 43:

> 41: import java.util.Collections;
> 42: 
> 43: import jdk.internal.event.SocketWriteEvent;

You'll probably want to clean up the imports to avoid having import of jdk.internal classes in two places.

src/java.base/share/classes/java/net/Socket.java line 1109:

> 1107:                 nbytes = read0(b, off, len);
> 1108:             } finally {
> 1109:                 SocketReadEvent.checkForCommit(start, nbytes, parent.getRemoteSocketAddress(), parent.getSoTimeout());

So if read throws, this will commit a jdk.SocketReadEvent with size 0, maybe this will change later to include the exception?

src/java.base/share/classes/java/net/Socket.java line 1114:

> 1112:         }
> 1113: 
> 1114:         private int read0(byte[] b, int off, int len) throws IOException {

Can you rename this to implRead?

src/java.base/share/classes/java/net/Socket.java line 1215:

> 1213:                 return;
> 1214:             }
> 1215:             int bytesWritten = 0;

Is bytesWritten needed?

src/java.base/share/classes/java/net/Socket.java line 1226:

> 1224:         }
> 1225: 
> 1226:         public void write0(byte[] b, int off, int len) throws IOException {

Can you change this to be private and rename to implWrite?

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 421:

> 419:     }
> 420: 
> 421:     private int read0(ByteBuffer buf) throws IOException {

Can you rename this to implRead too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236731407
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237226982
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719052
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719603
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1236719373
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237227861

From smarks at openjdk.org  Wed Jun 21 22:46:25 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 21 Jun 2023 22:46:25 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <Szmpu-UifvnljGMg0Ddt5StvwPNujRsuzDzMjA6DVHw=.0e63f68a-b86f-48c7-99e4-6efad007d33e@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <Szmpu-UifvnljGMg0Ddt5StvwPNujRsuzDzMjA6DVHw=.0e63f68a-b86f-48c7-99e4-6efad007d33e@github.com>
Message-ID: <qhyGzFtKzmYdEbw419YCyVmc7Orrd1_fqNkkjijR-I8=.491b698d-2d20-4b0a-96ac-64de7d3d9314@github.com>

On Wed, 21 Jun 2023 09:46:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> src/java.base/share/classes/java/net/Socket.java line 1114:
> 
>> 1112:         }
>> 1113: 
>> 1114:         private int read0(byte[] b, int off, int len) throws IOException {
> 
> Can you rename this to implRead?

Are we using a convention of `implRead` or `readImpl`? Either is ok with me, but I think we had been using `readImpl` and similar elsewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237316630

From alanb at openjdk.org  Wed Jun 21 22:46:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 22:46:25 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <qhyGzFtKzmYdEbw419YCyVmc7Orrd1_fqNkkjijR-I8=.491b698d-2d20-4b0a-96ac-64de7d3d9314@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <Szmpu-UifvnljGMg0Ddt5StvwPNujRsuzDzMjA6DVHw=.0e63f68a-b86f-48c7-99e4-6efad007d33e@github.com>
 <qhyGzFtKzmYdEbw419YCyVmc7Orrd1_fqNkkjijR-I8=.491b698d-2d20-4b0a-96ac-64de7d3d9314@github.com>
Message-ID: <mfjQaMPuvGwylY4FlUGw1MD-vWVHkV5M5VofIrhOhMs=.c66d7a2e-424a-4497-93d6-b98982bc2492@github.com>

On Wed, 21 Jun 2023 16:59:22 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Are we using a convention of `implRead` or `readImpl`? Either is ok with me, but I think we had been using `readImpl` and similar elsewhere.

This code is already using implXXX so it's just be consistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1237319486

From jvernee at openjdk.org  Wed Jun 21 23:33:38 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 Jun 2023 23:33:38 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v2]
In-Reply-To: <0mgcbnkWISnn5-eS8ifzc7fx9xfkQArVTWmvchSDtL0=.60770424-7252-4617-93c6-b708d801ce2a@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <Gj2OCyr4Gqzt8n4aynUHdIrERgxSLYpionyI8x0NGfU=.260ad239-bed4-4889-a9e8-97a1c12b42c3@github.com>
 <rmhmXFegRs0mjdRB5qVTtdkV6H9N008Hmoy9LXhDK1Y=.57c1dc9a-09bc-463c-9c84-a85e3d8dc4da@github.com>
 <IabUu8RcOrO1LsZko6Tm1j3X3vknyhbSxIncgCuHw7c=.b432a006-d7a0-400b-9b5f-024b8e2465a5@github.com>
 <0mgcbnkWISnn5-eS8ifzc7fx9xfkQArVTWmvchSDtL0=.60770424-7252-4617-93c6-b708d801ce2a@github.com>
Message-ID: <sFXcn6LJN5y3b6gIzrc8pVyCS8wla58zM6juROjMSIw=.f34ffd62-1514-46ff-a9f6-789ac3384b47@github.com>

On Wed, 21 Jun 2023 07:34:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Possible suggestion/thing to try: use a bullet list to spell out all cases for `index`. E.g. we know there's index == 0 (all variadic). Then we know there's index = N (no variadic). Then there's index == m, 0 < m < N - which means layouts 0..m are non-variadic and m..N are variadic (where n..m denotes an interval with n included and m excluded).
>
>> Possible suggestion/thing to try: use a bullet list to spell out all cases for `index`. E.g. we know there's index == 0 (all variadic). Then we know there's index = N (no variadic). Then there's index == m, 0 < m < N - which means layouts 0..m are non-variadic and m..N are variadic (where n..m denotes an interval with n included and m excluded).
> 
> I think this is a good suggestion. It makes it much easier to understand.

Thanks for the review.

I've added a bullet list, and switch same of the language to refer to the 'start of the variadic arguments passed to the function described by the function descriptor'. I think the latter avoids implying the index is an index into the argument layouts, but it feels like a bit of a mouthful (any suggestions?). I've also added a small note to the global variadic function doc to indicate that the index might not necessarily have a corresponding argument layout.

How does the new version look?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1237819366

From jvernee at openjdk.org  Wed Jun 21 23:33:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 21 Jun 2023 23:33:37 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v2]
In-Reply-To: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
Message-ID: <RIMeNZVOoqhIfP0DdA9RhEr7aoBb2UFVf86XfmcxCUo=.1501b11d-62a8-4031-bf8e-0158b646ce89@github.com>

> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  polish doc, review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14565/files
  - new: https://git.openjdk.org/jdk/pull/14565/files/24bf486f..f6a111b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14565&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14565&range=00-01

  Stats: 17 lines in 1 file changed: 5 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14565/head:pull/14565

PR: https://git.openjdk.org/jdk/pull/14565

From duke at openjdk.org  Thu Jun 22 00:13:06 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 00:13:06 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v7]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  move HEX256 to LongCache

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/ad53343f..e0bcf6cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=05-06

  Stats: 54 lines in 1 file changed: 11 ins; 42 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Thu Jun 22 00:13:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 00:13:07 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v7]
In-Reply-To: <QeA5TFXQM-ETfwDHIrcSlC5slr4ZoA4gs7djI9vSHl0=.f14dd2bf-7eea-4962-a79a-2b1ae2c1acb7@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <GTfcBUXye_cENwXx_szpkEWLQr87NUzpxtp1pSF4fbc=.d170b26a-e908-487a-9679-6e3d0118eba4@github.com>
 <hQX7IMF9hKigsyTDEfGRMTzuRe6CpoRMa0axryUjkng=.e25cac9b-976c-4899-9ea0-df558fa16e03@github.com>
 <jlubClyZez3WjTEoAfA6E-v-PZKQj2Y3YTrKC6IyY0A=.f50b6f02-a88a-4542-a75e-7fff0e723b40@github.com>
 <1i7Lw0AGawydZ16lB7vTPuY3rCnR4xIIe_aRKMlRqUY=.5bc69a6f-4e18-4d19-ba4c-7e775d457df8@github.com>
 <giul8FbzVUlryZ26tX2wCqg_GR_jgfhRZNqSRpIUKs8=.8e907e96-eedd-4704-a360-7e88ad52a530@github.com>
 <ftr7K0MuRTz_Ob9Scar7AXD6MFKB-uMf_61tbgHpb0o=.bd648a28-9415-4393-a42a-504866adc2d4@github.com>
 <QeA5TFXQM-ETfwDHIrcSlC5slr4ZoA4gs7djI9vSHl0=.f14dd2bf-7eea-4962-a79a-2b1ae2c1acb7@github.com>
Message-ID: <PS5t-hqpzzUDRXO2sYa47YgNI-RxvCCpcyuLSILfBLA=.3fd2844a-aacf-464b-8ade-9f8cec9b41ee@github.com>

On Wed, 21 Jun 2023 15:21:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> CDS can initialize arrays efficiently. The Long class already uses CDS to initialize the cache of Long values. See the LongCache code for an example of initializing from CDS with a fallback to direct initialization. You could move the HEX256 array to the LongCache holder class and avoid any performance hit on startup.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237840813

From dholmes at openjdk.org  Thu Jun 22 00:24:11 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Jun 2023 00:24:11 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v6]
In-Reply-To: <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
Message-ID: <51Ay_D5vknJgIa5tuzL9jDXWHMan5Y021LvQpG_-NSU=.9e2f2c12-971d-487f-ae2b-c70bf73f48e0@github.com>

On Wed, 21 Jun 2023 22:02:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request with a new target base 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:
> 
>  - improve the specification of forName
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>  - Review comment.  Add a test
>  - missing 'L' for the array class name
>  - review comment
>  - Clarify for an array class of primitive type
>  - 8310242: Clarify the name parameter to Class::forName

A few small suggestions, otherwise looks good.

Thanks.

src/java.base/share/classes/java/lang/Class.java line 444:

> 442:      * <p> To obtain {@code Class} object associated with an array class,
> 443:      * the name consists of one or more {@code '['} representing the depth
> 444:      * of the array class, followed by the element type as encoded in

Suggestion

+     * <p> To obtain the {@code Class} object associated with an array class,
+     * the name consists of one or more {@code '['} representing the depth
+     * of the array nesting, followed by the element type as encoded in

src/java.base/share/classes/java/lang/Class.java line 451:

> 449:      * Class<?> threadClass = Class.forName("java.lang.Thread", false, currentLoader);
> 450:      * Class<?> stringArrayClass = Class.forName("[Ljava.lang.String;", false, currentLoader);
> 451:      * Class<?> intArrayClass = Class.forName("[[[I", false, currentLoader);

The variable name doesn't match the actual class loaded. It might be clearer to add a trailing comment `// Class of int[][][]` ?

test/jdk/java/lang/Class/forName/ForNameNames.java line 52:

> 50:     @ParameterizedTest
> 51:     @MethodSource("testCases")
> 52:     void testForName(String cn, Class<?> expected) throws ClassNotFoundException {

Should this also test that `c.getName().equals(cn)`?

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1492109276
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237843279
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237843986
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237846267

From duke at openjdk.org  Thu Jun 22 00:25:04 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 00:25:04 GMT
Subject: RFR: 8310502 : optimization for UUID#toString [v3]
In-Reply-To: <hvZtu2hjLgVeJemUoLduxZ1ngXqXyLhjkbBiTZyiuyY=.6bc410cb-bbb9-440b-aded-1774af61708b@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SGDgNC7WpdFADu8WrNLBpOtvVtQHd3bE8x7kC7iQgV0=.d63801a4-58ab-4105-8809-fc465302da08@github.com>
 <hvZtu2hjLgVeJemUoLduxZ1ngXqXyLhjkbBiTZyiuyY=.6bc410cb-bbb9-440b-aded-1774af61708b@github.com>
Message-ID: <kiCc34rFUwcBHIB2rlILRDi2jaBoAx0DSBSeypgw79g=.bfa67cd2-c3d6-47c0-ad39-479e7bf17170@github.com>

On Wed, 21 Jun 2023 13:32:32 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8310502 : hex literal
>
> * benchmark code
> https://github.com/wenshao/jdk_8310502_test/blob/main/src/main/java/com/alibaba/openjdk/UUIDUtilsBenchmark.java
> 
> 
> git clone https://github.com/wenshao/jdk_8310502_test
> cd jdk_8310502_test
> mvn clean package -Dmaven.test.skip
> java -cp target/jdk_8310502_benchmark.jar com.alibaba.openjdk.UUIDUtilsBenchmark
> 
> 
> * benchmark result on Apple MacBook M1 Max
> 
> Benchmark                 Mode  Cnt       Score       Error   Units
> UUIDUtilsBenchmark.fast  thrpt    5  701840.078 ? 57597.624  ops/ms
> UUIDUtilsBenchmark.jdk   thrpt    5  246409.000 ? 84564.009  ops/ms
> 
> 
> * benchmark result on [ecs.c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> 
> Benchmark                 Mode  Cnt       Score      Error   Units
> UUIDUtilsBenchmark.fast  thrpt    5  131595.572 ? 7383.223  ops/ms
> UUIDUtilsBenchmark.jdk   thrpt    5  129610.735 ?  455.752  ops/ms
> 
> 
> * benchmark result on [ecs.c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> 
> Benchmark                 Mode  Cnt       Score      Error   Units
> UUIDUtilsBenchmark.fast  thrpt    5  129445.610 ? 1846.775  ops/ms
> UUIDUtilsBenchmark.jdk   thrpt    5  104651.872 ? 1005.977  ops/ms

> @wenshao Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information.

got it

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1601851348

From darcy at openjdk.org  Thu Jun 22 00:25:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Jun 2023 00:25:10 GMT
Subject: RFR: JDK-8310571: Use inline @return tag on java.util.Objects
Message-ID: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>

Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

-------------

Commit messages:
 - JDK-8310571: Use inline @return tag on java.util.Objects

Changes: https://git.openjdk.org/jdk/pull/14608/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14608&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310571
  Stats: 41 lines in 1 file changed: 0 ins; 21 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14608/head:pull/14608

PR: https://git.openjdk.org/jdk/pull/14608

From mchung at openjdk.org  Thu Jun 22 00:33:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Jun 2023 00:33:33 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v7]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/39e218ea..852bd774

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=05-06

  Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From liach at openjdk.org  Thu Jun 22 00:50:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 00:50:42 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <NAOSeEKmJ7ozFSC1y6a2xxlr19eLjCaM-db6ioZAhoI=.e4512a3c-6ff0-4805-ae76-af7703916835@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html

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 ten additional commits since the last revision:

 - Review and updates for 8310242
 - Merge branch 'master' into fix/descstring-spec
 - Update the note for getName
 - Convert the note in fromDescriptorString to apiNote
 - Address the other two review comments
 - Merge branch 'fix/descstring-spec' of https://github.com/liachmodded/jdk into fix/descstring-spec
 - Update src/java.base/share/classes/java/lang/Class.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Merge branch 'master' into fix/descstring-spec
 - 8309819: Fix specification about descriptor inverses in Class and MethodTypeDesc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/ff26c099..bf17845e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=04-05

  Stats: 15010 lines in 685 files changed: 8365 ins; 3131 del; 3514 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Thu Jun 22 00:54:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 00:54:20 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v7]
In-Reply-To: <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
Message-ID: <D7w78I3nlSlnrWI6OmXLVaHECego-zfbfm42GLI6lEU=.27ca6641-a0e9-4873-a37b-e44afa659993@github.com>

On Thu, 22 Jun 2023 00:33:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

src/java.base/share/classes/java/lang/Class.java line 426:

> 424:     /**
> 425:      * Returns the {@code Class} object associated with the class or
> 426:      * interface with the given string name, using the given class loader.

Should we update the summary to `... associated with the class or interface or array with the given string name...`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237860510

From liach at openjdk.org  Thu Jun 22 00:54:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 00:54:25 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v6]
In-Reply-To: <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
Message-ID: <a8MDLIt_HiknKx72-aVZTB8cG3mqGO1C9AQhVY4Q3UM=.ae625725-b5b2-4172-9388-b1d5780c2192@github.com>

On Wed, 21 Jun 2023 22:02:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request with a new target base 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:
> 
>  - improve the specification of forName
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>  - Review comment.  Add a test
>  - missing 'L' for the array class name
>  - review comment
>  - Clarify for an array class of primitive type
>  - 8310242: Clarify the name parameter to Class::forName

src/java.base/share/classes/java/lang/Class.java line 438:

> 436:      * representing primitive types or void, hidden classes or interfaces,
> 437:      * or array classes whose element type is a hidden class or interface.
> 438:      * If {@code name} denotes a primitive type or void, for example {@code I},

I think `{@code int}` would be a better example here as Java programmers aren't in touch with bytecode descriptors mostly.

src/java.base/share/classes/java/lang/Class.java line 459:

> 457:      * from {@code forName(}<i>N</i>{@code )} returns <i>N</i>.
> 458:      *
> 459:      * <p> A call to {@code forName("[L}<i>N</i>{@code ;")} causes the element type

This appears true for multi-dimensional arrays as well, but the name format here only applies to single-dimension arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237808121
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237809409

From smarks at openjdk.org  Thu Jun 22 00:56:03 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Jun 2023 00:56:03 GMT
Subject: RFR: JDK-8310571: Use inline @return tag on java.util.Objects
In-Reply-To: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
References: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
Message-ID: <7yv6Pz6q0i-hgmbS09oK3tgYu9rTCUwGh50cb-KVTL0=.40bf25e0-b33f-4041-9e7c-2d1943b0a851@github.com>

On Thu, 22 Jun 2023 00:19:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

Looks good. I had to refresh my understanding of the exact behavior of the inline `@return` tag:

https://docs.oracle.com/en/java/javase/17/docs/specs/javadoc/doc-comment-spec.html

(search for `{@return`)

It adds a leading "Returns " and a trailing "." to the block's text, and inserts a "Returns" section in the proper place. This seems oddly specific, but it's tailored for this exact use case. Anyway, good cleanup.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14608#pullrequestreview-1492140246

From rriggs at openjdk.org  Thu Jun 22 01:06:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 01:06:03 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
Message-ID: <GhN0RRFdc8N1VHtMdkKNeTPoipQyfBe7zBzRV_O6-PI=.bdc5fee4-e390-43c9-ad2a-838ee9aa1596@github.com>

On Thu, 22 Jun 2023 00:13:06 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HEX256 to LongCache

fyi, the title of this PR need to match exactly the title of the bug [JDK-8310502](https://bugs.openjdk.org/browse/JDK-8310502).
The mismatch is an Integration blocker. (See the comment in the description).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1601874909

From duke at openjdk.org  Thu Jun 22 01:11:03 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 01:11:03 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <GhN0RRFdc8N1VHtMdkKNeTPoipQyfBe7zBzRV_O6-PI=.bdc5fee4-e390-43c9-ad2a-838ee9aa1596@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
 <GhN0RRFdc8N1VHtMdkKNeTPoipQyfBe7zBzRV_O6-PI=.bdc5fee4-e390-43c9-ad2a-838ee9aa1596@github.com>
Message-ID: <rzXwj6BppxqkPWZ4PnwUrKHE1aS0ap-GLUXmXGqHaJk=.5e157242-f684-4994-a953-26a455fb484e@github.com>

On Thu, 22 Jun 2023 01:03:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fyi, the title of this PR need to match exactly the title of the bug [JDK-8310502](https://bugs.openjdk.org/browse/JDK-8310502). The mismatch is an Integration blocker. (See the comment in the description).

i have made the changes. is it ok now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1601878855

From jlu at openjdk.org  Thu Jun 22 01:16:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 01:16:33 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit
Message-ID: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>

Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.

If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).

Below is a list of all the changes,

- Refactor Bug4316602.java as LocaleConstructors.java
- Refactor Bug4210525.java as CaseCheckVariant.java
- Refactor bug6277243.java as RootLocale.java
- Refactor bug6312358.java as GetInstanceCheck.java
- Refactor Bug8154797.java as CompareProviderFormats.java
- Refactor Bug8004240.java as GetAdapterPreference.java
- Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

-------------

Commit messages:
 - Minor cleanup to various files
 - Refactor Bug8004240.java as GetAdapterPreference.java
 - Revert "Rename bug4123285.java as LocalesInApplet.java + minor cleanup, do not refactor to junit as depends on Applet"
 - Typo in CompareProviderFormats.java
 - Refactor Bug8154797.java as CompareProviderFormats.java
 - Rename bug4123285.java as LocalesInApplet.java + minor cleanup, do not refactor to junit as depends on Applet
 - Refactor bug6312358.java as GetInstanceCheck.java
 - Refactor bug6277243.java as RootLocale.java
 - Case of vars in LocaleConstructors.java
 - Refactor Bug4210525 as CaseCheckVariant
 - ... and 4 more: https://git.openjdk.org/jdk/compare/3e0bbd29...02252fb5

Changes: https://git.openjdk.org/jdk/pull/14609/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310234
  Stats: 1104 lines in 15 files changed: 597 ins; 507 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14609/head:pull/14609

PR: https://git.openjdk.org/jdk/pull/14609

From rriggs at openjdk.org  Thu Jun 22 01:19:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 01:19:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
Message-ID: <1S_jVwNMnksRkDywelHPnC_HQYkqLPJ5ChQwB0rtLmE=.652f3843-0b2e-47d9-8a17-9e8509efdc6d@github.com>

On Thu, 22 Jun 2023 00:13:06 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HEX256 to LongCache

The Bots have removed the warning so the titles match.
Please wait 24hrs to integrate to give anyone who has commented a chance to review and approve.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1601884222

From liach at openjdk.org  Thu Jun 22 01:25:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 01:25:05 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v5]
In-Reply-To: <NAiKaSRp9x6W1wdPLG5ylvB584Su1cCjEQp_zLeSU_s=.400931f3-6c80-4961-8f68-fde17e9dedf6@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <aCcnckfyhhGbpsJxgJZHJ0Ot5l7hZ-tgoedbDwwHspY=.b44cb4f2-00bf-4508-b6ca-90891602c026@github.com>
 <NAiKaSRp9x6W1wdPLG5ylvB584Su1cCjEQp_zLeSU_s=.400931f3-6c80-4961-8f68-fde17e9dedf6@github.com>
Message-ID: <Q4SqrXYPIfJYwgoC706aCfdHUfuSqtnhNW1lbUW-LnI=.e772540d-354e-4259-be7c-1d36650092b4@github.com>

On Thu, 15 Jun 2023 10:01:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the note for getName
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1233:
> 
>> 1231:      * (JVMS {@jvms 4.3.3}) and a suitable class loader argument. Two distinct
>> 1232:      * classes which share a common name but have different class loaders will
>> 1233:      * appear identical when viewed within descriptor strings.
> 
> "will appear identical when viewed within descriptor strings".  Would it be clearer to say that have equal descriptor strings?

How about this:
"A method type produced by changing a component type to a distinct class with the same name but a different class loader will have the same descriptor string"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1237878347

From liach at openjdk.org  Thu Jun 22 01:38:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 01:38:05 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v7]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. Class::getName was a partial inverse instead.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct classloaders.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/04/java.base/java/lang/invoke/MethodType.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Missed recommendations from Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/bf17845e..be3e8cd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=05-06

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Thu Jun 22 02:06:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 02:06:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
Message-ID: <-V1YfQANHNEdlooDsi0aMyQ1dIZ43zOSPHzb3OGHtDI=.4951a08f-8cfc-4948-94e5-8b09380f8e0c@github.com>

On Thu, 22 Jun 2023 00:13:06 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HEX256 to LongCache

Changes requested by liach (Author).

About @Glavo's VH suggestion: I think it is feasible, since the VH field is not initialized until the method is used, so there should be no startup issue. 

On a side note, JDK itself has a `UUIDBench` that benchmarks toString as well: can run it with `make test TEST="micro:java.util.UUIDBench.toString"` once the configuration has JMH set up, which I will be using (against master and this patch)

src/java.base/share/classes/java/lang/Long.java line 484:

> 482: 
> 483:         buf[off] = (byte) (i >> 8);
> 484:         buf[1 * charSize + off] = (byte) i;

Suggestion:

        buf[off] = (byte) (i0 >> 8);
        buf[1 * charSize + off] = (byte) i0;

Doesn't compile on my end

-------------

PR Review: https://git.openjdk.org/jdk/pull/14578#pullrequestreview-1492220846
PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1601915404
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1237906554

From mchung at openjdk.org  Thu Jun 22 02:06:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Jun 2023 02:06:11 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v6]
In-Reply-To: <a8MDLIt_HiknKx72-aVZTB8cG3mqGO1C9AQhVY4Q3UM=.ae625725-b5b2-4172-9388-b1d5780c2192@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <T52CY6_XSGKCv9ZdR8-YiG6NViZzZnzSyUiVuQKu0OQ=.c9a92d79-b2f6-45d5-befb-f4e1c9981c84@github.com>
 <a8MDLIt_HiknKx72-aVZTB8cG3mqGO1C9AQhVY4Q3UM=.ae625725-b5b2-4172-9388-b1d5780c2192@github.com>
Message-ID: <TMbzhA9Y4ltJ_k6DrK_mcy81iC_450_dwHAvuMHcrKY=.107ac218-34f2-4f6b-b370-33924d8e08cf@github.com>

On Wed, 21 Jun 2023 23:06:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request with a new target base 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:
>> 
>>  - improve the specification of forName
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8310242
>>  - Review comment.  Add a test
>>  - missing 'L' for the array class name
>>  - review comment
>>  - Clarify for an array class of primitive type
>>  - 8310242: Clarify the name parameter to Class::forName
>
> src/java.base/share/classes/java/lang/Class.java line 438:
> 
>> 436:      * representing primitive types or void, hidden classes or interfaces,
>> 437:      * or array classes whose element type is a hidden class or interface.
>> 438:      * If {@code name} denotes a primitive type or void, for example {@code I},
> 
> I think `{@code int}` would be a better example here as Java programmers aren't in touch with bytecode descriptors mostly.

One main point for this example to show is that it will find a class in unnamed package named `I` - a class named `I` is not uncommon but it's unlikely to have a class named `int`.

> src/java.base/share/classes/java/lang/Class.java line 459:
> 
>> 457:      * from {@code forName(}<i>N</i>{@code )} returns <i>N</i>.
>> 458:      *
>> 459:      * <p> A call to {@code forName("[L}<i>N</i>{@code ;")} causes the element type
> 
> This appears true for multi-dimensional arrays as well, but the name format here only applies to single-dimension arrays.

I considered that.   The spec and the example already describe multi-dimensional array.  I think one can infer from this single-dimensional array example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237904930
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237906383

From dholmes at openjdk.org  Thu Jun 22 02:12:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Jun 2023 02:12:06 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v7]
In-Reply-To: <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
Message-ID: <LV4ne7F1qU4xYq2yX7mntxRKNnke9t-TXptuXGzqeUQ=.44421e57-9046-4262-8b99-492623b43251@github.com>

On Thu, 22 Jun 2023 00:33:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

src/java.base/share/classes/java/lang/Class.java line 442:

> 440:      * whose name is {@code I} instead.
> 441:      *
> 442:      * <p> To obtain {@code Class} object associated with an array class,

To obtain _the_ Class object ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1237907917

From jwaters at openjdk.org  Thu Jun 22 02:55:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 02:55:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v5]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <puZ5zP_vpuAUhgolvMXTnk4BR4mSfe0w4eXhbTYkz98=.008a0d4b-8e8a-421c-904a-15be855f378f@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert NULL to nullptr changes in jaccesswalker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/5fa2d3eb..9a8a9158

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From jwaters at openjdk.org  Thu Jun 22 03:00:16 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 03:00:16 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters 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:

  Revert NULL to nullptr changes in jaccesswalker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/9a8a9158..a31e52e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From liach at openjdk.org  Thu Jun 22 03:09:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 03:09:04 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
Message-ID: <8hQUUbiOn0USetmA2JdU0-PT5A4zmn6IsIRjxrld3Ss=.268ea4ed-de84-4916-8ddd-92ab56f17894@github.com>

On Thu, 22 Jun 2023 00:13:06 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HEX256 to LongCache

I've tested the benchmarks and the patch and baseline (with extra stable annotation) with a slightly varied version suitable for gradle run:


package com.alibaba.openjdk;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
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.Warmup;
import org.openjdk.jmh.infra.Blackhole;

import java.util.UUID;
import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.Throughput)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 3, time = 10)
@Measurement(iterations = 6, time = 5)
@Fork(1)
public class UUIDUtilsBenchmark {
    public static UUID uuid = UUID.randomUUID();

    @Benchmark
    public void jdk(Blackhole bh) {
        bh.consume(uuid.toString());
    }

    @Benchmark
    public void fast(Blackhole bh) {
        bh.consume(UUIDUtils.fastUUID(uuid));
    }
}

The throughput varies a lot between iterations somehow; the patch and baseline with stable has no significant difference (i.e. within the error range, about 10%)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1601953110

From alanb at openjdk.org  Thu Jun 22 04:32:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 04:32:11 GMT
Subject: Integrated: 8309853: StructuredTaskScope.join description improvements
In-Reply-To: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>
References: <lwnVIrWWAF9DKPE-rNVfxHZsnjmJCjvW6naOoPKLLT4=.a4205319-3cdf-4914-a860-3a4c9b051c77@github.com>
Message-ID: <_8Gw7SVB0xmV2o7g-gIMQ6U8UNZmT1wYvS6J_HCYMgw=.5b649bb7-7009-4854-b12a-323b7b6c71d8@github.com>

On Mon, 12 Jun 2023 14:32:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> StructuredTaskScope's class description introduces the join method as waiting for all subtasks to finish but the API docs for join/joinUntil are phrased in terms of waiting for all threads to finish. ShutdownOnXXX join/joinUntil inherit this description but would be clearer if their description said they wait until all subtasks finished or a subtask to succeed or fail.

This pull request has now been integrated.

Changeset: 3661cdee
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3661cdee1b20ab2868025637871d22bb30add6bd
Stats:     82 lines in 1 file changed: 54 ins; 3 del; 25 mod

8309853: StructuredTaskScope.join description improvements

Reviewed-by: rpressler, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/14419

From alanb at openjdk.org  Thu Jun 22 05:51:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 05:51:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
Message-ID: <k2YmiuYhXAcVUo-3a1fjXpXES4Mwl83UdYYKXYgfaBI=.26eb97aa-8349-4a36-ae73-d4b83e393952@github.com>

On Thu, 22 Jun 2023 00:13:06 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move HEX256 to LongCache

src/java.base/share/classes/java/lang/Long.java line 1233:

> 1231:                 HEX256[i] = (char) (((hi < 10 ? '0' + hi : 'a' + hi - 10) << 8)
> 1232:                         + (lo < 10 ? '0' + lo : 'a' + lo - 10));
> 1233:             }

Did you mean to put this in LongCache and is the intention it be archived or are you putting this into its own holder class? Right now it's confusing as HEX256 is not read from the archive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238023213

From duke at openjdk.org  Thu Jun 22 07:10:05 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 22 Jun 2023 07:10:05 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <-V1YfQANHNEdlooDsi0aMyQ1dIZ43zOSPHzb3OGHtDI=.4951a08f-8cfc-4948-94e5-8b09380f8e0c@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
 <-V1YfQANHNEdlooDsi0aMyQ1dIZ43zOSPHzb3OGHtDI=.4951a08f-8cfc-4948-94e5-8b09380f8e0c@github.com>
Message-ID: <rO_vUqq5rA9FwmtAoeHC44e8jiLFceeEGLpZYqEpFVs=.fac7da47-2f6a-46a7-9c5f-d090fb9b8121@github.com>

On Thu, 22 Jun 2023 02:03:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> About @Glavo's VH suggestion: I think it is feasible, since the VH field is not initialized until the method is used, so there should be no startup issue.

@liach This sounds good.

I'm thinking about refactoring `ByteArray` and `ByteArrayLittleEndian` to use `Unsafe` internally instead of `VarHandle` so we can use it in more places without worrying about affecting startup time.

I'm running some tests to determine the benefit of doing this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1602118074

From duke at openjdk.org  Thu Jun 22 07:16:25 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 07:16:25 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v8]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <-iCQuZ9Sqjo59alu21EMx_UpRQyqDYrNZumWO-X38SU=.5e6e22df-4c70-4e47-b8e7-14e789b10d0a@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  fix compile error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/e0bcf6cd..2ec33ac8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From pminborg at openjdk.org  Thu Jun 22 07:25:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 Jun 2023 07:25:08 GMT
Subject: RFR: 8310591: Missing `@since` tags in java.lang.foreign
Message-ID: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>

This PR adds missing  `@Since` and `@PreviewFeature` annotations to some of the Panama FFM entities.

This PR should also be back-ported to 21.

-------------

Commit messages:
 - Add @Since and @PreviewFeature where missing

Changes: https://git.openjdk.org/jdk/pull/14611/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14611&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310591
  Stats: 8 lines in 3 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14611/head:pull/14611

PR: https://git.openjdk.org/jdk/pull/14611

From duke at openjdk.org  Thu Jun 22 07:28:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 07:28:07 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v8]
In-Reply-To: <-iCQuZ9Sqjo59alu21EMx_UpRQyqDYrNZumWO-X38SU=.5e6e22df-4c70-4e47-b8e7-14e789b10d0a@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <-iCQuZ9Sqjo59alu21EMx_UpRQyqDYrNZumWO-X38SU=.5e6e22df-4c70-4e47-b8e7-14e789b10d0a@github.com>
Message-ID: <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>

On Thu, 22 Jun 2023 07:16:25 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compile error

> I've tested the benchmarks and the patch and baseline (with extra stable annotation) with a slightly varied version suitable for gradle run:
> 
> ```java
> package com.alibaba.openjdk;
> 
> import org.openjdk.jmh.annotations.Benchmark;
> import org.openjdk.jmh.annotations.BenchmarkMode;
> 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.Warmup;
> import org.openjdk.jmh.infra.Blackhole;
> 
> import java.util.UUID;
> import java.util.concurrent.TimeUnit;
> 
> @BenchmarkMode(Mode.Throughput)
> @OutputTimeUnit(TimeUnit.MILLISECONDS)
> @Warmup(iterations = 3, time = 10)
> @Measurement(iterations = 6, time = 5)
> @Fork(1)
> public class UUIDUtilsBenchmark {
>     public static UUID uuid = UUID.randomUUID();
> 
>     @Benchmark
>     public void jdk(Blackhole bh) {
>         bh.consume(uuid.toString());
>     }
> 
>     @Benchmark
>     public void fast(Blackhole bh) {
>         bh.consume(UUIDUtils.fastUUID(uuid));
>     }
> }
> ```
> 
> The throughput varies a lot between iterations somehow; the patch and baseline with stable has no significant difference (i.e. within the error range, about 10%)

the performance of this improvement varies among different environments, with a significant improvement on the MacBookPro M1 Max chip (my laptop) and only about 10% improvement on Linux servers (Intel Xeon(Sapphire Rapids) Platinum and Aliyun Yitian 710 arm CPU and Orange Pi 5 Plus).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1602144426

From duke at openjdk.org  Thu Jun 22 07:44:21 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 07:44:21 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v9]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <cFZGBaYLPNDVXrvKjt5U7IUBeGTdeBuflZ3udN-epYU=.127df2fa-d719-4702-8351-0a0a44faf4e7@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  use single holder class cache HEX256

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/2ec33ac8..a591e317

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=07-08

  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From liach at openjdk.org  Thu Jun 22 07:51:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 07:51:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v8]
In-Reply-To: <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <-iCQuZ9Sqjo59alu21EMx_UpRQyqDYrNZumWO-X38SU=.5e6e22df-4c70-4e47-b8e7-14e789b10d0a@github.com>
 <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>
Message-ID: <7lziil1jFig_k6k1ePXuZrT9QCnVUT7r3RSWjvANmt4=.408cbb0d-20da-4849-86a0-5ac8f46e2668@github.com>

On Thu, 22 Jun 2023 07:25:34 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix compile error
>
>> I've tested the benchmarks and the patch and baseline (with extra stable annotation) with a slightly varied version suitable for gradle run:
>> 
>> ```java
>> package com.alibaba.openjdk;
>> 
>> import org.openjdk.jmh.annotations.Benchmark;
>> import org.openjdk.jmh.annotations.BenchmarkMode;
>> 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.Warmup;
>> import org.openjdk.jmh.infra.Blackhole;
>> 
>> import java.util.UUID;
>> import java.util.concurrent.TimeUnit;
>> 
>> @BenchmarkMode(Mode.Throughput)
>> @OutputTimeUnit(TimeUnit.MILLISECONDS)
>> @Warmup(iterations = 3, time = 10)
>> @Measurement(iterations = 6, time = 5)
>> @Fork(1)
>> public class UUIDUtilsBenchmark {
>>     public static UUID uuid = UUID.randomUUID();
>> 
>>     @Benchmark
>>     public void jdk(Blackhole bh) {
>>         bh.consume(uuid.toString());
>>     }
>> 
>>     @Benchmark
>>     public void fast(Blackhole bh) {
>>         bh.consume(UUIDUtils.fastUUID(uuid));
>>     }
>> }
>> ```
>> 
>> The throughput varies a lot between iterations somehow; the patch and baseline with stable has no significant difference (i.e. within the error range, about 10%)
> 
> the performance of this improvement varies among different environments, with a significant improvement on the MacBookPro M1 Max chip (my laptop) and only about 10% improvement on Linux servers (Intel Xeon(Sapphire Rapids) Platinum and Aliyun Yitian 710 arm CPU and Orange Pi 5 Plus).

@wenshao Can you try to just add `@Stable` on `Integer.digits` array and check its benchmark results?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1602173046

From duke at openjdk.org  Thu Jun 22 07:51:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 07:51:11 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]
In-Reply-To: <k2YmiuYhXAcVUo-3a1fjXpXES4Mwl83UdYYKXYgfaBI=.26eb97aa-8349-4a36-ae73-d4b83e393952@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <DtXXfU0WlnEb0Daam56OuhINYIMvy5s7qV6AM8EjPE4=.e5e62af1-669c-4b56-b6ed-12c481ac5087@github.com>
 <k2YmiuYhXAcVUo-3a1fjXpXES4Mwl83UdYYKXYgfaBI=.26eb97aa-8349-4a36-ae73-d4b83e393952@github.com>
Message-ID: <DU_TUat8Qgjr9YBG49hA_ARrd0JINibwZSkrrbhSrHg=.40348346-de4e-4880-a159-bec4511a4fa7@github.com>

On Thu, 22 Jun 2023 05:48:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move HEX256 to LongCache
>
> src/java.base/share/classes/java/lang/Long.java line 1233:
> 
>> 1231:                 HEX256[i] = (char) (((hi < 10 ? '0' + hi : 'a' + hi - 10) << 8)
>> 1232:                         + (lo < 10 ? '0' + lo : 'a' + lo - 10));
>> 1233:             }
> 
> Did you mean to put this in LongCache and is the intention it be archived or are you putting this into its own holder class? Right now it's confusing as HEX256 is not read from the archive.

i have already used a separate holder class "DigitCache", and modifiers do not use private because I will submit a new optimization using HEX256 for Integer.toHexString and Long.toHexString

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238135779

From egahlin at openjdk.org  Thu Jun 22 07:52:08 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 Jun 2023 07:52:08 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <hUEfUyItIPPG3D684O-BDu8uPX8LAnRZrGRZT2KMPnc=.4fdae999-4b9c-4f92-922b-e81c8618edd0@github.com>

On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

I believe the fields SOCKET_READ and SOCKET_WRITE in the jdk.jfr.events.EventConfigurations class can be removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602173783

From duke at openjdk.org  Thu Jun 22 08:06:08 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 22 Jun 2023 08:06:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v9]
In-Reply-To: <cFZGBaYLPNDVXrvKjt5U7IUBeGTdeBuflZ3udN-epYU=.127df2fa-d719-4702-8351-0a0a44faf4e7@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <cFZGBaYLPNDVXrvKjt5U7IUBeGTdeBuflZ3udN-epYU=.127df2fa-d719-4702-8351-0a0a44faf4e7@github.com>
Message-ID: <5tZZWE0SC3bGCbpz0_pCA7qsV41jowbI8XD2d7pZsJA=.c29ad309-496b-4130-b62f-e4fdaa4a3ebc@github.com>

On Thu, 22 Jun 2023 07:44:21 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use single holder class cache HEX256

src/java.base/share/classes/java/lang/Long.java line 1211:

> 1209:         @Stable
> 1210:         static final char[] HEX256;
> 1211: 

Builds are broken.

Suggestion:

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238157189

From liach at openjdk.org  Thu Jun 22 08:11:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 08:11:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v9]
In-Reply-To: <5tZZWE0SC3bGCbpz0_pCA7qsV41jowbI8XD2d7pZsJA=.c29ad309-496b-4130-b62f-e4fdaa4a3ebc@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <cFZGBaYLPNDVXrvKjt5U7IUBeGTdeBuflZ3udN-epYU=.127df2fa-d719-4702-8351-0a0a44faf4e7@github.com>
 <5tZZWE0SC3bGCbpz0_pCA7qsV41jowbI8XD2d7pZsJA=.c29ad309-496b-4130-b62f-e4fdaa4a3ebc@github.com>
Message-ID: <cw_LK9j4AuQMnlE-e_k8axBC2CoPVE8uy4DUB2mI_uE=.a788e56e-e865-49e3-8ce7-45ea0d967bef@github.com>

On Thu, 22 Jun 2023 08:03:40 GMT, Glavo <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use single holder class cache HEX256
>
> src/java.base/share/classes/java/lang/Long.java line 1211:
> 
>> 1209:         @Stable
>> 1210:         static final char[] HEX256;
>> 1211: 
> 
> Builds are broken.
> 
> Suggestion:

Also the stable annotation is missing in the copy of this field in the cache class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238161975

From mbaesken at openjdk.org  Thu Jun 22 08:12:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 08:12:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <P0OBubziQAeWtqlOFA7qMWjTCxZtkPgDNqD1mt2OSWk=.85ab4ce6-dc69-43c4-b32f-8e0b6b850b2b@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <P0OBubziQAeWtqlOFA7qMWjTCxZtkPgDNqD1mt2OSWk=.85ab4ce6-dc69-43c4-b32f-8e0b6b850b2b@github.com>
Message-ID: <4pvbSkswpD7S3YrIJDJV-DXs4EiXg_Ar7eC1bTTVx8w=.6a1265d8-d5e6-437d-87dd-aa0afbda4495@github.com>

On Wed, 21 Jun 2023 15:25:15 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> test/lib/jdk/test/lib/Platform.java line 280:
> 
>> 278:         String line;
>> 279:         while ((line = is.readLine()) != null) {
>> 280:             System.out.println("STDOUT: " + line);
> 
> This output is for every line seems too much. Maybe just print the lines where you find "Info.plist=not bound" or "Info.plist entries="?

I found the output useful when analyzing the issue (and it is just a few lines).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1238163572

From duke at openjdk.org  Thu Jun 22 08:29:06 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 22 Jun 2023 08:29:06 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v8]
In-Reply-To: <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <-iCQuZ9Sqjo59alu21EMx_UpRQyqDYrNZumWO-X38SU=.5e6e22df-4c70-4e47-b8e7-14e789b10d0a@github.com>
 <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>
Message-ID: <2WvehJMrdu0Zd29AwEpilKiLiPIEbHIrbvbyfPy8V1Q=.f6b325d7-768c-4543-8ee1-01951a59f13c@github.com>

On Thu, 22 Jun 2023 07:25:34 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix compile error
>
>> I've tested the benchmarks and the patch and baseline (with extra stable annotation) with a slightly varied version suitable for gradle run:
>> 
>> ```java
>> package com.alibaba.openjdk;
>> 
>> import org.openjdk.jmh.annotations.Benchmark;
>> import org.openjdk.jmh.annotations.BenchmarkMode;
>> 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.Warmup;
>> import org.openjdk.jmh.infra.Blackhole;
>> 
>> import java.util.UUID;
>> import java.util.concurrent.TimeUnit;
>> 
>> @BenchmarkMode(Mode.Throughput)
>> @OutputTimeUnit(TimeUnit.MILLISECONDS)
>> @Warmup(iterations = 3, time = 10)
>> @Measurement(iterations = 6, time = 5)
>> @Fork(1)
>> public class UUIDUtilsBenchmark {
>>     public static UUID uuid = UUID.randomUUID();
>> 
>>     @Benchmark
>>     public void jdk(Blackhole bh) {
>>         bh.consume(uuid.toString());
>>     }
>> 
>>     @Benchmark
>>     public void fast(Blackhole bh) {
>>         bh.consume(UUIDUtils.fastUUID(uuid));
>>     }
>> }
>> ```
>> 
>> The throughput varies a lot between iterations somehow; the patch and baseline with stable has no significant difference (i.e. within the error range, about 10%)
> 
> the performance of this improvement varies among different environments, with a significant improvement on the MacBookPro M1 Max chip (my laptop) and only about 10% improvement on Linux servers (Intel Xeon(Sapphire Rapids) Platinum and Aliyun Yitian 710 arm CPU and Orange Pi 5 Plus).

@wenshao I rerun the benchmark:


Baseline:
Benchmark   Mode  Cnt      Score     Error   Units
UUID.test  thrpt    5  84224.961 ? 556.817  ops/ms

Your PR:
Benchmark   Mode  Cnt      Score    Error   Units
UUID.test  thrpt    5  76205.978 ? 93.024  ops/ms

Using ByteArray (https://github.com/openjdk/jdk/pull/14578#discussion_r1237573456)
Benchmark   Mode  Cnt      Score     Error   Units
UUID.test  thrpt    5  87015.810 ? 329.174  ops/ms


Your current implementation has lower performance on my server than the baseline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1602226247

From aboldtch at openjdk.org  Thu Jun 22 08:47:11 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Jun 2023 08:47:11 GMT
Subject: [jdk21] Integrated: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
References: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
Message-ID: <-l-PUtkHpuka6haLkl2dJ7vfY0xRZuphvpoT8tGv7ZA=.d3088503-3528-4190-9579-893355eb91af@github.com>

On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6317249b
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6317249b50e039474f67c15507134bfc65a0fa79
Stats:     619 lines in 70 files changed: 447 ins; 5 del; 167 mod

8310187: Improve Generational ZGC jtreg testing

Reviewed-by: eosterlund
Backport-of: a0595761ef35c4eec8cb84326a869b9473cd5bba

-------------

PR: https://git.openjdk.org/jdk21/pull/37

From duke at openjdk.org  Thu Jun 22 08:57:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 08:57:27 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v10]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <nG81csbCgx4oq59kmglAw7_tH_sP89RP53eMIFrwVI8=.a6e04ec0-9110-4400-9ac4-f0697cb750ae@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  fix compile error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/a591e317..ae5c2e8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=08-09

  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Thu Jun 22 09:07:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 09:07:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v11]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <2VqC1uFLFwb5OT7zqjtTOGKoyfn6plNsar7vvCDcn84=.8bb33223-d378-499c-b0b6-6ba2dbda183b@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  use ByteArray for COMPACT_STRINGS disable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/ae5c2e8d..728dbddf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=09-10

  Stats: 88 lines in 1 file changed: 39 ins; 8 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From asemenov at openjdk.org  Thu Jun 22 09:13:21 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 09:13:21 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/101bf062..842d33d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04-05

  Stats: 26 lines in 5 files changed: 11 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Thu Jun 22 09:13:24 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 09:13:24 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
 <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>
Message-ID: <1uzHyJeBll4YnB4uuKYWFX8e7z66iWHoYK4Ksu8T3Ic=.c2a86584-ea77-48f9-8306-368edb33d0af@github.com>

On Wed, 21 Jun 2023 07:35:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - update
>>  - update
>>  - update
>>  - update
>>  - 8308286 Fix clang warnings in linux code
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235:
> 
>> 233:         DISABLED_WARNINGS_gcc := int-to-pointer-cast, \
>> 234:         DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \
>> 235:         DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \
> 
> please group the disabled warnings by compiler (gcc, then clang, then clang_aix)

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238236415

From duke at openjdk.org  Thu Jun 22 09:14:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 09:14:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v12]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <1wrJ-2Z7aiz3nkNB7CnKRGGC_5N4GLwnz-djVwcrZu8=.1e3a19d6-0612-4e8f-afe8-80dcfc170853@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  revert to non-ByteArray

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/728dbddf..c6dca16f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=10-11

  Stats: 116 lines in 1 file changed: 76 ins; 37 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From mcimadamore at openjdk.org  Thu Jun 22 09:21:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 22 Jun 2023 09:21:03 GMT
Subject: RFR: 8310591: Missing `@since` tags in java.lang.foreign
In-Reply-To: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
References: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
Message-ID: <edGSnDwVbBlF8uLQwj70ju8b3vSOCd-678swaYPJRQw=.e6128d5b-59ed-4954-b9cf-7d848c0c4049@github.com>

On Thu, 22 Jun 2023 07:18:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR adds missing  `@Since` and `@PreviewFeature` annotations to some of the Panama FFM entities.
> 
> This PR should also be back-ported to 21.

src/java.base/share/classes/java/lang/foreign/package-info.java line 156:

> 154: package java.lang.foreign;
> 155: 
> 156: import jdk.internal.javac.PreviewFeature;

Add an extra newline at the end

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14611#discussion_r1238248933

From mbaesken at openjdk.org  Thu Jun 22 09:26:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:26:06 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
Message-ID: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>

On Wed, 21 Jun 2023 21:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:
> 
>> 194: 
>> 195:     /**
>> 196:      * Set whether or not to use ct.sym as an alternate
> 
> As an alternate to what? This needs something else.

should "to the image modules files"  be used instead ?

> test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:
> 
>> 1: /*
> 
> The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?

It seems to start a javap. So I think it tests something, how important this is and what other tests might cover similar stuff, I do not know unfortunately .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238252196
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238254149

From mbaesken at openjdk.org  Thu Jun 22 09:53:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:53:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Some adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14562/files
  - new: https://git.openjdk.org/jdk/pull/14562/files/0d8c68c2..1b604db9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=00-01

  Stats: 37 lines in 5 files changed: 17 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mbaesken at openjdk.org  Thu Jun 22 09:53:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:53:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <b_loscpG1LcPQ6jUXpSinaEEm1D4WwYeh6Nk8EaskHw=.d18d1729-dd6e-449a-b45f-a99fe53cb89d@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

I adjusted COPYRIGHT info, adjusted TestMutuallyExclusivePlatformPredicates.java .
Also simplified the coding in Platform.java a bit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1602340023

From mbaesken at openjdk.org  Thu Jun 22 09:53:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:53:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <2hTz6Ylp5KA89yQymiGug9j251kWEWeEYKL01an3gqM=.b270bd6f-0c69-4bec-8a6b-b423dc6d70d9@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <2hTz6Ylp5KA89yQymiGug9j251kWEWeEYKL01an3gqM=.b270bd6f-0c69-4bec-8a6b-b423dc6d70d9@github.com>
Message-ID: <9BGK9J99tjP0UEZdoJU5BHJwadhXskzU2eK6HZ_-z4w=.2b048728-6ba1-4acf-8cdf-aee0c3adffdd@github.com>

On Wed, 21 Jun 2023 19:32:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some adjustments
>
> test/lib/jdk/test/lib/util/CoreUtils.java line 131:
> 
>> 129:             return coreFileLocation; // success!
>> 130:         } else {
>> 131:             System.out.println("Core file not found, try to find a reason for this");
> 
> Suggestion:
> 
>             System.out.println("Core file not found. Trying to find a reason why...");

I changed the message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1238282996

From pminborg at openjdk.org  Thu Jun 22 09:56:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 Jun 2023 09:56:09 GMT
Subject: RFR: 8310591: Missing `@since` tags in java.lang.foreign [v2]
In-Reply-To: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
References: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
Message-ID: <ATS-Z85299bMzTpmxw04pKpkWcqO7i_UkouXfgPgDgY=.26ba3421-33ee-4e70-9fb4-5fddb422f1fc@github.com>

> This PR adds missing  `@Since` and `@PreviewFeature` annotations to some of the Panama FFM entities.
> 
> This PR should also be back-ported to 21.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Add newline
 - Harmonize copyringht messages

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14611/files
  - new: https://git.openjdk.org/jdk/pull/14611/files/935bf2b4..3e35dc05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14611&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14611&range=00-01

  Stats: 273 lines in 13 files changed: 37 ins; 38 del; 198 mod
  Patch: https://git.openjdk.org/jdk/pull/14611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14611/head:pull/14611

PR: https://git.openjdk.org/jdk/pull/14611

From djelinski at openjdk.org  Thu Jun 22 10:02:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 10:02:09 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
Message-ID: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>

On Thu, 22 Jun 2023 09:13:21 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:

> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

Suggestion:

        DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
        DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
        DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
        DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
        DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
        DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
        DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260:

> 258:         DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
> 259:         DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \
> 260:         DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \

move this one closer to the other clang (non-aix) suppressions

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238296391
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238297332

From duke at openjdk.org  Thu Jun 22 10:13:18 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 10:13:18 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v13]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <JEWZUqt239w0Eh0PgwybdlCePVo8f03wXld4M4YIUqc=.a47c19dc-3209-470b-a01d-a927ec001f81@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  use ByteArray & simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/c6dca16f..2c9660ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=11-12

  Stats: 109 lines in 1 file changed: 2 ins; 55 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From alanb at openjdk.org  Thu Jun 22 10:25:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 10:25:09 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com>

On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

src/java.base/share/classes/java/net/Socket.java line 1101:

> 1099:         @Override
> 1100:         public int read(byte[] b, int off, int len) throws IOException {
> 1101:             if (! SocketReadEvent.enabled()) {

Drop the space in "! SocketReadEvent" as it is inconsistent with the existing code.

src/java.base/share/classes/jdk/internal/event/SocketReadEvent.java line 119:

> 117:     public static void checkForCommit(long start, long nbytes, SocketAddress remote, long timeout) {
> 118:         long duration = timestamp() - start;
> 119:         if (shouldCommit(duration)) {

I think you know this, but this will need to be re-examined for SocketChannel configured non-blocking.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:

> 406:     @Override
> 407:     public int read(ByteBuffer buf) throws IOException {
> 408:         if (!SocketReadEvent.enabled()) {

The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 416:

> 414:             nbytes = implRead(buf);
> 415:         } finally {
> 416:             SocketReadEvent.checkForCommit(start, nbytes, getRemoteAddress(), 0);

This will need to be changed to use remoteAddress(), can't use getRemoteAddress() as it might throw.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 466:

> 464:         throws IOException
> 465:     {
> 466:         if (! SocketReadEvent.enabled()) {

Spurious space here too, several other places.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 474:

> 472:             nbytes = implRead(dsts, offset, length);
> 473:         } finally {
> 474:             SocketReadEvent.checkForCommit(start, nbytes, getRemoteAddress(), 0);

This has to be remoteAddress() too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238312001
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238317470
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238323035
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238318572
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238318875
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238319120

From alanb at openjdk.org  Thu Jun 22 10:25:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 10:25:11 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <Szmpu-UifvnljGMg0Ddt5StvwPNujRsuzDzMjA6DVHw=.0e63f68a-b86f-48c7-99e4-6efad007d33e@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <Szmpu-UifvnljGMg0Ddt5StvwPNujRsuzDzMjA6DVHw=.0e63f68a-b86f-48c7-99e4-6efad007d33e@github.com>
Message-ID: <-CBspYQOiQx_e5vmZhTtyJkmVQAyr129m3xJIlVJy3k=.f4b5bc13-35bf-4bfe-85df-a84fa8362186@github.com>

On Wed, 21 Jun 2023 15:48:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> src/java.base/share/classes/java/net/Socket.java line 1109:
> 
>> 1107:                 nbytes = read0(b, off, len);
>> 1108:             } finally {
>> 1109:                 SocketReadEvent.checkForCommit(start, nbytes, parent.getRemoteSocketAddress(), parent.getSoTimeout());
> 
> So if read throws, this will commit a jdk.SocketReadEvent with size 0, maybe this will change later to include the exception?

The other issue to think about here is where the Socket is asynchronously closed. In t hat case, implRead will throw but we'll end up with a confusing suppressed exception due to the call to getSoTimeout. I think this will have to be replaced with a call to a helper method that returns the timeout or 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1238315000

From prappo at openjdk.org  Thu Jun 22 10:30:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Jun 2023 10:30:03 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <L4hQ4t4s_7gA1IklrR2qaWxzh5WG5QM24dHdkTJpFsg=.eae19715-38e0-4ffd-a87e-4821eb5ea319@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
 <L4hQ4t4s_7gA1IklrR2qaWxzh5WG5QM24dHdkTJpFsg=.eae19715-38e0-4ffd-a87e-4821eb5ea319@github.com>
Message-ID: <QMqAhwKxjfnuxom8cp1PZkfxyPRmQpF9CdPW6q__99c=.7afbdcfb-a152-4d36-9ced-f8c1ffafe437@github.com>

On Wed, 21 Jun 2023 11:55:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While it's out of scope of this PR, I note that we could also use the inline variant of `@return` in those methods of `Objects` that the `Object` refers to: `hash(Object)`, `hashCode(Object...)`, and `equals(Object, Object)`. In fact, I think they are crying for it.

@jddarcy, I see you have since published a separate PR that includes those methods: #14608; thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14567#issuecomment-1602397294

From prappo at openjdk.org  Thu Jun 22 10:40:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Jun 2023 10:40:05 GMT
Subject: RFR: JDK-8310571: Use inline @return tag on java.util.Objects
In-Reply-To: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
References: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
Message-ID: <KhPYSc1BrsN9papFFs01J8Pm5IPm6NSbg-4RQTraEck=.ede1e8fa-3675-4ef2-8ada-c7f31d418f11@github.com>

On Thu, 22 Jun 2023 00:19:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

I can see that `Objects.hash(Object...)` was not changed in this PR. Although I think I can see why, I wonder if any distinctions between "Generates" and "Returns" are not important in that context:

   /**
    * Generates a hash code for a sequence of input values. The hash
...
    * @return a hash value of the sequence of input values
...
    */
    public static int hash(Object... values) {

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14608#issuecomment-1602410131

From djelinski at openjdk.org  Thu Jun 22 10:40:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 10:40:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
Message-ID: <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>

On Thu, 22 Jun 2023 03:00:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters 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:
> 
>   Revert NULL to nullptr changes in jaccesswalker

src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 547:

> 545:         snprintf( s, sizeof(s),
> 546:             "ERROR calling GetAccessibleContextInfo; vmID = %lX, context = %p",
> 547:             reinterpret_cast<unsigned long>(vmID), (void*)context );

do you need this cast? I checked a few compilers and passing a signed long to "%lX" was fine with them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238338713

From clanger at openjdk.org  Thu Jun 22 10:57:08 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Jun 2023 10:57:08 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
Message-ID: <GGGG9CKG556EUDfDUmDUMomSxvRB81VyGrt0sbXRchM=.59c82f26-0d1c-43a2-ae8c-d28482b793da@github.com>

On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some adjustments

Looks a bit better. But I think instead of adding a Utils.javaPath() method, you can do all this path handling in Platform.launchCodesignOnJavaBinary(). Then even more code would be shared.

test/lib/jdk/test/lib/Platform.java line 263:

> 261:     }
> 262: 
> 263:     private static codesignProcess launchCodesignOnJavaBinary(String javaFileName) {

That can't work... should be `private static Process` ?

-------------

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1492927024
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1238354879

From duke at openjdk.org  Thu Jun 22 11:01:07 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 22 Jun 2023 11:01:07 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v13]
In-Reply-To: <JEWZUqt239w0Eh0PgwybdlCePVo8f03wXld4M4YIUqc=.a47c19dc-3209-470b-a01d-a927ec001f81@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <JEWZUqt239w0Eh0PgwybdlCePVo8f03wXld4M4YIUqc=.a47c19dc-3209-470b-a01d-a927ec001f81@github.com>
Message-ID: <SK98ArYyx-VU3BqrefyvIBAmYyvHMJEt7ioJDdIwwto=.e020cb5e-d360-4b83-b979-ee21a8252a16@github.com>

On Thu, 22 Jun 2023 10:13:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ByteArray & simplify code

src/java.base/share/classes/java/lang/Long.java line 492:

> 490:             ByteArray.setChar(buf, 30, i13);
> 491:             ByteArray.setChar(buf, 32, i14);
> 492:             ByteArray.setChar(buf, 34, i15);

Suggestion:

            ByteArray.setLong(buf, 0, ((long) i0 << 48) | ((long) i1 << 32) | ((long) i2 << 16) | i3);
            buf[8] = '-';
            ByteArray.setInt(buf, 9, (i4 << 16) | i5);
            buf[13] = '-';
            ByteArray.setInt(buf, 14, (i6 << 16) | i7);
            buf[18] = '-';
            ByteArray.setInt(buf, 19, (i8 << 16) | i9);
            buf[23] = '-';
            ByteArray.setLong(buf, 24, ((long) i10 << 48) | ((long) i11 << 32) | ((long) i12 << 16) | i13);
            ByteArray.setInt(buf, 32, (i14 << 16) | i15);


JMH Result:


  Benchmark   Mode  Cnt      Score     Error   Units
- UUID.test  thrpt    5  87196.091 ? 492.129  ops/ms
+ UUID.test  thrpt    5  99197.287 ? 925.266  ops/ms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238363498

From duke at openjdk.org  Thu Jun 22 11:07:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 11:07:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v14]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <yYUOc9Y9ew3ypNpZSQDdi9j0eXQd4Ugr8iVHdWdQRpU=.8a8b1b3d-bffe-49ed-9653-1f72459763de@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  use ByteArray.setInt & setLong

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/2c9660ad..5a5e7e12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=12-13

  Stats: 16 lines in 1 file changed: 0 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From prappo at openjdk.org  Thu Jun 22 11:11:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Jun 2023 11:11:07 GMT
Subject: RFR: JDK-8310571: Use inline @return tag on java.util.Objects
In-Reply-To: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
References: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
Message-ID: <SrxjL-0yb6ORenH5R-fB2dyR0AXI-ozcIgZdcttisfs=.10bd7344-b1de-48fd-af6b-053baaef593d@github.com>

On Thu, 22 Jun 2023 00:19:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

Thanks for doing this, Joe. It seems that I have made multiple comments on the same issue. It makes me wonder if that isn't an issue at all, but is a deliberate choice made in this PR.

src/java.base/share/classes/java/util/Objects.java line 145:

> 143:      * {@return the result of calling {@code toString} on the first
> 144:      * argument if the first argument is not {@code null} and returns
> 145:      * the second argument otherwise}

This "returns" in "and returns" feels non-DRY and brittle. We enclosed that word in `{@return}` already. Maybe we could use the wording from the original `@return` to avoid the verb altogether?

This is of course, a personal opinion.

src/java.base/share/classes/java/util/Objects.java line 251:

> 249: 
> 250:     /**
> 251:      * {@return {@code true} if the provided reference is {@code

See my previous comment on the "returns" verb in the doc comment for toString(Object, String). Here (IMO), you picked the better of the two options.

src/java.base/share/classes/java/util/Objects.java line 284:

> 282:     /**
> 283:      * {@return the first argument if it is non-{@code null} and
> 284:      * otherwise returns the non-{@code null} second argument}

Same comment for "returns".

src/java.base/share/classes/java/util/Objects.java line 300:

> 298:     /**
> 299:      * {@return the first argument if it is non-{@code null} and otherwise
> 300:      * returns the non-{@code null} value of {@code supplier.get()}}

Same.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14608#pullrequestreview-1492911171
PR Review Comment: https://git.openjdk.org/jdk/pull/14608#discussion_r1238347052
PR Review Comment: https://git.openjdk.org/jdk/pull/14608#discussion_r1238367383
PR Review Comment: https://git.openjdk.org/jdk/pull/14608#discussion_r1238370870
PR Review Comment: https://git.openjdk.org/jdk/pull/14608#discussion_r1238371975

From mbaesken at openjdk.org  Thu Jun 22 11:51:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 11:51:15 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  move javaPath into caller

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14562/files
  - new: https://git.openjdk.org/jdk/pull/14562/files/1b604db9..619b3578

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=01-02

  Stats: 32 lines in 2 files changed: 6 ins; 23 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mbaesken at openjdk.org  Thu Jun 22 11:51:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 11:51:16 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
Message-ID: <-9fdkta4gj5UUkFxpgUAsFfAR1jWuWPLz6G7XmCONio=.d12a4915-6494-457f-a3c9-26550f0a3c67@github.com>

On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some adjustments

Yes it must be 'private static Process' . And I moved the javaPath method into the caller ,

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1602496320

From dfuchs at openjdk.org  Thu Jun 22 11:57:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jun 2023 11:57:04 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <EAJkf3t-7yNk3CRvC2oRsjW5dJ1-ZX-hODYy2ShdQHE=.51608e32-7dff-4c92-aaf3-5d25c62943a5@github.com>

On Tue, 6 Jun 2023 19:39:31 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

The new code seems to accurately correspond to what the various `*Instrumentor` classes were doing, so that is good. I agree with Alan that potential exception that may arise when generating the event are an issue (e.g. call to getRemoteAddress() or other getter that may make a check on the socket state) - though that was already present in the original code. Maybe that could be fixed here though. 
In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602505386

From pminborg at openjdk.org  Thu Jun 22 12:05:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 Jun 2023 12:05:19 GMT
Subject: RFR: 8310591: Missing `@since` tags in java.lang.foreign [v3]
In-Reply-To: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
References: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
Message-ID: <jc3SlkJx0_-CU2I6n1PCZ7ngsHnGKbZBn-AllWrzN7k=.2a4f6e91-a204-4bd1-b8a4-da5a2175e725@github.com>

> This PR adds missing  `@Since` and `@PreviewFeature` annotations to some of the Panama FFM entities.
> 
> This PR should also be back-ported to 21.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Harmonize copyringht messages"
  
  This reverts commit 2931c8c7e677431c49f194fa67265005725dbcf9.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14611/files
  - new: https://git.openjdk.org/jdk/pull/14611/files/3e35dc05..d40f5c6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14611&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14611&range=01-02

  Stats: 271 lines in 13 files changed: 41 ins; 40 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/14611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14611/head:pull/14611

PR: https://git.openjdk.org/jdk/pull/14611

From pminborg at openjdk.org  Thu Jun 22 12:05:22 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 22 Jun 2023 12:05:22 GMT
Subject: Integrated: 8310591: Missing `@since` tags in java.lang.foreign
In-Reply-To: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
References: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
Message-ID: <dQFqY7TuDh1b517dcM3eVB_czM3xpAnH9bSxS1r4Z3M=.1723a54e-6525-4fd7-a890-26e8405119c0@github.com>

On Thu, 22 Jun 2023 07:18:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR adds missing  `@Since` and `@PreviewFeature` annotations to some of the Panama FFM entities.
> 
> This PR should also be back-ported to 21.

This pull request has now been integrated.

Changeset: 5a30fb66
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a30fb6664e748fe41606eecda1f882a9a3c66b8
Stats:     8 lines in 3 files changed: 8 ins; 0 del; 0 mod

8310591: Missing `@since` tags in java.lang.foreign

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14611

From mcimadamore at openjdk.org  Thu Jun 22 12:05:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 22 Jun 2023 12:05:20 GMT
Subject: RFR: 8310591: Missing `@since` tags in java.lang.foreign [v3]
In-Reply-To: <jc3SlkJx0_-CU2I6n1PCZ7ngsHnGKbZBn-AllWrzN7k=.2a4f6e91-a204-4bd1-b8a4-da5a2175e725@github.com>
References: <onu2eaKYo8nhb6Xfr55bKS90ktJR4QCIlZQxISd70IE=.dd7124d5-b6b3-4d82-8f09-5d39f08367e7@github.com>
 <jc3SlkJx0_-CU2I6n1PCZ7ngsHnGKbZBn-AllWrzN7k=.2a4f6e91-a204-4bd1-b8a4-da5a2175e725@github.com>
Message-ID: <gIrGYRw_M44o8ezl8sVZmnBmH73Ib-h6UyP3iJbPBbg=.d9a27c05-991e-4144-9c68-b6d1ea3151a1@github.com>

On Thu, 22 Jun 2023 11:59:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR adds missing  `@Since` and `@PreviewFeature` annotations to some of the Panama FFM entities.
>> 
>> This PR should also be back-ported to 21.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Harmonize copyringht messages"
>   
>   This reverts commit 2931c8c7e677431c49f194fa67265005725dbcf9.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14611#pullrequestreview-1493024804

From mbaesken at openjdk.org  Thu Jun 22 12:09:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 12:09:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <GGGG9CKG556EUDfDUmDUMomSxvRB81VyGrt0sbXRchM=.59c82f26-0d1c-43a2-ae8c-d28482b793da@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
 <GGGG9CKG556EUDfDUmDUMomSxvRB81VyGrt0sbXRchM=.59c82f26-0d1c-43a2-ae8c-d28482b793da@github.com>
Message-ID: <BfNd8YxeRyIH31LJU6lPiassDRgN3qd0FK2Ejpc93Vs=.7b1f4461-c90a-4260-9be5-11d18996864d@github.com>

On Thu, 22 Jun 2023 10:54:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Looks a bit better. But I think instead of adding a Utils.javaPath() method, you can do all this path handling in Platform.launchCodesignOnJavaBinary(). Then even more code would be shared.

Okay, I  had the idea  to later use  the method javaPath  at some more places, but let's do this separately.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1602521579

From alanb at openjdk.org  Thu Jun 22 12:09:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 12:09:27 GMT
Subject: [jdk21] RFR: 8309853: StructuredTaskScope.join description
 improvements
Message-ID: <HD17NbxnFPXZE3pIsn2hV37f0mQ9JFy1eEL5ZPcRk8Q=.93008e89-41c0-4265-a80b-67a249841d79@github.com>

8309853: StructuredTaskScope.join description improvements

-------------

Commit messages:
 - Backport 3661cdee1b20ab2868025637871d22bb30add6bd

Changes: https://git.openjdk.org/jdk21/pull/55/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=55&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309853
  Stats: 82 lines in 1 file changed: 54 ins; 3 del; 25 mod
  Patch: https://git.openjdk.org/jdk21/pull/55.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/55/head:pull/55

PR: https://git.openjdk.org/jdk21/pull/55

From duke at openjdk.org  Thu Jun 22 12:22:09 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 22 Jun 2023 12:22:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v14]
In-Reply-To: <yYUOc9Y9ew3ypNpZSQDdi9j0eXQd4Ugr8iVHdWdQRpU=.8a8b1b3d-bffe-49ed-9653-1f72459763de@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <yYUOc9Y9ew3ypNpZSQDdi9j0eXQd4Ugr8iVHdWdQRpU=.8a8b1b3d-bffe-49ed-9653-1f72459763de@github.com>
Message-ID: <mpd9Kg-OPkEgHDTSq3Q_Q8SDpBFTdQXTycUKhtI3WlI=.88b252d3-1415-4e69-b126-561d72da9b3e@github.com>

On Thu, 22 Jun 2023 11:07:09 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ByteArray.setInt & setLong

src/java.base/share/classes/java/lang/Long.java line 527:

> 525:         buf[70 + off] = (byte) i15;
> 526: 
> 527:         return new String(buf, UTF16);

Maybe?restore the?`else`?block?
Suggestion:

        } else {
            byte[] buf = new byte[72];
            int off = ByteOrder.nativeOrder() == ByteOrder.BIG_ENDIAN ? 1 : 0;

            buf[0 + off] = (byte) (i0 >> 8);
            buf[2 + off] = (byte) i0;
            buf[4 + off] = (byte) (i1 >> 8);
            buf[6 + off] = (byte) i1;
            buf[8 + off] = (byte) (i2 >> 8);
            buf[10 + off] = (byte) i2;
            buf[12 + off] = (byte) (i3 >> 8);
            buf[14 + off] = (byte) i3;
            buf[16 + off] = '-';
            buf[18 + off] = (byte) (i4 >> 8);
            buf[20 + off] = (byte) i4;
            buf[22 + off] = (byte) (i5 >> 8);
            buf[24 + off] = (byte) i5;
            buf[26 + off] = '-';
            buf[28 + off] = (byte) (i6 >> 8);
            buf[30 + off] = (byte) i6;
            buf[32 + off] = (byte) (i7 >> 8);
            buf[34 + off] = (byte) i7;
            buf[36 + off] = '-';
            buf[38 + off] = (byte) (i8 >> 8);
            buf[40 + off] = (byte) i8;
            buf[42 + off] = (byte) (i9 >> 8);
            buf[44 + off] = (byte) i9;
            buf[46 + off] = '-';
            buf[48 + off] = (byte) (i10 >> 8);
            buf[50 + off] = (byte) i10;
            buf[52 + off] = (byte) (i11 >> 8);
            buf[54 + off] = (byte) i11;
            buf[56 + off] = (byte) (i12 >> 8);
            buf[58 + off] = (byte) i12;
            buf[60 + off] = (byte) (i13 >> 8);
            buf[62 + off] = (byte) i13;
            buf[64 + off] = (byte) (i14 >> 8);
            buf[66 + off] = (byte) i14;
            buf[68 + off] = (byte) (i15 >> 8);
            buf[70 + off] = (byte) i15;

            return new String(buf, UTF16);
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238446588

From clanger at openjdk.org  Thu Jun 22 12:23:07 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Jun 2023 12:23:07 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <D19L98CF1JaEwwTVDOmQ8W98G3QvZmaIU6fR9jXzCfg=.2ce8ad35-1f03-4c0e-862f-e1dce10fbd0d@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Looks good to me now.

-------------

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1493063728

From liach at openjdk.org  Thu Jun 22 13:10:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 13:10:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v14]
In-Reply-To: <mpd9Kg-OPkEgHDTSq3Q_Q8SDpBFTdQXTycUKhtI3WlI=.88b252d3-1415-4e69-b126-561d72da9b3e@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <yYUOc9Y9ew3ypNpZSQDdi9j0eXQd4Ugr8iVHdWdQRpU=.8a8b1b3d-bffe-49ed-9653-1f72459763de@github.com>
 <mpd9Kg-OPkEgHDTSq3Q_Q8SDpBFTdQXTycUKhtI3WlI=.88b252d3-1415-4e69-b126-561d72da9b3e@github.com>
Message-ID: <8Ot6KaQGiCAQWfy4fWcZvVbPe378LC0MY_tV0D5HaUc=.0371a36f-9419-4703-af90-b899cc195ef9@github.com>

On Thu, 22 Jun 2023 12:18:21 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ByteArray.setInt & setLong
>
> src/java.base/share/classes/java/lang/Long.java line 527:
> 
>> 525:         buf[70 + off] = (byte) i15;
>> 526: 
>> 527:         return new String(buf, UTF16);
> 
> Maybe?restore the?`else`?block?
> Suggestion:
> 
>         } else {
>             byte[] buf = new byte[72];
>             int off = ByteOrder.nativeOrder() == ByteOrder.BIG_ENDIAN ? 1 : 0;
> 
>             buf[0 + off] = (byte) (i0 >> 8);
>             buf[2 + off] = (byte) i0;
>             buf[4 + off] = (byte) (i1 >> 8);
>             buf[6 + off] = (byte) i1;
>             buf[8 + off] = (byte) (i2 >> 8);
>             buf[10 + off] = (byte) i2;
>             buf[12 + off] = (byte) (i3 >> 8);
>             buf[14 + off] = (byte) i3;
>             buf[16 + off] = '-';
>             buf[18 + off] = (byte) (i4 >> 8);
>             buf[20 + off] = (byte) i4;
>             buf[22 + off] = (byte) (i5 >> 8);
>             buf[24 + off] = (byte) i5;
>             buf[26 + off] = '-';
>             buf[28 + off] = (byte) (i6 >> 8);
>             buf[30 + off] = (byte) i6;
>             buf[32 + off] = (byte) (i7 >> 8);
>             buf[34 + off] = (byte) i7;
>             buf[36 + off] = '-';
>             buf[38 + off] = (byte) (i8 >> 8);
>             buf[40 + off] = (byte) i8;
>             buf[42 + off] = (byte) (i9 >> 8);
>             buf[44 + off] = (byte) i9;
>             buf[46 + off] = '-';
>             buf[48 + off] = (byte) (i10 >> 8);
>             buf[50 + off] = (byte) i10;
>             buf[52 + off] = (byte) (i11 >> 8);
>             buf[54 + off] = (byte) i11;
>             buf[56 + off] = (byte) (i12 >> 8);
>             buf[58 + off] = (byte) i12;
>             buf[60 + off] = (byte) (i13 >> 8);
>             buf[62 + off] = (byte) i13;
>             buf[64 + off] = (byte) (i14 >> 8);
>             buf[66 + off] = (byte) i14;
>             buf[68 + off] = (byte) (i15 >> 8);
>             buf[70 + off] = (byte) i15;
> 
>             return new String(buf, UTF16);
>         }

We should avoid extra indentation when possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1238503236

From stsypanov at openjdk.org  Thu Jun 22 13:26:02 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 22 Jun 2023 13:26:02 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <Jd-PqHvj7s7SuiH_Q4xXnH2HKVlLYG-SR41tbQlUry8=.66e77fdf-4ee5-47b6-8b01-b8936519e685@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <5uQb42QmjGtiQXy6MsepPrUWOFIViMNi9wWS92gEzN8=.a52dcf79-6b1f-485e-b4be-c8d3828578a8@github.com>
 <6LMAYRo_gj99F4LzYwcyErnCHTFrj1Em4ajCx9Sp8XA=.c2b6bd40-370e-4fe1-a5b7-dbe05e822297@github.com>
 <Jd-PqHvj7s7SuiH_Q4xXnH2HKVlLYG-SR41tbQlUry8=.66e77fdf-4ee5-47b6-8b01-b8936519e685@github.com>
Message-ID: <fe6rZm5vNpJVmbtESEf6R05VnDi2ThHOBRX9xUhke1o=.7fcc4b49-7b60-4133-9ce8-b62ac6d985aa@github.com>

On Wed, 21 Jun 2023 14:58:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> On second thought, this is probably not necessary; write to the sink field is in another synchronized method, and this method is synchronized already. Is the goal here to remove the synchronized on flush?
>
> Good observation. Removing `synchronized` on flush might be a worthwhile goal but possible side effects (including on potential subclasses) should be carefully considered.
> I support stashing `sink` in a local variable though, even if the pointer can't be concurrently modified, just to make it clear that we only have one volatile read.

I think it's better to keep `synchronized` over the method this far

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14589#discussion_r1238524265

From egahlin at openjdk.org  Thu Jun 22 13:43:04 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 22 Jun 2023 13:43:04 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <EAJkf3t-7yNk3CRvC2oRsjW5dJ1-ZX-hODYy2ShdQHE=.51608e32-7dff-4c92-aaf3-5d25c62943a5@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <EAJkf3t-7yNk3CRvC2oRsjW5dJ1-ZX-hODYy2ShdQHE=.51608e32-7dff-4c92-aaf3-5d25c62943a5@github.com>
Message-ID: <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>

On Thu, 22 Jun 2023 11:53:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The new code seems to accurately correspond to what the various `*Instrumentor` classes were doing, so that is good. I agree with Alan that potential exception that may arise when generating the event are an issue (e.g. call to getRemoteAddress() or other getter that may make a check on the socket state) - though that was already present in the original code. Maybe that could be fixed here though.
> In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead?

An exception event will be emitted. The event is disabled by default, but there is ongoing work on a throttling mechanism, so it can be always-on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1602659051

From alanb at openjdk.org  Thu Jun 22 13:51:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 13:51:06 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v7]
In-Reply-To: <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
Message-ID: <DtGGdY_bhonMZJ9w-YEI2wH_JZn3Vjvi3AHXjCl1dhM=.07baf5f9-da03-4fb6-ba8a-1b4e2e4b17f1@github.com>

On Thu, 22 Jun 2023 00:33:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by alanb (Reviewer).

test/jdk/java/lang/Class/forName/ForNameNames.java line 45:

> 43:                 Arguments.of("java.lang.String", String.class),
> 44:                 Arguments.of("[Ljava.lang.String;", String[].class),
> 45:                 Arguments.of("ForNameNames$Inner", Inner.class),

For completeness, you could add "[LForNameNames$Inner;" to this list of test cases.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1493243021
PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1238557381

From jwaters at openjdk.org  Thu Jun 22 13:52:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 13:52:12 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
Message-ID: <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>

On Thu, 22 Jun 2023 10:37:11 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Julian Waters 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:
>> 
>>   Revert NULL to nullptr changes in jaccesswalker
>
> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 547:
> 
>> 545:         snprintf( s, sizeof(s),
>> 546:             "ERROR calling GetAccessibleContextInfo; vmID = %lX, context = %p",
>> 547:             reinterpret_cast<unsigned long>(vmID), (void*)context );
> 
> do you need this cast? I checked a few compilers and passing a signed long to "%lX" was fine with them.

gcc will crash with a warning about a mismatched format specifier between signed and unsigned if this isn't done, unfortunately

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238560245

From djelinski at openjdk.org  Thu Jun 22 14:08:08 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 14:08:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
Message-ID: <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>

On Thu, 22 Jun 2023 13:48:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalker.cpp line 547:
>> 
>>> 545:         snprintf( s, sizeof(s),
>>> 546:             "ERROR calling GetAccessibleContextInfo; vmID = %lX, context = %p",
>>> 547:             reinterpret_cast<unsigned long>(vmID), (void*)context );
>> 
>> do you need this cast? I checked a few compilers and passing a signed long to "%lX" was fine with them.
>
> gcc will crash with a warning about a mismatched format specifier between signed and unsigned if this isn't done, unfortunately

Which gcc? This code compiles without warnings:

#include <stdio.h>
int main() {
	unsigned long i = 1;
	long j = 2;
	printf("%ld %ld %lx %lx %lu %lu\n", i, j, i, j, i, j);
	return 0;
}


# gcc -Wall -Wextra -Wformat=2 test.c
# gcc --version
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238581381

From jwaters at openjdk.org  Thu Jun 22 14:08:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:08:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
 <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
Message-ID: <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>

On Thu, 22 Jun 2023 14:03:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> gcc will crash with a warning about a mismatched format specifier between signed and unsigned if this isn't done, unfortunately
>
> Which gcc? This code compiles without warnings:
> 
> #include <stdio.h>
> int main() {
> 	unsigned long i = 1;
> 	long j = 2;
> 	printf("%ld %ld %lx %lx %lu %lu\n", i, j, i, j, i, j);
> 	return 0;
> }
> 
> 
> # gcc -Wall -Wextra -Wformat=2 test.c
> # gcc --version
> gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm currently running version 13.1, win32 threads

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238583171

From jwaters at openjdk.org  Thu Jun 22 14:08:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:08:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
 <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
 <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>
Message-ID: <KLua14_P7iE4kFBB41waVmAMt2rVgRjcxRdBWfzU9n0=.1b880f79-c5b7-4cac-b661-781820942795@github.com>

On Thu, 22 Jun 2023 14:04:48 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Which gcc? This code compiles without warnings:
>> 
>> #include <stdio.h>
>> int main() {
>> 	unsigned long i = 1;
>> 	long j = 2;
>> 	printf("%ld %ld %lx %lx %lu %lu\n", i, j, i, j, i, j);
>> 	return 0;
>> }
>> 
>> 
>> # gcc -Wall -Wextra -Wformat=2 test.c
>> # gcc --version
>> gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
>> Copyright (C) 2019 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I'm currently running version 13.1, win32 threads

I'll retry again, maybe the warning has changed now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238583800

From alanb at openjdk.org  Thu Jun 22 14:11:18 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 14:11:18 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <0FaGOzj9zoKyEI42aly13NmOAkyqNilHGwuQw0ZV3NE=.82ff1a28-e58f-44fd-b42d-4f4478659b7b@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14567#pullrequestreview-1493289444

From alanb at openjdk.org  Thu Jun 22 14:11:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 14:11:20 GMT
Subject: RFR: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <rphq_MlQL2R0113hDOlvM8ct7RX6lgAsC6IaCBF0-VY=.96a78550-038b-4526-ab75-db1187d8e288@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
 <CJIjOczqDb2lW0K2bwOAXal462WtcDN6EFRTHP6Orww=.752d8e2e-e1da-49d5-b060-fd227d7ee8a4@github.com>
 <pRSU6nrByPhQR9cHFdRohYAL-2vpBMsf5PH4Yc3MzNM=.86694ac5-5d83-49f7-bf22-1c11d893d291@github.com>
 <n3psAbThZxm_HLA2mV3-3lBX8_atRoRzBSJCufveEi0=.c971cf60-787f-4269-b0c0-f651b22fe3b1@github.com>
 <rphq_MlQL2R0113hDOlvM8ct7RX6lgAsC6IaCBF0-VY=.96a78550-038b-4526-ab75-db1187d8e288@github.com>
Message-ID: <S4lCYtGppdCUQdfXIOUoKcTqyqkHFaAI9LXt9bNYQKw=.e56dbf78-0e9c-4972-8cbd-e8154e5a9113@github.com>

On Wed, 21 Jun 2023 17:25:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This method has an existing apiNote and implSpec. I suspect Joe meant to add this sentence to the apiNote, not the implSpec.
>
> I did mean to add the cross-reference to Objects.toIdentityString to the implSpec section since earlier in the implSpec section the expression that is the basis for Objects.toIdentityString is listed.

okay

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14567#discussion_r1238587157

From jwaters at openjdk.org  Thu Jun 22 14:16:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:16:28 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v7]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <TiKwQn4BFEbgGVGbquO5kXLWYKBRkSMa-EbUYfapzeA=.67c866e2-cd36-4ad5-8657-c279b6cb783c@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert Cast

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/a31e52e9..775a3b05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From jwaters at openjdk.org  Thu Jun 22 14:16:29 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:16:29 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v6]
In-Reply-To: <KLua14_P7iE4kFBB41waVmAMt2rVgRjcxRdBWfzU9n0=.1b880f79-c5b7-4cac-b661-781820942795@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <KBTN5YxCFF-uCWegfXq-go_ayWHuivPhGW9hTZxcn6A=.259775c8-65c0-4c11-9ed1-b4074969966c@github.com>
 <HZKMwCuCqn06QXqEMhUdammgjfZDbS7oZ5NtxmhkGNM=.93e5e532-1fab-455c-a79c-99b4dabd572b@github.com>
 <PLUbL3gLmMQIMsdqqbN4zVauu7z-4q0MiHm6jYv-2Cs=.64f87b6f-4c82-4d6d-bb27-bf6f92ce6ca8@github.com>
 <4az-3bnmXmvuQ_p-IHOJCvxhpFaXNp0qG9REPV4j-4U=.b1439cea-de5d-4073-bdc3-b20aedf25347@github.com>
 <qC2IQQaLjzu7LhzBCsi34XDPeMjvr1L1ks70Ly0o-W0=.fa39d9f1-1ecf-44fa-889b-ff022f19144c@github.com>
 <KLua14_P7iE4kFBB41waVmAMt2rVgRjcxRdBWfzU9n0=.1b880f79-c5b7-4cac-b661-781820942795@github.com>
Message-ID: <SnWV2q5q5U2G1iTIwBbr3r35BiGG-8fR9Q1uS_SE2vg=.c222531c-9c48-424b-8ecc-ebb023fcb904@github.com>

On Thu, 22 Jun 2023 14:05:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm currently running version 13.1, win32 threads
>
> I'll retry again, maybe the warning has changed now

Seems like it doesn't trigger any longer, I'll revert the cast. Thanks for catching this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238589176

From alanb at openjdk.org  Thu Jun 22 14:23:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 14:23:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

src/java.sql/share/classes/java/sql/DriverManager.java line 658:

> 656:          * (which is invoking this class indirectly)
> 657:          * classloader, so that the JDBC driver class outside the image
> 658:          * can be loaded from here.

This code should probably be changed to use VM.isSystemDomainLoader(callerCL).

I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:

"If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238604300

From jwaters at openjdk.org  Thu Jun 22 14:23:25 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:23:25 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v8]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <IAOJn2EoSPkqO-q5Cc-8dmYMVr0vsAP2T3UAbrNkyG8=.21aa6964-17a7-48d0-bd27-59a4c0edc74b@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  GetDIBits should take an LPVOID

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/775a3b05..7dbe5dea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From jwaters at openjdk.org  Thu Jun 22 14:23:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:23:27 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v7]
In-Reply-To: <TiKwQn4BFEbgGVGbquO5kXLWYKBRkSMa-EbUYfapzeA=.67c866e2-cd36-4ad5-8657-c279b6cb783c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <TiKwQn4BFEbgGVGbquO5kXLWYKBRkSMa-EbUYfapzeA=.67c866e2-cd36-4ad5-8657-c279b6cb783c@github.com>
Message-ID: <hMZxQx2zyEyh5uT7Na5_ooQMJ_TSvyIy0MRQH8h-rGM=.1e352c44-f11d-4e18-984c-cf5725b20daf@github.com>

On Thu, 22 Jun 2023 14:16:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Cast

Alright, I've addressed the issues brought up by the reviews, including the GetDIBits cast. In general I left everything that passes into a Java call at least once as a jint, and everything else as a native type

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1602725175

From djelinski at openjdk.org  Thu Jun 22 14:32:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 14:32:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v8]
In-Reply-To: <IAOJn2EoSPkqO-q5Cc-8dmYMVr0vsAP2T3UAbrNkyG8=.21aa6964-17a7-48d0-bd27-59a4c0edc74b@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <IAOJn2EoSPkqO-q5Cc-8dmYMVr0vsAP2T3UAbrNkyG8=.21aa6964-17a7-48d0-bd27-59a4c0edc74b@github.com>
Message-ID: <XXA-qyko6Oj0RyHl-zp3zJodEfFZn8WZW8t2_g1aVRg=.96b142e9-cada-434b-98ee-076c7589fd07@github.com>

On Thu, 22 Jun 2023 14:23:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GetDIBits should take an LPVOID

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1089:

> 1087:                 entry_point();
> 1088:                 colorBits = (jint*)safe_Malloc(MAX_ICON_SIZE * MAX_ICON_SIZE * sizeof(jint));
> 1089:                 GetDIBits(dc, iconInfo.hbmColor, 0, iconSize, (LPVOID) colorBits, &bmi, DIB_RGB_COLORS);

I don't believe casting to LPVOID was what @prrace was asking here.
The function takes a void* parameter because any other pointer type is implicitly convertible to that. We are using long/int/jint because we're asking for 32 bits per pixel (see biBitCount above); if we asked for 24/16/8/any other number of bits per pixel, we would have used a different pointer type.
Please revert these casts. They don't add any value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238616005

From duke at openjdk.org  Thu Jun 22 14:36:14 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 22 Jun 2023 14:36:14 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v14]
In-Reply-To: <yYUOc9Y9ew3ypNpZSQDdi9j0eXQd4Ugr8iVHdWdQRpU=.8a8b1b3d-bffe-49ed-9653-1f72459763de@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <yYUOc9Y9ew3ypNpZSQDdi9j0eXQd4Ugr8iVHdWdQRpU=.8a8b1b3d-bffe-49ed-9653-1f72459763de@github.com>
Message-ID: <LHPAuNVnOLa8yW0XnmBzSJC4kCqG2ESzfqj93yQjPmY=.599a5acf-c21e-4f7b-84b4-39725df95f73@github.com>

On Thu, 22 Jun 2023 11:07:09 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ByteArray.setInt & setLong

Latest benchmark results:

Apple M1 (+190.26%):

  Benchmark   Mode  Cnt       Score      Error   Units
- UUID.test  thrpt    5   46247.050 ? 1088.442  ops/ms
+ UUID.test  thrpt    5  134235.336 ? 2759.236  ops/ms


Rockchip RK3588 (+103.49%):

  Benchmark   Mode  Cnt      Score    Error   Units
- UUID.test  thrpt    5  22024.693 ? 83.439  ops/ms
+ UUID.test  thrpt    5  44817.679 ? 148.068  ops/ms


AMD Ryzen 7 5800X (+17.58%):

  Benchmark   Mode  Cnt      Score      Error   Units
- UUID.test  thrpt    5  84113.600 ? 1831.692  ops/ms
+ UUID.test  thrpt    5  98897.952 ? 249.251  ops/ms


Intel Celeron N5105 (+31.18%):

  Benchmark   Mode  Cnt      Score     Error   Units
- UUID.test  thrpt    5  27068.861 ? 498.483  ops/ms
+ UUID.test  thrpt    5  35507.873 ? 343.376  ops/ms


Looks good, using `ByteArray` does bring a noticeable performance boost.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1602750203

From jwaters at openjdk.org  Thu Jun 22 14:40:23 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 14:40:23 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Revert "GetDIBits should take an LPVOID"
  
  This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/7dbe5dea..84f8e08c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From djelinski at openjdk.org  Thu Jun 22 14:53:05 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 14:53:05 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
Message-ID: <wL5gSu6BhEJorAIL9VTMsCTXIaenQPD51DI4pIZ_7SY=.5af8adb8-ffd1-4742-ab40-cbe933b19311@github.com>

On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "GetDIBits should take an LPVOID"
>   
>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

Thanks. The code changes look good to me now. Some of the files have old copyright, please update them to 2023 before integrating.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1493384042

From jwaters at openjdk.org  Thu Jun 22 15:12:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 22 Jun 2023 15:12:06 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
Message-ID: <WpbJshChwxooyzyQykysrl0zQGDPT5TuylUn8N4gCB8=.d792b7f7-2632-4bfd-a221-e08e250a5d50@github.com>

On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "GetDIBits should take an LPVOID"
>   
>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

Will do, thanks Daniel
@prrace @dholmes-ora Are both of you happy with the changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1602811926

From prappo at openjdk.org  Thu Jun 22 15:30:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 22 Jun 2023 15:30:04 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
Message-ID: <XPk6BzLiiBZjjkkdEhIG7GoBvcXKHQYdqHqGo8zeNVM=.dba5741d-40e4-4421-ad91-91a44cfa1614@github.com>

On Wed, 21 Jun 2023 00:13:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.
>
> src/java.base/share/classes/java/lang/Class.java line 818:
> 
>> 816:      * they represent, namely {@code boolean}, {@code byte},
>> 817:      * {@code char}, {@code short}, {@code int},
>> 818:      * {@code long}, {@code float}, and {@code double}.
> 
> Should we add `{@code void}` to the list here, as this is one of the primitive type names?

@liach please have a look at this intensive exchange between David Holmes (@dholmes-ora) and me: https://github.com/openjdk/jdk/pull/6213#issuecomment-960420076 That exchange relates to other keywords that might appear in plain (i.e. prose) font.

Speaking of which, I might still owe David a follow-up PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1238697667

From bpb at openjdk.org  Thu Jun 22 15:48:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 15:48:05 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
Message-ID: <Fhy1zVzeu2YCH9XjaVjQ1_w2GIFeIiuBapLid4bv9X4=.9172f26d-77ce-44e9-a898-0c192b83c0dc@github.com>

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

@stsypanov The description section of the issue JDK-8310530 should be filled out. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14589#issuecomment-1602877391

From dfuchs at openjdk.org  Thu Jun 22 16:21:04 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Jun 2023 16:21:04 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
Message-ID: <wCerxxKzXnL9s3aSGDA907FnbyIamFBHAwCdcmp7q4s=.f5d47d43-b0ef-4a20-919f-48e335db062b@github.com>

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14589#pullrequestreview-1493586839

From bpb at openjdk.org  Thu Jun 22 16:29:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 16:29:03 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
Message-ID: <SHMtOo1yX2IN1I0QSW-PGe01x3vouhthb7q-Bsltzcs=.b556fd38-5a2f-4389-9293-02b495b505f5@github.com>

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Change looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14589#pullrequestreview-1493600504

From rriggs at openjdk.org  Thu Jun 22 16:35:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 16:35:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v8]
In-Reply-To: <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <-iCQuZ9Sqjo59alu21EMx_UpRQyqDYrNZumWO-X38SU=.5e6e22df-4c70-4e47-b8e7-14e789b10d0a@github.com>
 <1GJTMznqC2a-9sxTsS5c2T1kY5zGGAk5cpvry0AhJww=.c22e3dd6-971f-4655-8fbc-c38b1f961606@github.com>
Message-ID: <NH5bfOLhTsSlbcXLWHIm0j2mNrtnBfi9SVLHyvZrzNQ=.aab3e6c2-8700-40bf-8098-094bdc0998f2@github.com>

On Thu, 22 Jun 2023 07:25:34 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix compile error
>
>> I've tested the benchmarks and the patch and baseline (with extra stable annotation) with a slightly varied version suitable for gradle run:
>> 
>> ```java
>> package com.alibaba.openjdk;
>> 
>> import org.openjdk.jmh.annotations.Benchmark;
>> import org.openjdk.jmh.annotations.BenchmarkMode;
>> 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.Warmup;
>> import org.openjdk.jmh.infra.Blackhole;
>> 
>> import java.util.UUID;
>> import java.util.concurrent.TimeUnit;
>> 
>> @BenchmarkMode(Mode.Throughput)
>> @OutputTimeUnit(TimeUnit.MILLISECONDS)
>> @Warmup(iterations = 3, time = 10)
>> @Measurement(iterations = 6, time = 5)
>> @Fork(1)
>> public class UUIDUtilsBenchmark {
>>     public static UUID uuid = UUID.randomUUID();
>> 
>>     @Benchmark
>>     public void jdk(Blackhole bh) {
>>         bh.consume(uuid.toString());
>>     }
>> 
>>     @Benchmark
>>     public void fast(Blackhole bh) {
>>         bh.consume(UUIDUtils.fastUUID(uuid));
>>     }
>> }
>> ```
>> 
>> The throughput varies a lot between iterations somehow; the patch and baseline with stable has no significant difference (i.e. within the error range, about 10%)
> 
> the performance of this improvement varies among different environments, with a significant improvement on the MacBookPro M1 Max chip (my laptop) and only about 10% improvement on Linux servers (Intel Xeon(Sapphire Rapids) Platinum and Aliyun Yitian 710 arm CPU and Orange Pi 5 Plus).

@wenshao Integration is only possible after Reviewers have approved; so far there it has not been "Approved".
It may be useful to re-read sections on developing a PR of the [OpenJDK developers guide](https://openjdk.org/guide/#life-of-a-pr).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1602979249

From darcy at openjdk.org  Thu Jun 22 16:41:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Jun 2023 16:41:10 GMT
Subject: Integrated: JDK-8310453: Update javadoc of java.lang.Object
In-Reply-To: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
References: <2Jm6L5WN6C-s9yPbSddKA0X6hRKJ6gCxBnqmXDus6sk=.22e5df79-7967-4783-94bc-dc837c0196d8@github.com>
Message-ID: <SePPo5s-ZFVd-MZem3LUskP0C9N6aXOxyyMoVtDykmY=.5052eab8-5fb5-40aa-91df-7d19e73e51cc@github.com>

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I had occasion to read over the javadoc sources in java.lang.Object recently and noticed a few items that could be updated.
> 
> There are some new or expanded API notes referring to methods in java.util.Objects. I added these references as apiNote items rather than, say, `@see` tags since  `@see` tag changes would propagate into classes that overrode the methods in questions.
> 
> Changing toString to use an inline `@return` tag has the consequence of omitting a trailing period, "." in the "Returns" section of its javadoc. This also omits  a trailing period in subclasses that use the `@return` statement of Object.toString in their own toString method. Likewise for hashCode.

This pull request has now been integrated.

Changeset: 0e4fde3d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0e4fde3d300b91e6f93fe4d602f99251c75aa847
Stats:     25 lines in 1 file changed: 11 ins; 1 del; 13 mod

8310453: Update javadoc of java.lang.Object

Reviewed-by: rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14567

From darcy at openjdk.org  Thu Jun 22 16:43:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 22 Jun 2023 16:43:04 GMT
Subject: [jdk21] RFR: 8309853: StructuredTaskScope.join description
 improvements
In-Reply-To: <HD17NbxnFPXZE3pIsn2hV37f0mQ9JFy1eEL5ZPcRk8Q=.93008e89-41c0-4265-a80b-67a249841d79@github.com>
References: <HD17NbxnFPXZE3pIsn2hV37f0mQ9JFy1eEL5ZPcRk8Q=.93008e89-41c0-4265-a80b-67a249841d79@github.com>
Message-ID: <hooxqIDV5IB0u31dT7WOfAwUj_ZaOvgRkUSWswm5ZcI=.beb6efab-3de5-469a-b92a-3c370637d850@github.com>

On Thu, 22 Jun 2023 10:45:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 8309853: StructuredTaskScope.join description improvements

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/55#pullrequestreview-1493621677

From mchung at openjdk.org  Thu Jun 22 16:52:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Jun 2023 16:52:06 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v7]
In-Reply-To: <D7w78I3nlSlnrWI6OmXLVaHECego-zfbfm42GLI6lEU=.27ca6641-a0e9-4873-a37b-e44afa659993@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
 <D7w78I3nlSlnrWI6OmXLVaHECego-zfbfm42GLI6lEU=.27ca6641-a0e9-4873-a37b-e44afa659993@github.com>
Message-ID: <A5vH0Nfln6ChLhzIddY5dZpH-O1JoqjPjBQ7FkMaKs4=.abb7c0ba-d89b-4ea6-9899-ca348702a57d@github.com>

On Thu, 22 Jun 2023 00:49:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/java.base/share/classes/java/lang/Class.java line 426:
> 
>> 424:     /**
>> 425:      * Returns the {@code Class} object associated with the class or
>> 426:      * interface with the given string name, using the given class loader.
> 
> Should we update the summary to `... associated with the class or interface or array with the given string name...`

I want to keep it as is.  The first paragraph talks about a class or interface and the other paragraphs talk about array classes, primitive types and hidden classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1238792840

From liach at openjdk.org  Thu Jun 22 17:19:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 Jun 2023 17:19:08 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v7]
In-Reply-To: <A5vH0Nfln6ChLhzIddY5dZpH-O1JoqjPjBQ7FkMaKs4=.abb7c0ba-d89b-4ea6-9899-ca348702a57d@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <GXd2Ro4ekFQevJBFt-v2yx6cJQlHVkIIWcQSjakKyk0=.4c5c3d1e-f409-44b1-b935-56e6199b8584@github.com>
 <D7w78I3nlSlnrWI6OmXLVaHECego-zfbfm42GLI6lEU=.27ca6641-a0e9-4873-a37b-e44afa659993@github.com>
 <A5vH0Nfln6ChLhzIddY5dZpH-O1JoqjPjBQ7FkMaKs4=.abb7c0ba-d89b-4ea6-9899-ca348702a57d@github.com>
Message-ID: <C496dN6SF5h9aPEGN5Kxh8BPtYIxQQgs3eO1A6GMzTQ=.da5397a9-04eb-4768-90ce-0a53f84a62d3@github.com>

On Thu, 22 Jun 2023 16:49:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 426:
>> 
>>> 424:     /**
>>> 425:      * Returns the {@code Class} object associated with the class or
>>> 426:      * interface with the given string name, using the given class loader.
>> 
>> Should we update the summary to `... associated with the class or interface or array with the given string name...`
>
> I want to keep it as is.  The first paragraph talks about a class or interface and the other paragraphs talk about array classes, primitive types and hidden classes.

Indeed, this API is more suited to classes and intefaces discovery, and array types should be obtained via `arrayType()`, which is somehow faster than a direct forName (as seen in my ClassDesc.resolveConstantDesc benchmarks)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14528#discussion_r1238821443

From asemenov at openjdk.org  Thu Jun 22 17:25:08 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 17:25:08 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v7]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <YFU72ByH9nRD1kcivWlr-gj7NifaytNn1zaYiCPJ7w4=.f751154b-aedc-4dfa-98b9-3c07b3027bf2@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/842d33d8..c4ca2205

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Thu Jun 22 17:25:10 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 17:25:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
Message-ID: <e_CKdXAilBPQu8gZ3d6XcuvG-5B7XGl6fb5gSevUjlw=.d286a23d-f504-454d-9611-7c6eb8c64084@github.com>

On Thu, 22 Jun 2023 09:58:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260:
> 
>> 258:         DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>> 259:         DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \
>> 260:         DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \
> 
> move this one closer to the other clang (non-aix) suppressions

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238824459

From mchung at openjdk.org  Thu Jun 22 17:47:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Jun 2023 17:47:16 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v8]
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14528/files
  - new: https://git.openjdk.org/jdk/pull/14528/files/852bd774..b7453f15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14528&range=06-07

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14528/head:pull/14528

PR: https://git.openjdk.org/jdk/pull/14528

From jlu at openjdk.org  Thu Jun 22 18:28:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:28:03 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>

On Thu, 22 Jun 2023 01:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

test/jdk/java/util/Locale/LocaleConstructors.java line 51:

> 49:     public void langTest() {
> 50:         Locale aLocale = Locale.of(LANG);
> 51:         Locale otherLocale = new Locale(LANG);

Is there a preference on testing code that is marked as `@deprecated` in the JDK? This test originally validated the parameters of the deprecated Locale constructor but was changed in 2022 with the Locale.of() method. However, the test was originally meant to test the constructor so I re-inserted it here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238889219

From bpb at openjdk.org  Thu Jun 22 18:30:13 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 18:30:13 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
Message-ID: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>

Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

-------------

Commit messages:
 - 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer

Changes: https://git.openjdk.org/jdk/pull/14616/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8222329
  Stats: 17 lines in 3 files changed: 9 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From lancea at openjdk.org  Thu Jun 22 18:34:03 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 18:34:03 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>
Message-ID: <qHlJqSbpWXiMHGXIFVlzEytrpvC0vMv3s-aVy5ZqwyI=.7590836e-5345-4f2d-bd1b-c9af114f1a6c@github.com>

On Thu, 22 Jun 2023 18:25:24 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
>> 
>> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
>> 
>> Below is a list of all the changes,
>> 
>> - Refactor Bug4316602.java as LocaleConstructors.java
>> - Refactor Bug4210525.java as CaseCheckVariant.java
>> - Refactor bug6277243.java as RootLocale.java
>> - Refactor bug6312358.java as GetInstanceCheck.java
>> - Refactor Bug8154797.java as CompareProviderFormats.java
>> - Refactor Bug8004240.java as GetAdapterPreference.java
>> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)
>
> test/jdk/java/util/Locale/LocaleConstructors.java line 51:
> 
>> 49:     public void langTest() {
>> 50:         Locale aLocale = Locale.of(LANG);
>> 51:         Locale otherLocale = new Locale(LANG);
> 
> Is there a preference on testing code that is marked as `@deprecated` in the JDK? This test originally validated the parameters of the deprecated Locale constructor but was changed in 2022 with the Locale.of() method. However, the test was originally meant to test the constructor so I re-inserted it here.

If the functionality still exists we should keep the existing test(s)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238894306

From lancea at openjdk.org  Thu Jun 22 18:38:03 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 18:38:03 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <gKWqR92gEv-2EG_F3W9y10ljpWKfdrRukPVYppE0CB4=.d7207626-9f86-4691-8ca1-4e59e1133e1e@github.com>

On Thu, 22 Jun 2023 01:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

test/jdk/java/util/Locale/LocaleConstructors.java line 56:

> 54:     }
> 55: 
> 56:     @Test

Minor, but please consider a simple comment describing the tests intent.  Just makes it easier for future developers...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238897495

From rriggs at openjdk.org  Thu Jun 22 18:47:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 18:47:05 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <--HiX2f-DnBZU-SbmoFv9daOhvtGMdkMxA2T5mZ74Wo=.43ec1ed2-541f-4f84-a558-9b955e378ba4@github.com>

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1493807999

From bpb at openjdk.org  Thu Jun 22 18:47:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 18:47:06 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <kAvOikNepo9-Hbl6hezAmU09e_J68Qix4BnO7Q2CYJQ=.2af8e278-0dc1-4221-8e9e-137f289eb39c@github.com>

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

CSR will be filed if consensus is reached here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14616#issuecomment-1603144256

From lancea at openjdk.org  Thu Jun 22 18:51:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 18:51:10 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com>

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

src/java.base/share/classes/java/lang/Readable.java line 49:

> 47:      * @param cb the buffer to read characters into
> 48:      * @return The number of {@code char} values added to the buffer,
> 49:      *         possibly zero, or -1 if this source of characters is at its end

Would it be clearer to specifically indicate 0 is returned when no characters will be read.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238906635

From jlu at openjdk.org  Thu Jun 22 18:55:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:55:31 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: Clarify LocaleConstructors.java with comment for each test method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14609/files
  - new: https://git.openjdk.org/jdk/pull/14609/files/02252fb5..63256db3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14609/head:pull/14609

PR: https://git.openjdk.org/jdk/pull/14609

From jlu at openjdk.org  Thu Jun 22 18:55:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:55:32 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <qHlJqSbpWXiMHGXIFVlzEytrpvC0vMv3s-aVy5ZqwyI=.7590836e-5345-4f2d-bd1b-c9af114f1a6c@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <ITX09ODwahJGWJ2arRKHETAk7Y3hJKVrEa7cb4iK86Y=.1f1c8d1a-3c31-4a89-9d49-b38962c4bbc5@github.com>
 <qHlJqSbpWXiMHGXIFVlzEytrpvC0vMv3s-aVy5ZqwyI=.7590836e-5345-4f2d-bd1b-c9af114f1a6c@github.com>
Message-ID: <Z7-9eG9QwfxTZfISAFMPhBzqGMYMxpD9n6-tbt-3Wpk=.37da95b5-d2a3-4531-8efd-e5053978649c@github.com>

On Thu, 22 Jun 2023 18:30:55 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/util/Locale/LocaleConstructors.java line 51:
>> 
>>> 49:     public void langTest() {
>>> 50:         Locale aLocale = Locale.of(LANG);
>>> 51:         Locale otherLocale = new Locale(LANG);
>> 
>> Is there a preference on testing code that is marked as `@deprecated` in the JDK? This test originally validated the parameters of the deprecated Locale constructor but was changed in 2022 with the Locale.of() method. However, the test was originally meant to test the constructor so I re-inserted it here.
>
> If the functionality still exists we should keep the existing test(s)

Got it, will leave it in then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238912827

From jlu at openjdk.org  Thu Jun 22 18:55:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 18:55:56 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <gKWqR92gEv-2EG_F3W9y10ljpWKfdrRukPVYppE0CB4=.d7207626-9f86-4691-8ca1-4e59e1133e1e@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <gKWqR92gEv-2EG_F3W9y10ljpWKfdrRukPVYppE0CB4=.d7207626-9f86-4691-8ca1-4e59e1133e1e@github.com>
Message-ID: <yxjKX0T-P_sF7iHbul4vQ5RidcC0xZ8kJQKx5Y4-Reg=.01d1cb00-a402-4d57-b528-43efb092757d@github.com>

On Thu, 22 Jun 2023 18:34:26 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Clarify LocaleConstructors.java with comment for each test method
>
> test/jdk/java/util/Locale/LocaleConstructors.java line 56:
> 
>> 54:     }
>> 55: 
>> 56:     @Test
> 
> Minor, but please consider a simple comment describing the tests intent.  Just makes it easier for future developers...

Had originally only included a blanket comment for the test class. Updated the file with a comment for each test method to clarify intent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238915682

From bpb at openjdk.org  Thu Jun 22 19:04:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 19:04:04 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com>
Message-ID: <rC8EjBJ0k4EaHVjBfR6BFWH7nZSz0XnZ3LDJSBuqAYA=.e1b0a001-3404-4e7d-a22d-9f98a16ab9e8@github.com>

On Thu, 22 Jun 2023 18:43:19 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
>
> src/java.base/share/classes/java/lang/Readable.java line 49:
> 
>> 47:      * @param cb the buffer to read characters into
>> 48:      * @return The number of {@code char} values added to the buffer,
>> 49:      *         possibly zero, or -1 if this source of characters is at its end
> 
> Would it be clearer to specifically indicate 0 is returned when no characters will be read.

Might be. I was mimicking the return specification from [FileChannel::read](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/channels/FileChannel.html#read(java.nio.ByteBuffer[],int,int)).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238922106

From rriggs at openjdk.org  Thu Jun 22 19:10:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 19:10:16 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation
Message-ID: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>

Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
The code is refactored in `compareInstant` to do the comparison of `LocalDateTime` exactly once, if it is needed.

This case is covered by existing tests in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

-------------

Commit messages:
 - 8310241: OffsetDateTime compareTo redundant computation

Changes: https://git.openjdk.org/jdk/pull/14618/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14618&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310241
  Stats: 19 lines in 1 file changed: 10 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14618/head:pull/14618

PR: https://git.openjdk.org/jdk/pull/14618

From mchung at openjdk.org  Thu Jun 22 19:14:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Jun 2023 19:14:10 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v8]
In-Reply-To: <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>
Message-ID: <U5FMhu1TtL3m8Monf_58r8tFDGvjQNRZc777GFoMUho=.00c8ef82-86b1-425e-ac8c-805746f3609f@github.com>

On Thu, 22 Jun 2023 17:47:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

I attached the specdiff to the [CSR](https://bugs.openjdk.org/browse/JDK-8310244) - please review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14528#issuecomment-1603184227

From naoto at openjdk.org  Thu Jun 22 19:15:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 19:15:09 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v2]
In-Reply-To: <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
Message-ID: <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>

On Thu, 22 Jun 2023 18:55:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
>> 
>> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
>> 
>> Below is a list of all the changes,
>> 
>> - Refactor Bug4316602.java as LocaleConstructors.java
>> - Refactor Bug4210525.java as CaseCheckVariant.java
>> - Refactor bug6277243.java as RootLocale.java
>> - Refactor bug6312358.java as GetInstanceCheck.java
>> - Refactor Bug8154797.java as CompareProviderFormats.java
>> - Refactor Bug8004240.java as GetAdapterPreference.java
>> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Clarify LocaleConstructors.java with comment for each test method

test/jdk/java/util/Locale/AvailableLocalesTest.java line 46:

> 44:     /**
> 45:      * Test that Locale.getAvailableLocales() is non-empty.
> 46:      * Print out the locales.

If you combine two tests into a single one, I'd put the corresponding bug id into the method description.

test/jdk/java/util/Locale/AvailableLocalesTest.java line 61:

> 59:      */
> 60:     @Test
> 61:     public void StreamEqualsArrayTest() {

Method names should start with a lowercase character

test/jdk/java/util/Locale/CaseCheckVariant.java line 50:

> 48:     @ParameterizedTest
> 49:     @MethodSource("variants")
> 50:     public void variantNormalizationTest(String variant) {

"Normalization" -> "Case"? Locale does not normalize the variant.

test/jdk/java/util/Locale/GetInstanceCheck.java line 79:

> 77:         } catch (InvocationTargetException | IllegalAccessException exc) {
> 78:             Throwable cause = exc.getCause();
> 79:             if (exc.getCause() instanceof NullPointerException) {

Should this condition only be meaningful for `InvocationTargetException`?

test/jdk/java/util/Locale/GetInstanceCheck.java line 99:

> 97:         } catch (InvocationTargetException | IllegalAccessException exc) {
> 98:             Throwable cause = exc.getCause();
> 99:             if (cause instanceof NullPointerException) {

Same as above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238910004
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238912059
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238915580
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238927882
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238927101

From lancea at openjdk.org  Thu Jun 22 19:19:03 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 19:19:03 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <nWItvzqX7FYDFFrDsXqFetPV108SMbSLmPgmWh9Co4o=.d969304b-cee8-4689-8370-b6194c5c42e0@github.com>

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1493850121

From lancea at openjdk.org  Thu Jun 22 19:19:05 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 22 Jun 2023 19:19:05 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <rC8EjBJ0k4EaHVjBfR6BFWH7nZSz0XnZ3LDJSBuqAYA=.e1b0a001-3404-4e7d-a22d-9f98a16ab9e8@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <0qt0-5OxclIB-R6IFDSukdPydvxwT_tmzn9tKizO-Hc=.b439df6c-1dde-4568-8440-46f7fa355f04@github.com>
 <rC8EjBJ0k4EaHVjBfR6BFWH7nZSz0XnZ3LDJSBuqAYA=.e1b0a001-3404-4e7d-a22d-9f98a16ab9e8@github.com>
Message-ID: <PfTLmZKa7TWFl2RB_Qd4msMHfMuG-5qVE6cGYeBkYQo=.ebeacee3-9a1e-4f88-8b4d-9fc335c1152b@github.com>

On Thu, 22 Jun 2023 19:00:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Readable.java line 49:
>> 
>>> 47:      * @param cb the buffer to read characters into
>>> 48:      * @return The number of {@code char} values added to the buffer,
>>> 49:      *         possibly zero, or -1 if this source of characters is at its end
>> 
>> Would it be clearer to specifically indicate 0 is returned when no characters will be read.
>
> Might be. I was mimicking the return specification from [FileChannel::read](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/channels/FileChannel.html#read(java.nio.ByteBuffer[],int,int)).

Consistency is probably good I guess in this case, though specifying `zero` vs `0` seems inconsistent when we specify `-1` as I believe this varies throughout the javadoc.  But it matches the other javadoc so we are at least consistent (somewhat )

OK for now by me

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238935203

From rriggs at openjdk.org  Thu Jun 22 19:24:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 19:24:37 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v6]
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Refactored test to make it easier to add new Architectures
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Remove duplicate import
 - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Correct handling of ppc64le/ppc64 using non-canonical architecture.
   Keep canonical architecture names for s390, amd/x86_64.
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Review suggestions
 - ... and 2 more: https://git.openjdk.org/jdk/compare/72501cf7...2e04a1ca

-------------

Changes: https://git.openjdk.org/jdk/pull/14063/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=05
  Stats: 191 lines in 5 files changed: 121 ins; 46 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From jlu at openjdk.org  Thu Jun 22 19:31:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 19:31:54 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v3]
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <gzx5pI7yecjkcBsdlnMywoZ0XjUt3izZC_-YQv4SZNs=.fa300a44-723b-4996-b2c8-ce2a341f0879@github.com>

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - Method signature is too long
 - Exceptions in GetInstanceCheck.java are distinct, catch clause should be reserved for the underlying exception
 - Rename method to be more clear in CaseCheckVariant.java
 - Method name case in AvailableLocalesTest.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14609/files
  - new: https://git.openjdk.org/jdk/pull/14609/files/63256db3..c84b3ea0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=01-02

  Stats: 10 lines in 3 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14609/head:pull/14609

PR: https://git.openjdk.org/jdk/pull/14609

From jlu at openjdk.org  Thu Jun 22 19:32:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 19:32:00 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v3]
In-Reply-To: <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
 <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
Message-ID: <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>

On Thu, 22 Jun 2023 18:47:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Method signature is too long
>>  - Exceptions in GetInstanceCheck.java are distinct, catch clause should be reserved for the underlying exception
>>  - Rename method to be more clear in CaseCheckVariant.java
>>  - Method name case in AvailableLocalesTest.java
>
> test/jdk/java/util/Locale/AvailableLocalesTest.java line 46:
> 
>> 44:     /**
>> 45:      * Test that Locale.getAvailableLocales() is non-empty.
>> 46:      * Print out the locales.
> 
> If you combine two tests into a single one, I'd put the corresponding bug id into the method description.

Unless I am mistaken, both bug IDs, 4122700 8282319 are in the combined file.

> test/jdk/java/util/Locale/AvailableLocalesTest.java line 61:
> 
>> 59:      */
>> 60:     @Test
>> 61:     public void StreamEqualsArrayTest() {
> 
> Method names should start with a lowercase character

Missed that, thank you.

> test/jdk/java/util/Locale/CaseCheckVariant.java line 50:
> 
>> 48:     @ParameterizedTest
>> 49:     @MethodSource("variants")
>> 50:     public void variantNormalizationTest(String variant) {
> 
> "Normalization" -> "Case"? Locale does not normalize the variant.

That's a better name, fixed.

> test/jdk/java/util/Locale/GetInstanceCheck.java line 79:
> 
>> 77:         } catch (InvocationTargetException | IllegalAccessException exc) {
>> 78:             Throwable cause = exc.getCause();
>> 79:             if (exc.getCause() instanceof NullPointerException) {
> 
> Should this condition only be meaningful for `InvocationTargetException`?

Yes you're right, that's a good point. Reserved the catch clause to handle `InvocationTargetException` and moved `IllegalAccessException` to the method signature.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238940849
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238940976
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238941073
PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238942899

From bpb at openjdk.org  Thu Jun 22 19:42:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 19:42:02 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

src/java.base/share/classes/java/io/Reader.java line 193:

> 191:      * changes made are the results of a put operation. No flipping or
> 192:      * rewinding of the buffer is performed.  If the specified character
> 193:      * buffer is full, then no characters will be read and zero will be

Instead of "is full" here, it would be more consistent to state "has no remaining elements".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1238953679

From naoto at openjdk.org  Thu Jun 22 20:05:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 20:05:03 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v3]
In-Reply-To: <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
 <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
 <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>
Message-ID: <Ssd7DqSXJd_RAMSz7dKRZvYjQwFUw-RzJCAaQGLiQTE=.cb210d3a-00b7-4c89-82c3-8a328b7137d6@github.com>

On Thu, 22 Jun 2023 19:23:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/util/Locale/AvailableLocalesTest.java line 46:
>> 
>>> 44:     /**
>>> 45:      * Test that Locale.getAvailableLocales() is non-empty.
>>> 46:      * Print out the locales.
>> 
>> If you combine two tests into a single one, I'd put the corresponding bug id into the method description.
>
> Unless I am mistaken, both bug IDs, 4122700 8282319 are in the combined file.

Yes. I wanted to make it clear that this `nonEmptyLocalesTest` was for the issue 4122700.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1238975301

From aivanov at openjdk.org  Thu Jun 22 20:08:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:08:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
Message-ID: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>

On Thu, 22 Jun 2023 14:40:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "GetDIBits should take an LPVOID"
>   
>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.

Looks fine to me, except for a few comments.

The size of the types for `jint` and `jlong` remains the same after amending the typedef `jni_md.h`. Yet I'm still cautious about it. You should have an approval from hotspot.

Please also update the copyright year in the modified files.

src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325:

> 323:     }
> 324: 
> 325:     jint sx, sy, ex, ey;

I agree with David, these should have type `int` as accepted by the [`::Arc`](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-arc) function. However, the `AngleToCoord` function is declared with `jint` as parameters.

https://github.com/openjdk/jdk/blob/84f8e08c2ecc90ec50a13406fb99b8cd52f33b7c/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp#L52

Its declaration can be changed to `int`, it's an internal function used by `*_doDrawArc` and `*_doFillArc`.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1084:

> 1082: 
> 1083:             jint *colorBits = nullptr;
> 1084:             int *maskBits = nullptr;

Suggestion:

            jint *colorBits = NULL;
            int *maskBits = NULL;

I'd rather keep `NULL` ? it's used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through the file, so `nullptr` is out of place.

src/java.desktop/windows/native/libawt/windows/awt_MenuBar.cpp line 148:

> 146: }
> 147: 
> 148: AwtMenuItem* AwtMenuBar::GetItem(jobject target, jint index)

What is the reason for using `jint` instead of `int`?

The member function is used in for-loop which iterates with `int` loop variable. Yet the implementation of `GetItem` up-calls into Java.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1493854643
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238938194
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238948758
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238966069

From aivanov at openjdk.org  Thu Jun 22 20:08:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:08:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
Message-ID: <bmuXFOkDVcPKND-6UY0HtmWSgTGFkV2ZE6cmq9afUg8=.56d102fd-0f60-444f-9d3d-bf44ff33a753@github.com>

On Thu, 25 May 2023 01:30:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605:
> 
>> 603:         return;
>> 604:     }
>> 605:     jint sx, sy, ex, ey;
> 
> Again these don't seem to need to be Java types.

I've got the same concern.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238941743

From aivanov at openjdk.org  Thu Jun 22 20:08:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 22 Jun 2023 20:08:12 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
Message-ID: <lmxDNCQoRxmSz2_OlPXr_ILPqN8x6ZP8IifLAknBOr0=.77f84222-eb0f-46a1-afe1-809864f3f4ab@github.com>

On Thu, 22 Jun 2023 19:33:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1084:
> 
>> 1082: 
>> 1083:             jint *colorBits = nullptr;
>> 1084:             int *maskBits = nullptr;
> 
> Suggestion:
> 
>             jint *colorBits = NULL;
>             int *maskBits = NULL;
> 
> I'd rather keep `NULL` ? it's used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through the file, so `nullptr` is out of place.

The type of `colorBits` is `jint` because it's set to `iconBits` array, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1238952370

From stsypanov at openjdk.org  Thu Jun 22 20:17:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 22 Jun 2023 20:17:05 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <Fhy1zVzeu2YCH9XjaVjQ1_w2GIFeIiuBapLid4bv9X4=.9172f26d-77ce-44e9-a898-0c192b83c0dc@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
 <Fhy1zVzeu2YCH9XjaVjQ1_w2GIFeIiuBapLid4bv9X4=.9172f26d-77ce-44e9-a898-0c192b83c0dc@github.com>
Message-ID: <KG6fbJ5GZYlXPvI8hAmiy3HoebIuYyMKig7NVWC-sWY=.535fa6c1-de20-47e8-a718-7c9646d52f67@github.com>

On Thu, 22 Jun 2023 15:45:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> @stsypanov The description section of the issue JDK-8310530 should be filled out. Thanks.

@bplb done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14589#issuecomment-1603255772

From bpb at openjdk.org  Thu Jun 22 20:17:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 20:17:06 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <Fhy1zVzeu2YCH9XjaVjQ1_w2GIFeIiuBapLid4bv9X4=.9172f26d-77ce-44e9-a898-0c192b83c0dc@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
 <Fhy1zVzeu2YCH9XjaVjQ1_w2GIFeIiuBapLid4bv9X4=.9172f26d-77ce-44e9-a898-0c192b83c0dc@github.com>
Message-ID: <iDU48NmRJtTeBlz7aaLu9ubCPNUS411JQ4tDd-Y4Zsc=.aff00c86-831c-47d0-a5c7-079d8840176f@github.com>

On Thu, 22 Jun 2023 15:45:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> @stsypanov The description section of the issue JDK-8310530 should be filled out. Thanks.

> @bplb done

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14589#issuecomment-1603257241

From bpb at openjdk.org  Thu Jun 22 20:34:21 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 20:34:21 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v2]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <Kk1yGamBOyMr_o06QW5PprSb98vCXHwrDL0iayKIPAg=.19f3e1fb-1748-4db8-9fa5-d34764c52dc5@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: rephrase "full" to "no elements remaining"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/0fb2bf1f..ef650028

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=00-01

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From jlu at openjdk.org  Thu Jun 22 20:41:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 20:41:33 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v4]
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <n1c2unCuic0dyggqsYeHb2dpZqke-pzTsbnheAtt48c=.1b0ca0a9-ccb1-4f25-8df4-3b13472cac79@github.com>

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Put Bug ID in method description of nonEmptyLocalesTest()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14609/files
  - new: https://git.openjdk.org/jdk/pull/14609/files/c84b3ea0..ce80e777

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14609&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14609/head:pull/14609

PR: https://git.openjdk.org/jdk/pull/14609

From jlu at openjdk.org  Thu Jun 22 20:41:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 Jun 2023 20:41:33 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v4]
In-Reply-To: <Ssd7DqSXJd_RAMSz7dKRZvYjQwFUw-RzJCAaQGLiQTE=.cb210d3a-00b7-4c89-82c3-8a328b7137d6@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <1w8jezZSPe8-n7t0ExaVU_K5yQk6UzifKqSHpg0ETjQ=.6dd450c6-fad3-4764-bf8d-b4878e35f5d5@github.com>
 <DSaTfE2i6VQhPcdDlyDhKGRBtkMrnmWQFesL3nw2laY=.787a1c4e-a683-4cbf-87ea-fcaf70cc8bb9@github.com>
 <bMq3eb2s4qHWSLb8HYplxQnZdKZo1istK0kVFKfWy4w=.5c6c7363-c406-43b7-98f6-704cdf1bdb15@github.com>
 <Ssd7DqSXJd_RAMSz7dKRZvYjQwFUw-RzJCAaQGLiQTE=.cb210d3a-00b7-4c89-82c3-8a328b7137d6@github.com>
Message-ID: <x1TPZBsvyYoJHEO26oW_MEHSpk_nhflKyxOa46Abv8Q=.d4e9a9db-ad89-4e39-91b3-e9973e68994c@github.com>

On Thu, 22 Jun 2023 20:02:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Unless I am mistaken, both bug IDs, 4122700 8282319 are in the combined file.
>
> Yes. I wanted to make it clear that this `nonEmptyLocalesTest` was for the issue 4122700.

Sorry, I totally misread you said 'method'. Fixed `nonEmptyLocalesTest` to include the bug ID.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14609#discussion_r1239007083

From naoto at openjdk.org  Thu Jun 22 20:44:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 20:44:05 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash
Message-ID: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>

Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

-------------

Commit messages:
 - 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

Changes: https://git.openjdk.org/jdk/pull/14620/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14620&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310182
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14620/head:pull/14620

PR: https://git.openjdk.org/jdk/pull/14620

From rriggs at openjdk.org  Thu Jun 22 20:54:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 20:54:03 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash
In-Reply-To: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
Message-ID: <arE-d-B5YAOu6rX3a2dM3dnbnQhW_xnEXTOh6zJjiTo=.8fe3a13c-546a-4b94-87dc-cfed898897cd@github.com>

On Thu, 22 Jun 2023 20:36:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

Correcting the description of the delimiter seems like the best solution.

As a doc-only change it would also be appropriate for JDK 21 also.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1493979047
PR Comment: https://git.openjdk.org/jdk/pull/14620#issuecomment-1603298580

From rriggs at openjdk.org  Thu Jun 22 21:03:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 21:03:06 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
Message-ID: <X9FA6RfLU94i82-YlReox6-ulhoCAS4ywd915GSzlqc=.9dfbe743-fbfa-48d0-927d-f41a6f91e242@github.com>

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

I think the bug description should include a bit more detail along the lines that since the method reading and writing are synchronized, its not really a racy read. It does avoid reading the volatile value twice (a relatively expensive operation).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14589#issuecomment-1603308404

From duke at openjdk.org  Thu Jun 22 21:17:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 21:17:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v15]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <y9Safabq6dEkmXEVBkzC6jWxcjwymK3sGO7X-gLm_3s=.d306c64e-f397-4939-9e27-e0d3a4ddb40c@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  make fastUUID codeSize less than 325 (FreqInlineSize)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/5a5e7e12..c11668c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=13-14

  Stats: 82 lines in 1 file changed: 52 ins; 20 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From rriggs at openjdk.org  Thu Jun 22 21:25:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 21:25:04 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v2]
In-Reply-To: <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>
Message-ID: <icmT4Q3H5899yNDiVhLYOlWKftRD0MXhQ22gKDPsQ2E=.4b4a18cc-1e82-494c-92d8-e358096bc8d9@github.com>

On Thu, 22 Jun 2023 19:39:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8222329: rephrase "full" to "no elements remaining"
>
> src/java.base/share/classes/java/io/Reader.java line 193:
> 
>> 191:      * changes made are the results of a put operation. No flipping or
>> 192:      * rewinding of the buffer is performed.  If the specified character
>> 193:      * buffer is full, then no characters will be read and zero will be
> 
> Instead of "is full" here, it would be more consistent to state "has no remaining elements".

For a buffer that is being written into, it sounds a bit odd to say "no remaining elements"; that phrasing is ok for reading/getting bytes but doesn't sound like there's free space to put anything.

Would "no remaining free elements" or "no remaining available elements" be better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239042484

From duke at openjdk.org  Thu Jun 22 21:25:15 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 21:25:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v16]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <vxP9amy4iU266b4FJo3Qme-HE97Az8YigPb4uoB8OWQ=.b4780009-40ad-447e-a032-a71cfe1192fd@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  add import & rename HEX to H256

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/c11668c4..2b35aa42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=14-15

  Stats: 34 lines in 1 file changed: 1 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From bpb at openjdk.org  Thu Jun 22 21:28:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 21:28:04 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v2]
In-Reply-To: <icmT4Q3H5899yNDiVhLYOlWKftRD0MXhQ22gKDPsQ2E=.4b4a18cc-1e82-494c-92d8-e358096bc8d9@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>
 <icmT4Q3H5899yNDiVhLYOlWKftRD0MXhQ22gKDPsQ2E=.4b4a18cc-1e82-494c-92d8-e358096bc8d9@github.com>
Message-ID: <Hxx2YdBGLXJYbMYaRV66UaKKHaNuQB_0Iadb9EQajIo=.36f87ce0-ebe8-49fe-83ca-ee3566d97de5@github.com>

On Thu, 22 Jun 2023 21:21:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 193:
>> 
>>> 191:      * changes made are the results of a put operation. No flipping or
>>> 192:      * rewinding of the buffer is performed.  If the specified character
>>> 193:      * buffer is full, then no characters will be read and zero will be
>> 
>> Instead of "is full" here, it would be more consistent to state "has no remaining elements".
>
> For a buffer that is being written into, it sounds a bit odd to say "no remaining elements"; that phrasing is ok for reading/getting bytes but doesn't sound like there's free space to put anything.
> 
> Would "no remaining free elements" or "no remaining available elements" be better?

Or "no remaining space" / "no space remaining"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239045510

From naoto at openjdk.org  Thu Jun 22 21:36:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 Jun 2023 21:36:04 GMT
Subject: RFR: 8310234: Refactor Locale tests to use JUnit [v4]
In-Reply-To: <n1c2unCuic0dyggqsYeHb2dpZqke-pzTsbnheAtt48c=.1b0ca0a9-ccb1-4f25-8df4-3b13472cac79@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
 <n1c2unCuic0dyggqsYeHb2dpZqke-pzTsbnheAtt48c=.1b0ca0a9-ccb1-4f25-8df4-3b13472cac79@github.com>
Message-ID: <52hTkD0Tw2c4zRPGgU02Jy_TL0seWHgxhO9rgzWZbdc=.749579d4-edd4-4407-8063-bf09f5cc81dd@github.com>

On Thu, 22 Jun 2023 20:41:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
>> 
>> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
>> 
>> Below is a list of all the changes,
>> 
>> - Refactor Bug4316602.java as LocaleConstructors.java
>> - Refactor Bug4210525.java as CaseCheckVariant.java
>> - Refactor bug6277243.java as RootLocale.java
>> - Refactor bug6312358.java as GetInstanceCheck.java
>> - Refactor Bug8154797.java as CompareProviderFormats.java
>> - Refactor Bug8004240.java as GetAdapterPreference.java
>> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put Bug ID in method description of nonEmptyLocalesTest()

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14609#pullrequestreview-1494026613

From rriggs at openjdk.org  Thu Jun 22 21:41:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 22 Jun 2023 21:41:03 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v2]
In-Reply-To: <Hxx2YdBGLXJYbMYaRV66UaKKHaNuQB_0Iadb9EQajIo=.36f87ce0-ebe8-49fe-83ca-ee3566d97de5@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>
 <icmT4Q3H5899yNDiVhLYOlWKftRD0MXhQ22gKDPsQ2E=.4b4a18cc-1e82-494c-92d8-e358096bc8d9@github.com>
 <Hxx2YdBGLXJYbMYaRV66UaKKHaNuQB_0Iadb9EQajIo=.36f87ce0-ebe8-49fe-83ca-ee3566d97de5@github.com>
Message-ID: <BsAiZQec9Gi0V8O4ZWM3e5uIQpWQ9q4P1ARtZ5Dm3XE=.6d260163-baa9-43a4-ad77-3eb69b3f87d8@github.com>

On Thu, 22 Jun 2023 21:25:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a buffer that is being written into, it sounds a bit odd to say "no remaining elements"; that phrasing is ok for reading/getting bytes but doesn't sound like there's free space to put anything.
>> 
>> Would "no remaining free elements" or "no remaining available elements" be better?
>
> Or "no remaining space" / "no space remaining"?

I have a slight preference for "no space remaining"; remaining can still be a linkplain to the method if that helps it be specific.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239054873

From duke at openjdk.org  Thu Jun 22 21:44:12 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 21:44:12 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v17]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <exlqqXQRTFOkZ339TAne9PSAiApiivOC_NS4fFSxaVw=.f91b163e-40b6-48f6-aa53-0d35ae185bbf@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/2b35aa42..ff6e7e4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=15-16

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From smarks at openjdk.org  Thu Jun 22 22:07:19 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Jun 2023 22:07:19 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements [v2]
In-Reply-To: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
Message-ID: <SsNbvnJT-hBYoXxzwgz3efsfrHTwnXOm1rYzOUjTb08=.3a0f171c-a9c1-40c0-8b83-2971dea6fbfd@github.com>

> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Update to avoid overspecification.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14504/files
  - new: https://git.openjdk.org/jdk/pull/14504/files/5981ca83..0a8b769f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14504&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14504&range=00-01

  Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14504/head:pull/14504

PR: https://git.openjdk.org/jdk/pull/14504

From smarks at openjdk.org  Thu Jun 22 22:07:21 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Jun 2023 22:07:21 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements
In-Reply-To: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
Message-ID: <snz_CfLy_YKYDA5vNLHV2iRMFWhQ-yTI1ffPKt6nvy0=.04253b9b-3190-4673-9655-84ff0296fe4c@github.com>

On Thu, 15 Jun 2023 22:38:43 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.

OK please take another look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14504#issuecomment-1603370734

From smarks at openjdk.org  Thu Jun 22 22:11:08 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 22 Jun 2023 22:11:08 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <AVhPpcKvxTCHsZXzE3QwbUbFIRXMV2Mt7oa-ckfPXD0=.37205594-4e2e-4629-9450-6a635b0f99fd@github.com>

On Fri, 7 Apr 2023 12:22:03 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734

OK. Feel free to discuss things here before trying to wordsmith the CSR. It's probably easier to discuss and get agreement on a sketch of a solution before trying to commit the solution to words in the specification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1603375418

From duke at openjdk.org  Thu Jun 22 22:16:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 22 Jun 2023 22:16:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v17]
In-Reply-To: <exlqqXQRTFOkZ339TAne9PSAiApiivOC_NS4fFSxaVw=.f91b163e-40b6-48f6-aa53-0d35ae185bbf@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <exlqqXQRTFOkZ339TAne9PSAiApiivOC_NS4fFSxaVw=.f91b163e-40b6-48f6-aa53-0d35ae185bbf@github.com>
Message-ID: <_hdayirrO6KTRVIpucLMsALsUUPJMoj5mHQqKKE9g7Q=.814dfbb3-a236-46f6-b00b-2cc29f892ee9@github.com>

On Thu, 22 Jun 2023 21:44:12 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format code

Latest benchmark results:

* aliyun_c8i.xlarge (+23.25%)
cpu intel xeon sapphire rapids (x64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
+UUIDBench.toString   20000  thrpt   15  76.979 ? 1.011  ops/us


* aliyun_c8a.xlarge (+29.93%)
cpu amd epc genoa (x64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
+UUIDBench.toString   20000  thrpt   15  85.331 ? 0.181  ops/us


* aliyun_c8y.xlarge (+29.06%)
cpu aliyun yitian 710 (aarch64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
+UUIDBench.toString   20000  thrpt   15  41.555 ? 0.963  ops/us


* aws_c5.xlarge (+35.29%)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
+UUIDBench.toString   20000  thrpt   15  62.239 ? 0.072  ops/us

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1603379671

From bpb at openjdk.org  Thu Jun 22 22:18:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 22:18:03 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v2]
In-Reply-To: <BsAiZQec9Gi0V8O4ZWM3e5uIQpWQ9q4P1ARtZ5Dm3XE=.6d260163-baa9-43a4-ad77-3eb69b3f87d8@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>
 <icmT4Q3H5899yNDiVhLYOlWKftRD0MXhQ22gKDPsQ2E=.4b4a18cc-1e82-494c-92d8-e358096bc8d9@github.com>
 <Hxx2YdBGLXJYbMYaRV66UaKKHaNuQB_0Iadb9EQajIo=.36f87ce0-ebe8-49fe-83ca-ee3566d97de5@github.com>
 <BsAiZQec9Gi0V8O4ZWM3e5uIQpWQ9q4P1ARtZ5Dm3XE=.6d260163-baa9-43a4-ad77-3eb69b3f87d8@github.com>
Message-ID: <VL1YCVbMYhqs9NWT8MpYXfAGcCg3s64oO7cvuVakfqI=.ba203d00-1fdf-4562-a7f6-acb41457b1ab@github.com>

On Thu, 22 Jun 2023 21:38:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Or "no remaining space" / "no space remaining"?
>
> I have a slight preference for "no space remaining"; remaining can still be a linkplain to the method if that helps it be specific.

I concur. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239080155

From bpb at openjdk.org  Thu Jun 22 22:24:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 22:24:23 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v3]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <y92tH0S00AxveWtmQmCB5lYJPDwKRJriGptpHpJutS8=.cecb89f4-416d-4d88-aaaa-dd31740db62b@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: "elements remaining" -> "space remaining"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/ef650028..055107bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From bpb at openjdk.org  Thu Jun 22 22:52:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Jun 2023 22:52:23 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v4]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: Correct return verbiage of Reader and CharBuffer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/055107bd..d693c612

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From jwaters at openjdk.org  Fri Jun 23 00:16:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:16:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
Message-ID: <SEwBNPhlLxpGAitn9_yJHWn49VLebp4u12GgCuA2nJo=.21af475d-a44a-4c54-8a50-fbfda5e8bf28@github.com>

On Thu, 22 Jun 2023 19:20:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325:
> 
>> 323:     }
>> 324: 
>> 325:     jint sx, sy, ex, ey;
> 
> I agree with David, these should have type `int` as accepted by the [`::Arc`](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-arc) function. However, the `AngleToCoord` function is declared with `jint` as parameters.
> 
> https://github.com/openjdk/jdk/blob/84f8e08c2ecc90ec50a13406fb99b8cd52f33b7c/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp#L52
> 
> Its declaration can be changed to `int`, it's an internal function used by `*_doDrawArc` and `*_doFillArc`.

Resolved, will push soon

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239142969

From jwaters at openjdk.org  Fri Jun 23 00:16:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:16:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <bmuXFOkDVcPKND-6UY0HtmWSgTGFkV2ZE6cmq9afUg8=.56d102fd-0f60-444f-9d3d-bf44ff33a753@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
 <bmuXFOkDVcPKND-6UY0HtmWSgTGFkV2ZE6cmq9afUg8=.56d102fd-0f60-444f-9d3d-bf44ff33a753@github.com>
Message-ID: <9RJ8-w0M5_3QeoXfshnOhtwVvi7g89XaOH35RTFKIZg=.8b19b043-0b16-4f28-a124-22ee2e644940@github.com>

On Thu, 22 Jun 2023 19:24:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605:
>> 
>>> 603:         return;
>>> 604:     }
>>> 605:     jint sx, sy, ex, ey;
>> 
>> Again these don't seem to need to be Java types.
>
> I've got the same concern.

Resolved, pushing soon

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239143080

From jwaters at openjdk.org  Fri Jun 23 00:16:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:16:13 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <lmxDNCQoRxmSz2_OlPXr_ILPqN8x6ZP8IifLAknBOr0=.77f84222-eb0f-46a1-afe1-809864f3f4ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
 <lmxDNCQoRxmSz2_OlPXr_ILPqN8x6ZP8IifLAknBOr0=.77f84222-eb0f-46a1-afe1-809864f3f4ab@github.com>
Message-ID: <f4yYWXUYsev-Ftn2ESAWjF1QXnW8K2pmL204ZkFcoIo=.492c1ac4-6190-4774-afcc-6aa272534c5d@github.com>

On Thu, 22 Jun 2023 19:37:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1084:
>> 
>>> 1082: 
>>> 1083:             jint *colorBits = nullptr;
>>> 1084:             int *maskBits = nullptr;
>> 
>> Suggestion:
>> 
>>             jint *colorBits = NULL;
>>             int *maskBits = NULL;
>> 
>> I'd rather keep `NULL` ? it's used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through the file, so `nullptr` is out of place.
>
> The type of `colorBits` is `jint` because it's set to `iconBits` array, right?

Yes, colorBits is a jint because of that

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239143202

From jwaters at openjdk.org  Fri Jun 23 00:19:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:19:18 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
Message-ID: <42a4Nj_iDfQRh-eOXo4PSl7eag1EVv9JW1y2Uvqt2vg=.1dac1318-9637-46f5-9c40-f090c9e2640e@github.com>

On Thu, 22 Jun 2023 19:51:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "GetDIBits should take an LPVOID"
>>   
>>   This reverts commit 7dbe5dea84b1afb2235b66da581bcd3c1da4d6ac.
>
> src/java.desktop/windows/native/libawt/windows/awt_MenuBar.cpp line 148:
> 
>> 146: }
>> 147: 
>> 148: AwtMenuItem* AwtMenuBar::GetItem(jobject target, jint index)
> 
> What is the reason for using `jint` instead of `int`?
> 
> The member function is used in for-loop which iterates with `int` loop variable. Yet the implementation of `GetItem` up-calls into Java.

I had it as a jint since it upcalls into Java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239144537

From jwaters at openjdk.org  Fri Jun 23 00:31:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 00:31:28 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v10]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Fixups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/84f8e08c..80b6f787

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=08-09

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From liach at openjdk.org  Fri Jun 23 00:37:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jun 2023 00:37:22 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
Message-ID: <liRljkajQRZqaszJrh1Hvcf0vZR8IqnzU4K07gIMPE0=.59ad0ac4-46aa-4973-9e3f-ffcdf1093148@github.com>

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14589#pullrequestreview-1494165520

From duke at openjdk.org  Fri Jun 23 00:43:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 23 Jun 2023 00:43:13 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v18]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <aFxOD2-fIaYpyo25vJXa5N5Gr_z2yA3tKIOkG2PosX0=.6c9428e0-98e3-4f53-a28e-79fab12e10e6@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  remove Arrays.fill

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/ff6e7e4d..27a82129

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=16-17

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From liach at openjdk.org  Fri Jun 23 01:16:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jun 2023 01:16:05 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v8]
In-Reply-To: <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>
Message-ID: <Bn0iPS5zl_jj0IahAMTRLCjwDB_XmFDV0crCMPa81mg=.cc966547-7f78-41a3-91d4-c5ce6f8c8409@github.com>

On Thu, 22 Jun 2023 17:47:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1494187389

From dholmes at openjdk.org  Fri Jun 23 02:08:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Jun 2023 02:08:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v10]
In-Reply-To: <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
Message-ID: <uXV4ZGxEPEhLn8yhnI7PmiPWgm9pSOpouoSIXyq2enQ=.617f49c8-4ba0-4e61-9775-58702fbb1ed0@github.com>

On Fri, 23 Jun 2023 00:31:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

Hotspot changes still approved.

Other changes seem okay to me.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1494291399

From jwaters at openjdk.org  Fri Jun 23 02:12:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:12:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v10]
In-Reply-To: <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <s7h5Yy1iybAw4CfXR2pCE_5SllL_uDwmMy-kaoLaWA0=.9b753e18-3073-4a68-9903-6315b2cccd5c@github.com>
Message-ID: <v8-gfGamUHAsZgiQ8bo2lEVlI2pF8KeVfCdY0qrkjqQ=.4df0a245-cefa-4be8-ab16-990039ae0c9d@github.com>

On Fri, 23 Jun 2023 00:31:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixups

Alright, I'll integrate once Alexsey approve, anyone else has further objections?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1603594332

From jwaters at openjdk.org  Fri Jun 23 02:29:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:29:07 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v5]
In-Reply-To: <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>
Message-ID: <eEbDYpSwsLcib5N30VkZvRcHoIpGzQPSs3o4BVhzsuw=.f3f36344-3e98-4bd9-99b2-c03a2f76eb0a@github.com>

On Tue, 20 Jun 2023 07:20:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Whitespace
>  - Revert
>  - _MSC_VER

@djelinski Sorry for the tag, it's just that this PR has been collecting dust for months now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1603602062

From jwaters at openjdk.org  Fri Jun 23 02:38:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:38:13 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Revert wrong Copyright
 - Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/80b6f787..16b5a914

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=09-10

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From liach at openjdk.org  Fri Jun 23 02:42:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jun 2023 02:42:21 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v7]
In-Reply-To: <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
Message-ID: <CKeWUf-xq1hGquFYlFE6KZixYFuyA0YO2nS4tUOjoRA=.c14e2ff7-ad4f-4660-b349-ba063e8e9ade@github.com>

On Thu, 22 Jun 2023 01:38:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed recommendations from Alan

This patch, rendered API specification, and the CSR have all been updated, taking notes from recommendations in #14528 ([JDK-8310242](https://bugs.openjdk.org/browse/JDK-8310242)). Please review again, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1603608737

From jwaters at openjdk.org  Fri Jun 23 02:43:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:43:38 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'openjdk:master' into patch-6
 - Whitespace
 - Revert
 - _MSC_VER
 - Restore visCPP
 - Restore gcc attribute
 - Revert gcc
 - Revert
 - Semicolon
 - gcc offset_of
 - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

-------------

Changes: https://git.openjdk.org/jdk/pull/13258/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=05
  Stats: 11 lines in 3 files changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

PR: https://git.openjdk.org/jdk/pull/13258

From duke at openjdk.org  Fri Jun 23 04:22:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 23 Jun 2023 04:22:07 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? 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/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/27a82129..dce6296f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=17-18

  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From dholmes at openjdk.org  Fri Jun 23 04:31:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Jun 2023 04:31:05 GMT
Subject: RFR: 8310242: Clarify the name parameter to Class::forName [v8]
In-Reply-To: <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
 <BpcNuM1LHSF6m0U0kHhi6O6n7u2YKIjT1PO4sLInoSI=.2b3fae10-ef63-4778-b953-9c82f0d42ebd@github.com>
Message-ID: <AyTCWpdus1RPmulbdrs8nDarZTWEh-0s2UMgReP3NkE=.6585c9b0-48b9-4a65-bc6c-53ebdff8daa9@github.com>

On Thu, 22 Jun 2023 17:47:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14528#pullrequestreview-1494373253

From alanb at openjdk.org  Fri Jun 23 04:47:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Jun 2023 04:47:12 GMT
Subject: [jdk21] Integrated: 8309853: StructuredTaskScope.join description
 improvements
In-Reply-To: <HD17NbxnFPXZE3pIsn2hV37f0mQ9JFy1eEL5ZPcRk8Q=.93008e89-41c0-4265-a80b-67a249841d79@github.com>
References: <HD17NbxnFPXZE3pIsn2hV37f0mQ9JFy1eEL5ZPcRk8Q=.93008e89-41c0-4265-a80b-67a249841d79@github.com>
Message-ID: <Ms0USJUjxMw_v8mysQlpPLFyIJ8h4TRd5ZPmUNtdwjo=.2c291f52-beeb-4c75-a3c6-262c5290467f@github.com>

On Thu, 22 Jun 2023 10:45:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 8309853: StructuredTaskScope.join description improvements

This pull request has now been integrated.

Changeset: e86d765b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/e86d765b229d6cc2270dcc90b40252851e50c959
Stats:     82 lines in 1 file changed: 54 ins; 3 del; 25 mod

8309853: StructuredTaskScope.join description improvements

Reviewed-by: darcy
Backport-of: 3661cdee1b20ab2868025637871d22bb30add6bd

-------------

PR: https://git.openjdk.org/jdk21/pull/55

From duke at openjdk.org  Fri Jun 23 04:55:06 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 23 Jun 2023 04:55:06 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
Message-ID: <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>

On Fri, 23 Jun 2023 04:22:07 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused import

Latest benchmark results:

###  aliyun_c8i.xlarge (+23.25% )
cpu : intel xeon sapphire rapids (x64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
+UUIDBench.toString   20000  thrpt   15  76.979 ? 1.011  ops/us


### aliyun_c8a.xlarge (+23.09%)
cpu : amd epc genoa (x64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
+UUIDBench.toString   20000  thrpt   15  80.839 ? 0.278  ops/us


### aliyun_c8y.xlarge (+71.92%)
cpu : aliyun yitian 710 (aarch64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
+UUIDBench.toString   20000  thrpt   15  55.356 ? 1.882  ops/us


### aws_c5.xlarge (+36.23% )
aws x64
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
+UUIDBench.toString   20000  thrpt   15  62.673 ? 0.259  ops/us


### MacBook Pro M1 Pro (+179.94%)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  36.875 ? 0.902  ops/us
+UUIDBench.toString   20000  thrpt   15  103.229 ? 1.063  ops/us


### Orange Pi 5 Plus (+71.16%)
cpu : RK3588 (aarch64)
``` diff
 Benchmark           (size)   Mode  Cnt   Score   Error   Units
-UUIDBench.toString   20000  thrpt   15  21.691 ? 0.204  ops/us
+UUIDBench.toString   20000  thrpt   15  38.211 ? 0.344  ops/us

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1603676840

From djelinski at openjdk.org  Fri Jun 23 05:58:15 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 05:58:15 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v5]
In-Reply-To: <eEbDYpSwsLcib5N30VkZvRcHoIpGzQPSs3o4BVhzsuw=.f3f36344-3e98-4bd9-99b2-c03a2f76eb0a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>
 <eEbDYpSwsLcib5N30VkZvRcHoIpGzQPSs3o4BVhzsuw=.f3f36344-3e98-4bd9-99b2-c03a2f76eb0a@github.com>
Message-ID: <0uCYsojlqYE-BhXPzK4Ne8u0I814yw5aWnNgAwYoeBc=.55117431-5a01-444e-8903-86779148ea78@github.com>

On Fri, 23 Jun 2023 02:25:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Whitespace
>>  - Revert
>>  - _MSC_VER
>
> @djelinski Sorry for the tag, it's just that this PR has been collecting dust for months now

Hi @TheShermanTanker these alignment instructions were introduced in JDK-8220348 and JDK-8239856 to deal with Windows 32 failures. Windows 32 build is going away soon. As far as I could tell, the declspec was only introduced to deal with an overzealous assert.

@TheRealMDoerr @RealCLanger @tstuefe @sspitsyn since you were responsible for the introduction of the alignment specifiers, could you help with reviewing this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1603717283

From jwaters at openjdk.org  Fri Jun 23 06:16:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 06:16:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
Message-ID: <LdyxdQwGp8-1SV9ljJSo_KQXQVa7Fwaai32DyrfezgI=.8f37a207-a58d-47a3-940a-3d7dcfedac2e@github.com>

On Thu, 8 Jun 2023 11:20:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> I'll take a look? hopefully next week.

Wait a minute, I was right, it was a jint the whole time! Oh well, I'll wait for what @aivanov-jdk has to say, but I don't like the idea of leaving both inconsistent

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1603730539

From djelinski at openjdk.org  Fri Jun 23 06:22:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 06:22:06 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
Message-ID: <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>

On Thu, 22 Jun 2023 09:58:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:
> 
>> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
> 
> Suggestion:
> 
>         DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
>         DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
>         DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
>         DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
>         DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>         DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>         DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

Please remove the extra spaces.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239364317

From djelinski at openjdk.org  Fri Jun 23 06:13:07 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 06:13:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
Message-ID: <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>

On Fri, 23 Jun 2023 02:38:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert wrong Copyright
>  - Copyright

src/java.desktop/windows/native/libawt/windows/awt_Menu.h line 76:

> 74:     /*for multifont menu */
> 75:     BOOL IsTopMenu();
> 76:     virtual AwtMenuItem* GetItem(jobject target, int index);

Hi @aivanov-jdk are you OK leaving this inconsistent with the definition?
https://github.com/openjdk/jdk/blob/16b5a91461db1765e2e7596ebaaf1299cec9b0c8/src/java.desktop/windows/native/libawt/windows/awt_Menu.cpp#L261

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239358334

From alanb at openjdk.org  Fri Jun 23 06:52:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Jun 2023 06:52:03 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v4]
In-Reply-To: <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>
Message-ID: <Od7ZqIktrLxS95Opus0ZhJulAwD1KGHvsHd68dRKmJA=.2a577e2a-f535-4946-afbd-41bb412daf54@github.com>

On Thu, 22 Jun 2023 22:52:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8222329: Correct return verbiage of Reader and CharBuffer

src/java.base/share/classes/java/nio/X-Buffer.java.template line 484:

> 482:      * @throws ReadOnlyBufferException if target is a read only buffer,
> 483:      *         even if it is empty
> 484:      * @since 1.5

It might be clearer if this method linked to the length method. That way it could be specified to return 0 when the length of the target buffer is 0.

For the @throws of ROBE, probably need to avoid the word "empty", only because this method writes to the target buffer, it doesn't read from the target buffer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239387151

From dqu at openjdk.org  Fri Jun 23 07:52:16 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Fri, 23 Jun 2023 07:52:16 GMT
Subject: RFR: 8307512: Provide more information in message of
 NoSuchFieldException thrown by Class
Message-ID: <I2LNyxaeo0917sFUbh4_OSpUxe539_hNCF8ZFRbCRq4=.27fba00a-29fd-426a-b1e2-5d55f65b3ccf@github.com>

Similar to #11745 , this patch adds more information for `NoSuchFieldException` thrown by `getField()` or `getDeclaredField()` of `java.lang.Class`. The error message changes like the example below:
1. For `getField()`

Before this change:

Exception in thread "main" java.lang.NoSuchFieldException: i
?

After this change:

Exception in thread "main" java.lang.NoSuchFieldException: Class 'Test' does not have member field 'i'
?


2. For `getDeclaredField()`

Before this change:

Exception in thread "main" java.lang.NoSuchFieldException: i
?

After this change:

Exception in thread "main" java.lang.NoSuchFieldException: Class 'Test' does not have declared field 'i'
?


Tests `tier1-3` has passed for release build on Linux x86-64. (With one failure not related to this.)

-------------

Commit messages:
 - Add more info in the exception message

Changes: https://git.openjdk.org/jdk/pull/14624/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14624&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307512
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14624.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14624/head:pull/14624

PR: https://git.openjdk.org/jdk/pull/14624

From asemenov at openjdk.org  Fri Jun 23 08:03:45 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:03:45 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v8]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/c4ca2205..92f629f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06-07

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Fri Jun 23 08:09:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:09:05 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
 <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>
Message-ID: <uFToDpeYUWFQyhvBB5DMIvAYOdiUDq-KP-R6v64A51g=.361ef91f-3e20-4be7-b63e-f3774cb9128c@github.com>

On Fri, 23 Jun 2023 06:19:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:
>> 
>>> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>>> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>>> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
>> 
>> Suggestion:
>> 
>>         DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
>>         DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
>>         DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
>>         DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
>>         DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>>         DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>>         DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
>
> Please remove the extra spaces.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239506015

From djelinski at openjdk.org  Fri Jun 23 08:27:04 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 08:27:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v8]
In-Reply-To: <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>
Message-ID: <6Ii3MX8vMTxkr1M6OSPRK1MC3Mird6O_jeC6topuMdU=.e954d902-8b57-40bf-8fd9-9d88b82cd969@github.com>

On Fri, 23 Jun 2023 08:03:45 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

LGTM

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1494691850

From mbaesken at openjdk.org  Fri Jun 23 08:40:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Jun 2023 08:40:06 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <y6e_N1LMrTBZdZekhjzGj2KwcMhVO-qFNgnUXudcgE8=.20369c56-290f-4f8c-ae2e-a2399fcde214@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Hi Christoph, thanks for the review !
Chris are you okay with the latest rev.  of this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1603933840

From stsypanov at openjdk.org  Fri Jun 23 08:51:06 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 23 Jun 2023 08:51:06 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <SnvjgmShwG_mldT46T2pbzUHESEVOItrlCfpe9zpHKk=.904c54e8-2f2f-4d2f-ba04-2e386ebea260@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Any review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1603947605

From stsypanov at openjdk.org  Fri Jun 23 08:54:05 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 23 Jun 2023 08:54:05 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <X9FA6RfLU94i82-YlReox6-ulhoCAS4ywd915GSzlqc=.9dfbe743-fbfa-48d0-927d-f41a6f91e242@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
 <X9FA6RfLU94i82-YlReox6-ulhoCAS4ywd915GSzlqc=.9dfbe743-fbfa-48d0-927d-f41a6f91e242@github.com>
Message-ID: <QElPV-VF2xSUXyH6mLa8EFHEao0-Na45G032FZVu_aA=.b04d38e3-9ed3-4cf8-8363-e41f6e3063f1@github.com>

On Thu, 22 Jun 2023 21:00:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>>   
>>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>
> I think the bug description should include a bit more detail along the lines that since the method reading and writing are synchronized, its not really a racy read. It does avoid reading the volatile value twice (a relatively expensive operation).

@RogerRiggs updated

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14589#issuecomment-1603951233

From aturbanov at openjdk.org  Fri Jun 23 09:08:17 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 23 Jun 2023 09:08:17 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v58]
In-Reply-To: <ruUYxaG6_D79Pkfk-oNqLjuiX_uP2Qi4yfX8aJgfvUo=.042bd99e-d968-4252-8a49-b20dfe0bc17f@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <ruUYxaG6_D79Pkfk-oNqLjuiX_uP2Qi4yfX8aJgfvUo=.042bd99e-d968-4252-8a49-b20dfe0bc17f@github.com>
Message-ID: <N03UdVNXyGJo0u-6MEwmonhM4bARM-0gKvxdAHrxXGo=.12bed3bf-f4e4-4714-b7c3-15c65e8dd95f@github.com>

On Wed, 8 Mar 2023 08:50:24 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK.
>> 
>> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one.
>> 
>> Classfile API development is tracked at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch
>> 
>> Development branch of consolidated JDK class files parsing, generating, and transforming is at:
>> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch
>> 
>> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html) is also available.
>> 
>> Please take you time to review this non-trivial JDK addition.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete javadoc from implementation classes

src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 139:

> 137:         Util.checkKind(op, Opcode.Kind.CONSTANT);
> 138:         if (op != Opcode.BIPUSH && op != Opcode.SIPUSH)
> 139:             throw new IllegalArgumentException(String.format("Wrong opcode specified; found %s, expected BIPUSH or SIPUSH", op, op.kind()));

IDEA shows warning here.
Too many arguments for format string (found: 2, expected: 1)

Seems op.kind() parameter is unused in the format string.

And the same issue in `jdk.internal.classfile.instruction.ConstantInstruction#ofLoad`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10982#discussion_r1239565938

From liach at openjdk.org  Fri Jun 23 09:33:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jun 2023 09:33:04 GMT
Subject: RFR: 8307512: Provide more information in message of
 NoSuchFieldException thrown by Class
In-Reply-To: <I2LNyxaeo0917sFUbh4_OSpUxe539_hNCF8ZFRbCRq4=.27fba00a-29fd-426a-b1e2-5d55f65b3ccf@github.com>
References: <I2LNyxaeo0917sFUbh4_OSpUxe539_hNCF8ZFRbCRq4=.27fba00a-29fd-426a-b1e2-5d55f65b3ccf@github.com>
Message-ID: <kYh2T73tqwQfEp4lcj40luE6O9tZj0uh-2KLgqK1vc4=.be454f0a-61e4-4e46-8bf2-dec93b1e783c@github.com>

On Fri, 23 Jun 2023 07:44:31 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> Similar to #11745 , this patch adds more information for `NoSuchFieldException` thrown by `getField()` or `getDeclaredField()` of `java.lang.Class`. The error message changes like the example below:
> 1. For `getField()`
> 
> Before this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: i
> ?
> 
> After this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: Class 'Test' does not have member field 'i'
> ?
> 
> 
> 2. For `getDeclaredField()`
> 
> Before this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: i
> ?
> 
> After this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: Class 'Test' does not have declared field 'i'
> ?
> 
> 
> Tests `tier1-3` has passed for release build on Linux x86-64. (With one failure not related to this.)

I think a message like 'Class.field' is better, more consistent with methodToString's behavior.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14624#issuecomment-1604005192

From cstein at openjdk.org  Fri Jun 23 09:37:47 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 23 Jun 2023 09:37:47 GMT
Subject: RFR: 8309670: java -help output for --module-path / -p is
 incomplete [v2]
In-Reply-To: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
References: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
Message-ID: <8r6E02LkMFhhcfvAKxQdTKpRfyCRAkmNP_3iQw29-eo=.581578b0-49ab-4464-a0ce-f88e5601becf@github.com>

> Please review this update to `java`'s help output for `--module-path`/`-p`.
> 
> This PR also updates the output for the closely related `--upgrade-module-path` option.
> 
> Thanks in advance!

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update java.1 man page

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14564/files
  - new: https://git.openjdk.org/jdk/pull/14564/files/c45531b5..f24027ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14564&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14564&range=00-01

  Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14564/head:pull/14564

PR: https://git.openjdk.org/jdk/pull/14564

From alanb at openjdk.org  Fri Jun 23 09:43:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Jun 2023 09:43:04 GMT
Subject: RFR: 8309670: java -help output for --module-path / -p is
 incomplete [v2]
In-Reply-To: <8r6E02LkMFhhcfvAKxQdTKpRfyCRAkmNP_3iQw29-eo=.581578b0-49ab-4464-a0ce-f88e5601becf@github.com>
References: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
 <8r6E02LkMFhhcfvAKxQdTKpRfyCRAkmNP_3iQw29-eo=.581578b0-49ab-4464-a0ce-f88e5601becf@github.com>
Message-ID: <wHMbTxfjuNQVm1RRSDelxOmiE3XkmQUpZ8sf-SkvxZc=.f27491c2-4fc9-43e4-bd1f-55295292a59d@github.com>

On Fri, 23 Jun 2023 09:37:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this update to `java`'s help output for `--module-path`/`-p`.
>> 
>> This PR also updates the output for the closely related `--upgrade-module-path` option.
>> 
>> Thanks in advance!
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update java.1 man page

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14564#pullrequestreview-1494817796

From prappo at openjdk.org  Fri Jun 23 10:46:24 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 10:46:24 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Coincidentally, I'm looking at modernizing some of the equals methods in java.base.

src/java.base/share/classes/java/util/ResourceBundle.java line 743:

> 741:                 return ((module != null) && (module.equals(otherEntry.getModule())) &&
> 742:                         (caller != null) && (caller.equals(otherEntry.getCallerModule())));
> 743:             } catch (NullPointerException | ClassCastException e) {

Are we sure that NPE can only be thrown when calling equals on `name` or `locale` and not, for example, from `getModule()` or `getCallerModule()`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1494905419
PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1239665426

From dqu at openjdk.org  Fri Jun 23 10:56:16 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Fri, 23 Jun 2023 10:56:16 GMT
Subject: RFR: 8307512: Provide more information in message of
 NoSuchFieldException thrown by Class
In-Reply-To: <kYh2T73tqwQfEp4lcj40luE6O9tZj0uh-2KLgqK1vc4=.be454f0a-61e4-4e46-8bf2-dec93b1e783c@github.com>
References: <I2LNyxaeo0917sFUbh4_OSpUxe539_hNCF8ZFRbCRq4=.27fba00a-29fd-426a-b1e2-5d55f65b3ccf@github.com>
 <kYh2T73tqwQfEp4lcj40luE6O9tZj0uh-2KLgqK1vc4=.be454f0a-61e4-4e46-8bf2-dec93b1e783c@github.com>
Message-ID: <CVNR94cU9fYhVL0NNLxvX9sIwfq_lOadyGwCKG2EbyI=.b7596c10-807f-47c0-877b-8de754a1d0c8@github.com>

On Fri, 23 Jun 2023 09:30:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think a message like 'Class.field' is better, more consistent with methodToString's behavior.

Hi, @liach, thanks for your suggestions, this `Class.field` format is indeed more succinct. But I'm following this format (`NoSuchFieldError` thrown in `linkResolver.cpp`).

https://github.com/openjdk/jdk/blob/d1d2b55ce0b950e07f6e3761983f73fd58079627/src/hotspot/share/interpreter/linkResolver.cpp#L976-L984

Anyway, the point here is that the name of the class should be added to the message. So maybe both are acceptable. Let's wait for some others' opinions :D

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14624#issuecomment-1604104282

From duke at openjdk.org  Fri Jun 23 11:03:13 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 23 Jun 2023 11:03:13 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v20]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <rzn70ubtBEj6ic5L7ye_z6B2wKAfFmUXUpkRkgog4f8=.16cc921d-49bd-4f7f-a6a5-cbd5f210640f@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  make Long.fastUUID codeSize less than 325 (FreqInlineSize)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/dce6296f..0d346558

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=18-19

  Stats: 52 lines in 2 files changed: 0 ins; 5 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From cstein at openjdk.org  Fri Jun 23 11:12:08 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 23 Jun 2023 11:12:08 GMT
Subject: Integrated: 8309670: java -help output for --module-path / -p is
 incomplete
In-Reply-To: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
References: <d1x-TUWEmUoOY06hi5nnTfYv2m992Xf7rGgE9mHMqe8=.edaa8df7-faa4-478f-9c1b-4d3cf85733d0@github.com>
Message-ID: <GuYEKklqpdveBYxKqMjb8QcOEQhIq2JkneGkLxzDBqM=.4b3b3d64-c53d-459b-849e-d3189ff73b8f@github.com>

On Tue, 20 Jun 2023 13:54:15 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this update to `java`'s help output for `--module-path`/`-p`.
> 
> This PR also updates the output for the closely related `--upgrade-module-path` option.
> 
> Thanks in advance!

This pull request has now been integrated.

Changeset: 4bf78162
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024
Stats:     18 lines in 2 files changed: 7 ins; 0 del; 11 mod

8309670: java -help output for --module-path / -p is incomplete

Reviewed-by: mchung, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14564

From duke at openjdk.org  Fri Jun 23 11:17:04 2023
From: duke at openjdk.org (Sam Brannen)
Date: Fri, 23 Jun 2023 11:17:04 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
 <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
Message-ID: <taIHhGov1A4pJRSyOXj13VyCubQN5uvKztL92Ms8jq4=.246f259f-23b3-46e6-b0b6-d12310d76f92@github.com>

On Wed, 21 Jun 2023 00:35:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 818:
>> 
>>> 816:      * they represent, namely {@code boolean}, {@code byte},
>>> 817:      * {@code char}, {@code short}, {@code int},
>>> 818:      * {@code long}, {@code float}, and {@code double}.
>> 
>> Should we add `{@code void}` to the list here, as this is one of the primitive type names?
>
> Hmm. I'll consider that. The javadoc in java.lang.Class is inconsistent in the formatting of "void" as a type name, some instances are in code markup while others are not.

@jddarcy and @pavelrappo, as I understood it, @liach is not suggesting that the term "void" in "primitive types and void" should be replaced by `{@code void}`.

Rather, `{@code void}` should be included in the enumeration of primitive types -- for example, by replacing `and {@code double}` with `{@code double}, and {@code void}`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1239692615

From duke at openjdk.org  Fri Jun 23 11:24:23 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 23 Jun 2023 11:24:23 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v21]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/0d346558..f08444f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=19-20

  Stats: 12 lines in 1 file changed: 1 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From prappo at openjdk.org  Fri Jun 23 11:37:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 11:37:04 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
 <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
Message-ID: <kSPafWmL6pvFXaEbExLgiYMfaMSLn_KCZ1LN3OKSiBY=.87497c6c-e04f-4d30-becc-dc32a35dd1b6@github.com>

On Wed, 21 Jun 2023 00:35:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 818:
>> 
>>> 816:      * they represent, namely {@code boolean}, {@code byte},
>>> 817:      * {@code char}, {@code short}, {@code int},
>>> 818:      * {@code long}, {@code float}, and {@code double}.
>> 
>> Should we add `{@code void}` to the list here, as this is one of the primitive type names?
>
> Hmm. I'll consider that. The javadoc in java.lang.Class is inconsistent in the formatting of "void" as a type name, some instances are in code markup while others are not.

> @jddarcy and @pavelrappo, as I understood it, @liach is not suggesting that the term "void" in "primitive types and void" should be replaced by `{@code void}`.
> 
> Rather, `{@code void}` should be included in the enumeration of primitive types -- for example, by replacing `and {@code double}` with `{@code double}, and {@code void}`.

AFAIK, that sentence enumerates primitive types, which according to the Java Language Specification [^1][^2], do not include `void`.

[^1]: https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-4.2
[^2]: https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.4.5

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1239711787

From cstein at openjdk.org  Fri Jun 23 11:38:18 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 23 Jun 2023 11:38:18 GMT
Subject: [jdk21] RFR: 8309670: java -help output for --module-path / -p is
 incomplete
Message-ID: <-okyrcCmSJNm1rmsjkaypjSIpewpNJOOmUWx7GScD6c=.ca60bbd8-2e28-47ff-be83-b90f6bb2e496@github.com>

Hi all,

This pull request contains a backport of commit [4bf78162](https://github.com/openjdk/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Christian Stein on 23 Jun 2023 and was reviewed by Mandy Chung and Alan Bateman.

Thanks!

-------------

Commit messages:
 - Backport 4bf78162c52564645af79b8324b69d89102dc024

Changes: https://git.openjdk.org/jdk21/pull/57/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=57&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309670
  Stats: 18 lines in 2 files changed: 7 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk21/pull/57.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/57/head:pull/57

PR: https://git.openjdk.org/jdk21/pull/57

From duke at openjdk.org  Fri Jun 23 11:55:02 2023
From: duke at openjdk.org (Sam Brannen)
Date: Fri, 23 Jun 2023 11:55:02 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <kSPafWmL6pvFXaEbExLgiYMfaMSLn_KCZ1LN3OKSiBY=.87497c6c-e04f-4d30-becc-dc32a35dd1b6@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
 <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
 <kSPafWmL6pvFXaEbExLgiYMfaMSLn_KCZ1LN3OKSiBY=.87497c6c-e04f-4d30-becc-dc32a35dd1b6@github.com>
Message-ID: <8Rz8rcc-K11xpeGqoSUNt9n2KvSYXsdR7typFgXt-go=.0c1dab5f-e06d-42b0-840c-74b69b9de237@github.com>

On Fri, 23 Jun 2023 11:34:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Hmm. I'll consider that. The javadoc in java.lang.Class is inconsistent in the formatting of "void" as a type name, some instances are in code markup while others are not.
>
>> @jddarcy and @pavelrappo, as I understood it, @liach is not suggesting that the term "void" in "primitive types and void" should be replaced by `{@code void}`.
>> 
>> Rather, `{@code void}` should be included in the enumeration of primitive types -- for example, by replacing `and {@code double}` with `{@code double}, and {@code void}`.
> 
> AFAIK, that sentence enumerates primitive types, which according to the Java Language Specification [^1][^2], do not include `void`.
> 
> [^1]: https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-4.2
> [^2]: https://docs.oracle.com/javase/specs/jls/se20/html/jls-8.html#jls-8.4.5

Thanks for the links, @pavelrappo.

I understand the point you're making; however, there is still ambiguous wording in the documentation for this method.

The method is called `isPrimitive`, and it returns `true` for `isPrimitive(void.class)`. In addition, the first sentence states: "Determines if the specified `Class` object represents a primitive type."

Note as well that the documentation states "There are nine predefined ..." but then goes on to only list 8 names.

So, in line with the intent of the method with regard to `void`, it should be clear to the user that `void` is the name for the type `void.class` (and `Void.TYPE`).

Perhaps the easiest way to include `void.class` and match the 9 predefined types with their names is to remove "primitive" from "as the primitive types that" and replace `and {@code double}` with `{@code double}, and {@code void}`.

Along that line of thinking, it might be best to change the first sentence to "Determines if the specified `Class` object represents a primitive type or void."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1239725820

From prappo at openjdk.org  Fri Jun 23 12:02:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 12:02:02 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <8Rz8rcc-K11xpeGqoSUNt9n2KvSYXsdR7typFgXt-go=.0c1dab5f-e06d-42b0-840c-74b69b9de237@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
 <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
 <kSPafWmL6pvFXaEbExLgiYMfaMSLn_KCZ1LN3OKSiBY=.87497c6c-e04f-4d30-becc-dc32a35dd1b6@github.com>
 <8Rz8rcc-K11xpeGqoSUNt9n2KvSYXsdR7typFgXt-go=.0c1dab5f-e06d-42b0-840c-74b69b9de237@github.com>
Message-ID: <T4eouINL7seCi6IWJgnBLk9f_YKPrlId7XLrkariRak=.bb2fb1f1-333b-49fc-aa97-a3101ff80911@github.com>

On Fri, 23 Jun 2023 11:52:12 GMT, Sam Brannen <duke at openjdk.org> wrote:

> Along that line of thinking, it might be best to change the first sentence to "Determines if the specified Class object represents a primitive type or void."

I was just about to suggest exactly that, but from the superinterface method's perspective. Here's what I had been writing when received your message:

At the same, time java.lang.invoke.TypeDescriptor.OfField#isPrimitive:

        /**
         * Does this field descriptor describe a primitive type (including void.)
         *
         * @return whether this field descriptor describes a primitive type
         */
        boolean isPrimitive();

I suggest rephrasing that and similar text elsewhere, for example, as follows:

    /** {@return whether this field descriptor describes a primitive type or void} */
    boolean isPrimitive();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1239730572

From duke at openjdk.org  Fri Jun 23 12:10:33 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 23 Jun 2023 12:10:33 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v5]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <dUdXGUZH0GjnqHJZDIMaMPrOZwcXrep3CWw7C36ZA1c=.b253fcfe-7127-4dc8-8910-59956f75e03d@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

Oliver Kopp has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into fix-8240567
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Merge remote-tracking branch 'upstream/master' into fix-8240567
 - Remove "final" at "enabled" - not part of the point of this PR
 - Remove comments
 - 8240567: MethodTooLargeException thrown while creating a jlink image
   
   Co-authored-by: Christoph Schwentker <siedlerkiller at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/e9732951..a084ca54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=03-04

  Stats: 10453 lines in 519 files changed: 5309 ins; 2092 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/14408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14408/head:pull/14408

PR: https://git.openjdk.org/jdk/pull/14408

From liach at openjdk.org  Fri Jun 23 12:59:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 23 Jun 2023 12:59:05 GMT
Subject: RFR: 8307512: Provide more information in message of
 NoSuchFieldException thrown by Class
In-Reply-To: <I2LNyxaeo0917sFUbh4_OSpUxe539_hNCF8ZFRbCRq4=.27fba00a-29fd-426a-b1e2-5d55f65b3ccf@github.com>
References: <I2LNyxaeo0917sFUbh4_OSpUxe539_hNCF8ZFRbCRq4=.27fba00a-29fd-426a-b1e2-5d55f65b3ccf@github.com>
Message-ID: <UteNj0LspejaqDrm7CGMLPY00PGvntLn-_7qCGsKCIk=.a39ed241-0a77-486b-913e-75bb3624b3a6@github.com>

On Fri, 23 Jun 2023 07:44:31 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> Similar to #11745 , this patch adds more information for `NoSuchFieldException` thrown by `getField()` or `getDeclaredField()` of `java.lang.Class`. The error message changes like the example below:
> 1. For `getField()`
> 
> Before this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: i
> ?
> 
> After this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: Class 'Test' does not have member field 'i'
> ?
> 
> 
> 2. For `getDeclaredField()`
> 
> Before this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: i
> ?
> 
> After this change:
> 
> Exception in thread "main" java.lang.NoSuchFieldException: Class 'Test' does not have declared field 'i'
> ?
> 
> 
> Tests `tier1-3` has passed for release build on Linux x86-64. (With one failure not related to this.)

IMO #11745 is a bit too verbose, compared to the code that prints the absent method in NoSuchMethodError:
https://github.com/openjdk/jdk/blob/d1d2b55ce0b950e07f6e3761983f73fd58079627/src/hotspot/share/interpreter/linkResolver.cpp#L863-L871
Printing the descriptor directly suffices. Field descriptors are described by [JVMS 4.3.2](https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.3.2).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14624#issuecomment-1604245500

From stsypanov at openjdk.org  Fri Jun 23 13:49:09 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 23 Jun 2023 13:49:09 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
Message-ID: <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>

On Fri, 23 Jun 2023 10:41:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore logic
>
> src/java.base/share/classes/java/util/ResourceBundle.java line 743:
> 
>> 741:                 return ((module != null) && (module.equals(otherEntry.getModule())) &&
>> 742:                         (caller != null) && (caller.equals(otherEntry.getCallerModule())));
>> 743:             } catch (NullPointerException | ClassCastException e) {
> 
> Are we sure that NPE can only be thrown when calling equals on `name` or `locale` and not, for example, from `getModule()` or `getCallerModule()`?

Yes:

CacheKey(String baseName, Locale locale, Module module, Module caller) {
    Objects.requireNonNull(module);
    Objects.requireNonNull(caller);

    this.name = baseName;
    this.locale = locale;
    this.moduleRef = new KeyElementReference<>(module, referenceQueue, this);
    this.callerRef = new KeyElementReference<>(caller, referenceQueue, this);
    this.modulesHash = module.hashCode() ^ caller.hashCode();
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1239839973

From aivanov at openjdk.org  Fri Jun 23 14:27:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 14:27:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
Message-ID: <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>

On Fri, 23 Jun 2023 06:10:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert wrong Copyright
>>  - Copyright
>
> src/java.desktop/windows/native/libawt/windows/awt_Menu.h line 76:
> 
>> 74:     /*for multifont menu */
>> 75:     BOOL IsTopMenu();
>> 76:     virtual AwtMenuItem* GetItem(jobject target, int index);
> 
> Hi @aivanov-jdk are you OK leaving this inconsistent with the definition?
> https://github.com/openjdk/jdk/blob/16b5a91461db1765e2e7596ebaaf1299cec9b0c8/src/java.desktop/windows/native/libawt/windows/awt_Menu.cpp#L261

The declaration and implementation have to match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239886709

From aivanov at openjdk.org  Fri Jun 23 14:27:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 14:27:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v9]
In-Reply-To: <42a4Nj_iDfQRh-eOXo4PSl7eag1EVv9JW1y2Uvqt2vg=.1dac1318-9637-46f5-9c40-f090c9e2640e@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <8DgisSGbTfEW8SIvgeweqpmQz3xbVFDKsInXCBPklRI=.368ca26b-eaaa-4620-8c71-20b72deb931f@github.com>
 <XNLoJBN-0cm8ZeTLRaVjHAtde8wkQLyxrnXUm9uSjtI=.d4001486-36fc-4c59-8566-cbd5fa691b37@github.com>
 <42a4Nj_iDfQRh-eOXo4PSl7eag1EVv9JW1y2Uvqt2vg=.1dac1318-9637-46f5-9c40-f090c9e2640e@github.com>
Message-ID: <2kn5RYAWrZokkv1fHoUC2FO0fS7Z1R4DQH2ws9Mrw88=.f8d7bd70-1a1c-4421-91d2-5296812b5561@github.com>

On Fri, 23 Jun 2023 00:16:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_MenuBar.cpp line 148:
>> 
>>> 146: }
>>> 147: 
>>> 148: AwtMenuItem* AwtMenuBar::GetItem(jobject target, jint index)
>> 
>> What is the reason for using `jint` instead of `int`?
>> 
>> The member function is used in for-loop which iterates with `int` loop variable. Yet the implementation of `GetItem` up-calls into Java.
>
> I had it as a jint since it upcalls into Java

I am fine with either way as long as it compiles without warning and menu works as expected.

I had to ask the question. Which way conveys the intention clearer? I don't know. I incline to using `int` as is in the latest version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239883713

From aivanov at openjdk.org  Fri Jun 23 14:34:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 14:34:17 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
Message-ID: <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>

On Fri, 23 Jun 2023 14:24:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Menu.h line 76:
>> 
>>> 74:     /*for multifont menu */
>>> 75:     BOOL IsTopMenu();
>>> 76:     virtual AwtMenuItem* GetItem(jobject target, int index);
>> 
>> Hi @aivanov-jdk are you OK leaving this inconsistent with the definition?
>> https://github.com/openjdk/jdk/blob/16b5a91461db1765e2e7596ebaaf1299cec9b0c8/src/java.desktop/windows/native/libawt/windows/awt_Menu.cpp#L261
>
> The declaration and implementation have to match.

To minimise the number of changes, we can go for using `jint` in `AwtMenu::GetItem`.

What do you thing, @djelinski and @TheShermanTanker?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239891473

From jwaters at openjdk.org  Fri Jun 23 14:34:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 14:34:18 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
 <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
Message-ID: <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>

On Fri, 23 Jun 2023 14:28:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The declaration and implementation have to match.
>
> To minimise the number of changes, we can go for using `jint` in `AwtMenu::GetItem`.
> 
> What do you thing, @djelinski and @TheShermanTanker?

Hmm, I lean towards jint as I feel it conveys the fact that it is a Java parameter clearer, intuitively to me it makes sense that a Java integer type would still work in a C++ for loop in native code

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1239893754

From prappo at openjdk.org  Fri Jun 23 15:15:11 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 15:15:11 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
 <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
Message-ID: <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>

On Fri, 23 Jun 2023 13:46:04 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ResourceBundle.java line 743:
>> 
>>> 741:                 return ((module != null) && (module.equals(otherEntry.getModule())) &&
>>> 742:                         (caller != null) && (caller.equals(otherEntry.getCallerModule())));
>>> 743:             } catch (NullPointerException | ClassCastException e) {
>> 
>> Are we sure that NPE can only be thrown when calling equals on `name` or `locale` and not, for example, from `getModule()` or `getCallerModule()`?
>
> Yes:
> 
> CacheKey(String baseName, Locale locale, Module module, Module caller) {
>     Objects.requireNonNull(module);
>     Objects.requireNonNull(caller);
> 
>     this.name = baseName;
>     this.locale = locale;
>     this.moduleRef = new KeyElementReference<>(module, referenceQueue, this);
>     this.callerRef = new KeyElementReference<>(caller, referenceQueue, this);
>     this.modulesHash = module.hashCode() ^ caller.hashCode();
> }

I'll run our CI, and if all good, I'll approve this PR. If nothing else, this change seems reasonable and correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1239940961

From bpb at openjdk.org  Fri Jun 23 15:45:18 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 15:45:18 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v5]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <un9IS7kWFcYmeLlFP0nCOzJ2j8oqgf6DgMm9HTXl2Kw=.4410d6ba-6eb3-4044-a9b7-9117625db312@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: Tweak verbiage some more

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/d693c612..94505a45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=03-04

  Stats: 10 lines in 3 files changed: 3 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From bpb at openjdk.org  Fri Jun 23 15:45:20 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 15:45:20 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v5]
In-Reply-To: <VL1YCVbMYhqs9NWT8MpYXfAGcCg3s64oO7cvuVakfqI=.ba203d00-1fdf-4562-a7f6-acb41457b1ab@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <T-LJO9eM9RXaMEqPBSn-m2Au_CM5aIEt9HBS4cdJke0=.a7798f48-7b0a-4214-8c83-d996aceb5971@github.com>
 <icmT4Q3H5899yNDiVhLYOlWKftRD0MXhQ22gKDPsQ2E=.4b4a18cc-1e82-494c-92d8-e358096bc8d9@github.com>
 <Hxx2YdBGLXJYbMYaRV66UaKKHaNuQB_0Iadb9EQajIo=.36f87ce0-ebe8-49fe-83ca-ee3566d97de5@github.com>
 <BsAiZQec9Gi0V8O4ZWM3e5uIQpWQ9q4P1ARtZ5Dm3XE=.6d260163-baa9-43a4-ad77-3eb69b3f87d8@github.com>
 <VL1YCVbMYhqs9NWT8MpYXfAGcCg3s64oO7cvuVakfqI=.ba203d00-1fdf-4562-a7f6-acb41457b1ab@github.com>
Message-ID: <KZsxyg4X012qjRLwzNX68zHlW2dDsa6aiM9eRGSbqoU=.b8f3d9c5-0b4c-4db2-ae27-a74cd8a889f8@github.com>

On Thu, 22 Jun 2023 22:15:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I have a slight preference for "no space remaining"; remaining can still be a linkplain to the method if that helps it be specific.
>
> I concur. Thanks.

Addressed in 055107bddcc38a331ee93e178402473ab9f91740.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239969934

From bpb at openjdk.org  Fri Jun 23 15:45:24 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 15:45:24 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v4]
In-Reply-To: <Od7ZqIktrLxS95Opus0ZhJulAwD1KGHvsHd68dRKmJA=.2a577e2a-f535-4946-afbd-41bb412daf54@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>
 <Od7ZqIktrLxS95Opus0ZhJulAwD1KGHvsHd68dRKmJA=.2a577e2a-f535-4946-afbd-41bb412daf54@github.com>
Message-ID: <AtJZSqPpzagk4P_DrcIGYk69FrFp18EV-aa64UAMvZA=.07ed6fc4-f790-4938-b1cc-3395e2d6b288@github.com>

On Fri, 23 Jun 2023 06:49:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8222329: Correct return verbiage of Reader and CharBuffer
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 484:
> 
>> 482:      * @throws ReadOnlyBufferException if target is a read only buffer,
>> 483:      *         even if it is empty
>> 484:      * @since 1.5
> 
> It might be clearer if this method linked to the length method. That way it could be specified to return 0 when the length of the target buffer is 0.
> 
> For the @throws of ROBE, probably need to avoid the word "empty", only because this method writes to the target buffer, it doesn't read from the target buffer.

Addressed in 94505a45ce099faf3e31a07b8500ac456345a3b1; CSR not yet updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1239968591

From bpb at openjdk.org  Fri Jun 23 16:36:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 16:36:16 GMT
Subject: RFR: 8310682: No package-info (and @since) for package jdk.nio.mapmode
Message-ID: <E5ex0jxUOFEh37YeVi_ZzJG4WUGzp61JgdXDncGpdoQ=.1f29c122-2de6-4195-9712-835a15ccec53@github.com>

Add `package-info.java` for package `jdk.nio.mapmode`.

-------------

Commit messages:
 - 8310682: No package-info (and @since) for package jdk.nio.mapmode

Changes: https://git.openjdk.org/jdk/pull/14628/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14628&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310682
  Stats: 33 lines in 1 file changed: 33 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14628/head:pull/14628

PR: https://git.openjdk.org/jdk/pull/14628

From jbhateja at openjdk.org  Fri Jun 23 16:52:09 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 23 Jun 2023 16:52:09 GMT
Subject: RFR: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor VectorShuffle
 implementation
Message-ID: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>

Backing out shuffle related overhaul done with [JDK-8304450](https://bugs.openjdk.org/browse/JDK-8304450), we saw significant performance degradation with VectorAPI JMH and our internal benchmarks. Following two issues were filed on this recently.

1/ [JDK-8310459](https://bugs.openjdk.org/browse/JDK-8310459): We observed significant performance drop in VectorAPI slice / unslice performance w.r.t to JDK-20.
2/ [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373): Performance drop in Vector-API based kernel with JDK-21.

A follow-up JBS [JDK-8310691](https://bugs.openjdk.org/browse/JDK-8310691) is created to address this in JDK-22.

Best Regards,
Jatin

-------------

Commit messages:
 - 8310459: [BACKOUT] 8304450: [vectorapi] Refactor VectorShuffle implementation

Changes: https://git.openjdk.org/jdk/pull/14629/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14629&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310459
  Stats: 3895 lines in 64 files changed: 1169 ins; 1819 del; 907 mod
  Patch: https://git.openjdk.org/jdk/pull/14629.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14629/head:pull/14629

PR: https://git.openjdk.org/jdk/pull/14629

From alanb at openjdk.org  Fri Jun 23 16:53:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Jun 2023 16:53:04 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v4]
In-Reply-To: <AtJZSqPpzagk4P_DrcIGYk69FrFp18EV-aa64UAMvZA=.07ed6fc4-f790-4938-b1cc-3395e2d6b288@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>
 <Od7ZqIktrLxS95Opus0ZhJulAwD1KGHvsHd68dRKmJA=.2a577e2a-f535-4946-afbd-41bb412daf54@github.com>
 <AtJZSqPpzagk4P_DrcIGYk69FrFp18EV-aa64UAMvZA=.07ed6fc4-f790-4938-b1cc-3395e2d6b288@github.com>
Message-ID: <HmCbSeSHvwD-wgHdCNXn1WYK_oNzx1Nvid1T8Y7V7oU=.44d9bffd-f309-4a64-8fd6-06dcdbdf6f0e@github.com>

On Fri, 23 Jun 2023 15:38:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 484:
>> 
>>> 482:      * @throws ReadOnlyBufferException if target is a read only buffer,
>>> 483:      *         even if it is empty
>>> 484:      * @since 1.5
>> 
>> It might be clearer if this method linked to the length method. That way it could be specified to return 0 when the length of the target buffer is 0.
>> 
>> For the @throws of ROBE, probably need to avoid the word "empty", only because this method writes to the target buffer, it doesn't read from the target buffer.
>
> Addressed in 94505a45ce099faf3e31a07b8500ac456345a3b1; CSR not yet updated.

I checked the update but it now has "no source remaining or its length is zero". In CB, length == remaining so I think you just want one in the description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240038493

From aivanov at openjdk.org  Fri Jun 23 16:56:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 16:56:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
 <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
 <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>
Message-ID: <EXUYhWNGG35nKS3WIDouUG588SsAUq3MzJfIxA7UPFs=.4f874737-bf89-43ad-833d-b815bc6dab4c@github.com>

On Fri, 23 Jun 2023 14:30:49 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> To minimise the number of changes, we can go for using `jint` in `AwtMenu::GetItem`.
>> 
>> What do you thing, @djelinski and @TheShermanTanker?
>
> Hmm, I lean towards jint as I feel it conveys the fact that it is a Java parameter clearer, intuitively to me it makes sense that a Java integer type would still work in a C++ for loop in native code

You're right? it gives a hint it'll be an upcall into Java. Let's go for `jint` then.

I don't think there's a need to change the type of the for-loop variable to `jint`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1240041248

From jwaters at openjdk.org  Fri Jun 23 16:59:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 16:59:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <EXUYhWNGG35nKS3WIDouUG588SsAUq3MzJfIxA7UPFs=.4f874737-bf89-43ad-833d-b815bc6dab4c@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
 <hQct1uuJRoFhFu_m7bL7ojtdCgFMWhh1L4kZcmtkZZI=.8b64cfee-08ee-4a6d-a256-7a6674d34ea5@github.com>
 <4XUr19lXHho95I9rleAZZXwyaIgZGL3pr77HqMRFCVQ=.de59b9ea-c7dd-4056-bebe-019c84a7ac54@github.com>
 <rB1JfUiYnfU0pqm3jFZj0wBOB0GuAftbZnSRBRq_Xmo=.d0951979-6d93-475f-880e-6977892ff7c5@github.com>
 <ApH0B1EnT2_WNk5ojWuyPljOv30AiGN8X9ZBGUmEZNQ=.305895df-25f4-4b07-96ff-e2d3cd4d09af@github.com>
 <EXUYhWNGG35nKS3WIDouUG588SsAUq3MzJfIxA7UPFs=.4f874737-bf89-43ad-833d-b815bc6dab4c@github.com>
Message-ID: <bdR0sm_lnZmnnl_A9aEYIymH0RH8InYxi8JgcJ2-4zw=.4a44db67-31cd-4ec4-9533-5c9cda88fe14@github.com>

On Fri, 23 Jun 2023 16:53:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Hmm, I lean towards jint as I feel it conveys the fact that it is a Java parameter clearer, intuitively to me it makes sense that a Java integer type would still work in a C++ for loop in native code
>
> You're right? it gives a hint it'll be an upcall into Java. Let's go for `jint` then.
> 
> I don't think there's a need to change the type of the for-loop variable to `jint`.

Oh no, I didn't mean to change the loop variable, rather that leaving the jint as is should be fine in the for loop

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1240044495

From mchung at openjdk.org  Fri Jun 23 17:06:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 23 Jun 2023 17:06:12 GMT
Subject: Integrated: JDK-8310460: Remove jdeps -profile option
In-Reply-To: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>
References: <-hGihw2JlEDwi4hTfaBKKkkZlJvWzMedJO9sKaFC1WE=.117cbc2d-fa8c-4f99-8e68-974854514c7d@github.com>
Message-ID: <pLCUt6l_Zxjg0ZXUC6mPQil4SWNCqW5kESME7Bwf0JI=.c3f955c9-195b-4aac-a204-2ff49fbbb8da@github.com>

On Tue, 20 Jun 2023 18:42:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Compact profiles are defined in Java SE 8 and are legacy in Java SE 9. jdeps -profile option was deprecated for removal in JDK 21. This option can be removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.

This pull request has now been integrated.

Changeset: 556831d1
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/556831d1bf80a919330d9ca5330b4deef16592e2
Stats:     384 lines in 9 files changed: 0 ins; 329 del; 55 mod

8310460: Remove jdeps -profile option

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14570

From naoto at openjdk.org  Fri Jun 23 17:08:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Jun 2023 17:08:12 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
 <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
 <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>
Message-ID: <IpzjmCSAYxfa8TjZKuq8vSil9zD4AwrQttpMDlMzOLk=.30818f2b-57e4-4185-b4d5-c1f7493943a1@github.com>

On Fri, 23 Jun 2023 15:11:47 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Yes:
>> 
>> CacheKey(String baseName, Locale locale, Module module, Module caller) {
>>     Objects.requireNonNull(module);
>>     Objects.requireNonNull(caller);
>> 
>>     this.name = baseName;
>>     this.locale = locale;
>>     this.moduleRef = new KeyElementReference<>(module, referenceQueue, this);
>>     this.callerRef = new KeyElementReference<>(caller, referenceQueue, this);
>>     this.modulesHash = module.hashCode() ^ caller.hashCode();
>> }
>
> I'll run our CI, and if all good, I'll approve this PR. If nothing else, this change seems reasonable and correct.

Thanks Pavel for jumping in. I too think this change looks good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240055000

From jwaters at openjdk.org  Fri Jun 23 17:09:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 17:09:12 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v12]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - Swap to jint in awt_MenuBar.h
 - Swap to jint in awt_MenuBar.cpp
 - Swap to jint in awt_Menu.h

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/16b5a914..d5f74cc2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=10-11

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From jwaters at openjdk.org  Fri Jun 23 17:09:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 17:09:14 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v11]
In-Reply-To: <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <CAlxtbuE_kczEu-wKxKCv6QrL0ujojj2ktAkdk7YEq0=.d2f303af-c2ef-4480-9854-cf1666eeff0d@github.com>
Message-ID: <6LhofTh1RYX22niDjY1cPgArtX7E5Ghm4880ulFgUmI=.7326b3e2-8dd6-4e49-bf88-c91e4b93bbed@github.com>

On Fri, 23 Jun 2023 02:38:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert wrong Copyright
>  - Copyright

Alright, waiting for you to do the honours :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1604563651

From bpb at openjdk.org  Fri Jun 23 17:10:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 17:10:07 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v4]
In-Reply-To: <HmCbSeSHvwD-wgHdCNXn1WYK_oNzx1Nvid1T8Y7V7oU=.44d9bffd-f309-4a64-8fd6-06dcdbdf6f0e@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>
 <Od7ZqIktrLxS95Opus0ZhJulAwD1KGHvsHd68dRKmJA=.2a577e2a-f535-4946-afbd-41bb412daf54@github.com>
 <AtJZSqPpzagk4P_DrcIGYk69FrFp18EV-aa64UAMvZA=.07ed6fc4-f790-4938-b1cc-3395e2d6b288@github.com>
 <HmCbSeSHvwD-wgHdCNXn1WYK_oNzx1Nvid1T8Y7V7oU=.44d9bffd-f309-4a64-8fd6-06dcdbdf6f0e@github.com>
Message-ID: <HB3mqopI7AzzzMAXVKrRUmkU9XAQUjtjMKNonRsLEtk=.1820af69-4a3a-4189-baf3-20be6e2bb56e@github.com>

On Fri, 23 Jun 2023 16:50:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Addressed in 94505a45ce099faf3e31a07b8500ac456345a3b1; CSR not yet updated.
>
> I checked the update but it now has "no source remaining or its length is zero". In CB, length == remaining so I think you just want one in the description.

Ah, good catch!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240057409

From bpb at openjdk.org  Fri Jun 23 17:19:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 17:19:10 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v6]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <ldMsh77B4tz619iaYvUrmmftTCdCSrumt5oWPK-GeP0=.af6372b9-5ad9-4736-b3a8-eea576fd1e65@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: Remove redundancy of length vs. remaining in CharBuffer::read doc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/94505a45..7281b482

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From bpb at openjdk.org  Fri Jun 23 17:19:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 17:19:12 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v4]
In-Reply-To: <HB3mqopI7AzzzMAXVKrRUmkU9XAQUjtjMKNonRsLEtk=.1820af69-4a3a-4189-baf3-20be6e2bb56e@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <GmnAsUCjvZEncljOlIY_6CwyoOnGRFCJ8LkLgF2kxwc=.9b24fc47-e865-4c47-9145-e1a46ef50371@github.com>
 <Od7ZqIktrLxS95Opus0ZhJulAwD1KGHvsHd68dRKmJA=.2a577e2a-f535-4946-afbd-41bb412daf54@github.com>
 <AtJZSqPpzagk4P_DrcIGYk69FrFp18EV-aa64UAMvZA=.07ed6fc4-f790-4938-b1cc-3395e2d6b288@github.com>
 <HmCbSeSHvwD-wgHdCNXn1WYK_oNzx1Nvid1T8Y7V7oU=.44d9bffd-f309-4a64-8fd6-06dcdbdf6f0e@github.com>
 <HB3mqopI7AzzzMAXVKrRUmkU9XAQUjtjMKNonRsLEtk=.1820af69-4a3a-4189-baf3-20be6e2bb56e@github.com>
Message-ID: <fT9ZhcNjB2nc088UwTVwtqph8NiIF3aFH6dS0-6Wxp8=.24e4fbc9-01f8-4a37-acea-cfd91f366472@github.com>

On Fri, 23 Jun 2023 17:07:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I checked the update but it now has "no source remaining or its length is zero". In CB, length == remaining so I think you just want one in the description.
>
> Ah, good catch!

Fixed by 7281b482c24a3c74da15dbf637f7627c5dc5407b.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240066381

From darcy at openjdk.org  Fri Jun 23 17:25:00 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 17:25:00 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v2]
In-Reply-To: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
Message-ID: <bpwgXIrqVdh7At6Dwj5lqp6LcZNb62ypeflxkIBI7lE=.3d22db1c-921c-40b4-ae7b-b0ceb87191ae@github.com>

> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

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:

 - Respond to review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8310267
 - Fix whitespace.
 - JDK-8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14574/files
  - new: https://git.openjdk.org/jdk/pull/14574/files/fdb9b67a..9d05b090

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=00-01

  Stats: 6296 lines in 326 files changed: 3053 ins; 909 del; 2334 mod
  Patch: https://git.openjdk.org/jdk/pull/14574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14574/head:pull/14574

PR: https://git.openjdk.org/jdk/pull/14574

From mcimadamore at openjdk.org  Fri Jun 23 17:30:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 Jun 2023 17:30:07 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v2]
In-Reply-To: <RIMeNZVOoqhIfP0DdA9RhEr7aoBb2UFVf86XfmcxCUo=.1501b11d-62a8-4031-bf8e-0158b646ce89@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <RIMeNZVOoqhIfP0DdA9RhEr7aoBb2UFVf86XfmcxCUo=.1501b11d-62a8-4031-bf8e-0158b646ce89@github.com>
Message-ID: <Z8ahKnTFtz6jefg6I84SbZBNBbMVUdJTXNbVXK7A66g=.22ce98b2-532d-49f1-b13a-ce6c487d0829@github.com>

On Wed, 21 Jun 2023 23:33:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   polish doc, review comments

src/java.base/share/classes/java/lang/foreign/Linker.java line 654:

> 652:          * <ul>
> 653:          * <li>{@code 0}, all arguments passed to the function are passed as variadic arguments</li>
> 654:          * <li>{@code N}, none of the arguments passed to the function are passed as variadic argument</li>

Suggestion:

         * <li>{@code N}, none of the arguments passed to the function are passed as variadic argumenst</li>

src/java.base/share/classes/java/lang/foreign/Linker.java line 658:

> 656:          * </ul>
> 657:          * It is important to always use this linker option when linking a <a href=Linker.html#variadic-funcs>variadic
> 658:          * function</a>, even when none of the arguments are passed as variadic arguments (the second case in the list

Suggestion:

         * function</a>, even if no variadic argument is passed (the second case in the list

src/java.base/share/classes/java/lang/foreign/Linker.java line 659:

> 657:          * It is important to always use this linker option when linking a <a href=Linker.html#variadic-funcs>variadic
> 658:          * function</a>, even when none of the arguments are passed as variadic arguments (the second case in the list
> 659:          * above), as this affects the linking process on certain platforms.

Suggestion:

         * above), as this might still affect the calling convention on certain platforms.

src/java.base/share/classes/java/lang/foreign/Linker.java line 664:

> 662:          *           against which the index is validated is available.
> 663:          *
> 664:          * @param index the index indicating the start of the variadic arguments passed to the function described by

My general feeling is that the previous text was better here. We describe in plenty details what this "index" is in the method javadoc. I think I'm more for reverting the changes here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1240079184
PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1240081468
PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1240083169
PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1240087788

From mcimadamore at openjdk.org  Fri Jun 23 17:30:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 23 Jun 2023 17:30:08 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v2]
In-Reply-To: <Z8ahKnTFtz6jefg6I84SbZBNBbMVUdJTXNbVXK7A66g=.22ce98b2-532d-49f1-b13a-ce6c487d0829@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <RIMeNZVOoqhIfP0DdA9RhEr7aoBb2UFVf86XfmcxCUo=.1501b11d-62a8-4031-bf8e-0158b646ce89@github.com>
 <Z8ahKnTFtz6jefg6I84SbZBNBbMVUdJTXNbVXK7A66g=.22ce98b2-532d-49f1-b13a-ce6c487d0829@github.com>
Message-ID: <aGebTXFY9EcbAZ5JgMFZInoqOBbVR9cj9ffRn3W_1XM=.2876d1dd-6e3f-4652-b770-056c62b15b43@github.com>

On Fri, 23 Jun 2023 17:24:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   polish doc, review comments
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 659:
> 
>> 657:          * It is important to always use this linker option when linking a <a href=Linker.html#variadic-funcs>variadic
>> 658:          * function</a>, even when none of the arguments are passed as variadic arguments (the second case in the list
>> 659:          * above), as this affects the linking process on certain platforms.
> 
> Suggestion:
> 
>          * above), as this might still affect the calling convention on certain platforms.

Note: we use the term calling convention in Linker javadoc - I think it's slightly more precise than "linking process".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14565#discussion_r1240083929

From darcy at openjdk.org  Fri Jun 23 17:33:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 17:33:03 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v2]
In-Reply-To: <T4eouINL7seCi6IWJgnBLk9f_YKPrlId7XLrkariRak=.bb2fb1f1-333b-49fc-aa97-a3101ff80911@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <UofHbzbZSfLSZNT0mkmG8hRenOdywnOEragpKrOIKFM=.df166dfb-9927-4897-811d-4545ef9ca97e@github.com>
 <eZ-Bg0GsEUDN5wYLqLHDl6mS16RFGXCiw57ctEegS8w=.0ac89af6-b1ba-45b9-8f60-ae69098f5da8@github.com>
 <kSPafWmL6pvFXaEbExLgiYMfaMSLn_KCZ1LN3OKSiBY=.87497c6c-e04f-4d30-becc-dc32a35dd1b6@github.com>
 <8Rz8rcc-K11xpeGqoSUNt9n2KvSYXsdR7typFgXt-go=.0c1dab5f-e06d-42b0-840c-74b69b9de237@github.com>
 <T4eouINL7seCi6IWJgnBLk9f_YKPrlId7XLrkariRak=.bb2fb1f1-333b-49fc-aa97-a3101ff80911@github.com>
Message-ID: <UqnTcCc-vmWaio7cQBEcvGHF7b4tTlk8wTck0LUwD_M=.00ce8eae-9b00-499f-acb6-f597fbd124dd@github.com>

On Fri, 23 Jun 2023 11:58:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Thanks for the links, @pavelrappo.
>> 
>> I understand the point you're making; however, there is still ambiguous wording in the documentation for this method.
>> 
>> The method is called `isPrimitive`, and it returns `true` for `isPrimitive(void.class)`. In addition, the first sentence states: "Determines if the specified `Class` object represents a primitive type."
>> 
>> Note as well that the documentation states "There are nine predefined ..." but then goes on to only list 8 names.
>> 
>> So, in line with the intent of the method with regard to `void`, it should be clear to the user that `void` is the name for the type `void.class` (and `Void.TYPE`).
>> 
>> Perhaps the easiest way to include `void.class` and match the 9 predefined types with their names is to remove "primitive" from "as the primitive types that" and replace `and {@code double}` with `{@code double}, and {@code void}`.
>> 
>> Along that line of thinking, it might be best to change the first sentence to "Determines if the specified `Class` object represents a primitive type or void." And the return statement should be changed to `@return true if and only if this class represents a primitive type or void`.
>
>> Along that line of thinking, it might be best to change the first sentence to "Determines if the specified Class object represents a primitive type or void."
> 
> I was just about to suggest exactly that, but from the superinterface method's perspective. Here's what I had been writing when received your message:
> 
> At the same, time java.lang.invoke.TypeDescriptor.OfField#isPrimitive:
> 
>         /**
>          * Does this field descriptor describe a primitive type (including void.)
>          *
>          * @return whether this field descriptor describes a primitive type
>          */
>         boolean isPrimitive();
> 
> I suggest rephrasing that and similar text elsewhere, for example, as follows:
> 
>     /** {@return whether this field descriptor describes a primitive type or void} */
>     boolean isPrimitive();

The functionality of the method is "isPrimitiveTypeOrVoid" as void is technically not a type, etc.; however, the method is named "isPrimitive" and that is most of what it does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1240093494

From prappo at openjdk.org  Fri Jun 23 17:47:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 17:47:05 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v2]
In-Reply-To: <bpwgXIrqVdh7At6Dwj5lqp6LcZNb62ypeflxkIBI7lE=.3d22db1c-921c-40b4-ae7b-b0ceb87191ae@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <bpwgXIrqVdh7At6Dwj5lqp6LcZNb62ypeflxkIBI7lE=.3d22db1c-921c-40b4-ae7b-b0ceb87191ae@github.com>
Message-ID: <wWvQ3B7BfYjxyMH1EdDGm1ZHxB2N4FKSjWXHe2GAAcw=.974db7cd-936d-4622-9a9e-67202b3cd1ac@github.com>

On Fri, 23 Jun 2023 17:25:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.
>
> 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:
> 
>  - Respond to review feedback.
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8310267
>  - Fix whitespace.
>  - JDK-8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives

src/java.base/share/classes/java/lang/Class.java line 823:

> 821:      *
> 822:      * @apiNote
> 823:      * A {@code Class} object represented a primitive type can be

Not a native speaker, but "representED" not "representING"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14574#discussion_r1240107268

From darcy at openjdk.org  Fri Jun 23 17:57:22 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 17:57:22 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v3]
In-Reply-To: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
Message-ID: <gyNmGakSmAXPs47QsV5FPVLrnhAxRxZbvMkEvK0a7u8=.ce2fe270-229f-4453-ac35-3076a71dda7e@github.com>

> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14574/files
  - new: https://git.openjdk.org/jdk/pull/14574/files/9d05b090..9f4a5555

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14574/head:pull/14574

PR: https://git.openjdk.org/jdk/pull/14574

From prappo at openjdk.org  Fri Jun 23 18:05:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 18:05:07 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v3]
In-Reply-To: <gyNmGakSmAXPs47QsV5FPVLrnhAxRxZbvMkEvK0a7u8=.ce2fe270-229f-4453-ac35-3076a71dda7e@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <gyNmGakSmAXPs47QsV5FPVLrnhAxRxZbvMkEvK0a7u8=.ce2fe270-229f-4453-ac35-3076a71dda7e@github.com>
Message-ID: <OInMt62yayV9MNACFg5nBZRYUeL6-HQL_gzUr3D07yE=.ee819e9f-8803-47d8-8314-b769b04432f2@github.com>

On Fri, 23 Jun 2023 17:57:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo.

Looks good to me.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14574#pullrequestreview-1495641556

From aivanov at openjdk.org  Fri Jun 23 18:05:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 23 Jun 2023 18:05:13 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v12]
In-Reply-To: <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
Message-ID: <IWwjatEYIjQu7eT1_3MBUgza4BTmS0Gbro-ZJfmKQwY=.5eec9d8d-462d-4865-9f6d-347b747af77e@github.com>

On Fri, 23 Jun 2023 17:09:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Swap to jint in awt_MenuBar.h
>  - Swap to jint in awt_MenuBar.cpp
>  - Swap to jint in awt_Menu.h

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 1126:

> 1124: 
> 1125:             // Free bitmap buffers if they were allocated
> 1126:             if (colorBits != nullptr) {

Let's revert `nullptr` to `NULL`.

The `NULL` value is used consistently inside `_Win32ShellFolder2_getIconBits` function as well as through out the file, so `nullptr` is out of place.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1495623168
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1240121736

From prappo at openjdk.org  Fri Jun 23 18:14:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 18:14:05 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v3]
In-Reply-To: <gyNmGakSmAXPs47QsV5FPVLrnhAxRxZbvMkEvK0a7u8=.ce2fe270-229f-4453-ac35-3076a71dda7e@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <gyNmGakSmAXPs47QsV5FPVLrnhAxRxZbvMkEvK0a7u8=.ce2fe270-229f-4453-ac35-3076a71dda7e@github.com>
Message-ID: <bSFVF3zwQh3HiWXgpLGGJRmc5MvL_G8HgmuGCW3hN6U=.2ffb8f82-4b9e-470a-9473-24eb16761e2b@github.com>

On Fri, 23 Jun 2023 17:57:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo.

Only after I have approved the change, did I re-read the whole thing again. Would you be able to fix this in this PR too? (Sorry.)

    /**
     * Determines if the specified {@code Class} object represents a
     * primitive type.
...

There's no "specified class object",  it's **this** class object. That method has zero parameters.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14574#issuecomment-1604659632

From duke at openjdk.org  Fri Jun 23 19:34:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 23 Jun 2023 19:34:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v21]
In-Reply-To: <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>
Message-ID: <JE6bJgXjC2W4yC8JMdnIQvKYe-dKBd4eCczD-xx0E10=.74bf8d97-11bb-4687-b717-a6e8343714d5@github.com>

On Fri, 23 Jun 2023 11:24:23 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format code

src/java.base/share/classes/java/lang/Long.java line 493:

> 491:                         | H256[((int) lsb) & 0xff]);
> 492: 
> 493:         return new String(buf, LATIN1);

Note?that this?isn?t?correct when?`COMPACT_STRINGS` is?`false`, as?then?`buf` is?always?interpreted as?having a?`coder`?of?`UTF16`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1240231921

From dcubed at openjdk.org  Fri Jun 23 19:38:26 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 23 Jun 2023 19:38:26 GMT
Subject: [jdk21] RFR: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
Message-ID: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>

A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.

-------------

Commit messages:
 - 8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64

Changes: https://git.openjdk.org/jdk21/pull/60/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=60&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310822
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/60.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/60/head:pull/60

PR: https://git.openjdk.org/jdk21/pull/60

From darcy at openjdk.org  Fri Jun 23 19:41:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 19:41:17 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v4]
In-Reply-To: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
Message-ID: <OLl-tLDgExtySNhmim7KZx1Wm1HfRYxQJGlsTwjKRH0=.f4abfcdb-1102-44e6-a355-be10f67c13e7@github.com>

> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix another typo and reflow paragraphs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14574/files
  - new: https://git.openjdk.org/jdk/pull/14574/files/9f4a5555..82a42ab9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14574&range=02-03

  Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14574/head:pull/14574

PR: https://git.openjdk.org/jdk/pull/14574

From darcy at openjdk.org  Fri Jun 23 19:41:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 19:41:18 GMT
Subject: Integrated: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives
In-Reply-To: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
Message-ID: <EB1I1fEHdgHCZ_EPclbLBvdRqsmN9zu9nskrfLfs_FY=.cc7aa93b-678d-4124-aac0-b6b9067f4f1b@github.com>

On Wed, 21 Jun 2023 00:00:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.

This pull request has now been integrated.

Changeset: 0314292c
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0314292cb2d55474d8fb3d0ef46129be7e4f1838
Stats:     21 lines in 1 file changed: 10 ins; 0 del; 11 mod

8310267: Javadoc for Class#isPrimitive() is incorrect regarding Class objects for primitives

Reviewed-by: prappo

-------------

PR: https://git.openjdk.org/jdk/pull/14574

From lmesnik at openjdk.org  Fri Jun 23 19:48:10 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Jun 2023 19:48:10 GMT
Subject: [jdk21] RFR: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
In-Reply-To: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
References: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
Message-ID: <eOKUeglxLchCp7iGn6D8wTm-gtbTz-43jnZI3I12mjI=.21961806-2f38-4120-97dd-c8bb15158eea@github.com>

On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.

Changes requested by lmesnik (Reviewer).

test/jdk/ProblemList-Xcomp.txt line 31:

> 29: 
> 30: java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 generic-all
> 31: java/lang/ScopedValue/StressStackOverflow.java 8308609 generic-x64

java/lang/ScopedValue/StressStackOverflow.java#no-vmcontinuations ?

-------------

PR Review: https://git.openjdk.org/jdk21/pull/60#pullrequestreview-1495822775
PR Review Comment: https://git.openjdk.org/jdk21/pull/60#discussion_r1240249942

From iris at openjdk.org  Fri Jun 23 19:48:09 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 23 Jun 2023 19:48:09 GMT
Subject: [jdk21] RFR: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
In-Reply-To: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
References: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
Message-ID: <qNIxFUllvQWYIUs9QywZfFYWIU8uju0GTg4pIrkZ3ac=.9a157663-05c4-4591-91ab-3e5c7c65fbbf@github.com>

On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/60#pullrequestreview-1495822256

From lmesnik at openjdk.org  Fri Jun 23 19:52:07 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Jun 2023 19:52:07 GMT
Subject: [jdk21] RFR: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
In-Reply-To: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
References: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
Message-ID: <gYoIK8fFPHXl-DnjflnPdlovpXG18n5tJXHDdjIaobU=.53e87f52-8cf7-47c3-abc7-f1754014b5ec@github.com>

On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/60#pullrequestreview-1495844009

From dcubed at openjdk.org  Fri Jun 23 19:52:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 23 Jun 2023 19:52:11 GMT
Subject: [jdk21] RFR: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
In-Reply-To: <eOKUeglxLchCp7iGn6D8wTm-gtbTz-43jnZI3I12mjI=.21961806-2f38-4120-97dd-c8bb15158eea@github.com>
References: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
 <eOKUeglxLchCp7iGn6D8wTm-gtbTz-43jnZI3I12mjI=.21961806-2f38-4120-97dd-c8bb15158eea@github.com>
Message-ID: <1pAfV4FoIQmaS53ho_8gdgZn5Lnk_1auLceUUmourPc=.499d4498-9e0f-4fd3-91be-1887083b667f@github.com>

On Fri, 23 Jun 2023 19:45:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.
>
> test/jdk/ProblemList-Xcomp.txt line 31:
> 
>> 29: 
>> 30: java/lang/invoke/MethodHandles/CatchExceptionTest.java 8146623 generic-all
>> 31: java/lang/ScopedValue/StressStackOverflow.java 8308609 generic-x64
> 
> java/lang/ScopedValue/StressStackOverflow.java#no-vmcontinuations ?

Nope. This is the JDK21 version of the test and not the JDK22 version of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk21/pull/60#discussion_r1240258561

From dcubed at openjdk.org  Fri Jun 23 19:52:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 23 Jun 2023 19:52:08 GMT
Subject: [jdk21] RFR: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
In-Reply-To: <qNIxFUllvQWYIUs9QywZfFYWIU8uju0GTg4pIrkZ3ac=.9a157663-05c4-4591-91ab-3e5c7c65fbbf@github.com>
References: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
 <qNIxFUllvQWYIUs9QywZfFYWIU8uju0GTg4pIrkZ3ac=.9a157663-05c4-4591-91ab-3e5c7c65fbbf@github.com>
Message-ID: <m2TdwhUfsyl50Ah3FkFXBV7ZwbpssDp8XL_3Wbuh0PI=.ccac5de1-2198-4072-8184-ef6774b0900f@github.com>

On Fri, 23 Jun 2023 19:44:50 GMT, Iris Clark <iris at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.
>
> Marked as reviewed by iris (Reviewer).

@irisclark and @lmesnik - Thanks for the fast reviews!

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/60#issuecomment-1604810661

From dcubed at openjdk.org  Fri Jun 23 19:56:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 23 Jun 2023 19:56:03 GMT
Subject: [jdk21] Integrated: 8310822: JDK21: ProblemList
 java/lang/ScopedValue/StressStackOverflow.java on generic-x64
In-Reply-To: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
References: <MYzhnIkIZcyAF9VQs9GS3Urx14yC40p5N8LcyJdCWio=.f11cc9d0-8014-44fc-b4c2-36d6a49f1a20@github.com>
Message-ID: <rWTMo1EJRVs6JntUbuDoG6Rbbf-tg3yyiWzPmhIoRNM=.c26783e8-131c-4dd7-b6b2-849488f886ea@github.com>

On Fri, 23 Jun 2023 19:30:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64.

This pull request has now been integrated.

Changeset: af3a56e5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/af3a56e56901a1ec1e532c8f04c573cff77c5ed0
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8310822: JDK21: ProblemList java/lang/ScopedValue/StressStackOverflow.java on generic-x64

Reviewed-by: iris, lmesnik

-------------

PR: https://git.openjdk.org/jdk21/pull/60

From prappo at openjdk.org  Fri Jun 23 20:22:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 20:22:15 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <IpzjmCSAYxfa8TjZKuq8vSil9zD4AwrQttpMDlMzOLk=.30818f2b-57e4-4185-b4d5-c1f7493943a1@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <N16S5EDwZ_WE2zQFtKGoHrkuHrOBbZznpbJYt5MHqDo=.f3237a72-7704-4c3c-86d2-072eea8b504f@github.com>
 <VURgvgFqNMUbReCcHrxHN6B3VIbV8JEjbZFtvkJrFEI=.3a7e1db1-e26c-41db-9c4c-46b073607e7c@github.com>
 <XmsdAzRaKH9B131ovAKAAbdRpQb12vp_IQQrZKj1gbk=.cfae6480-1a57-4d3a-9055-c48830db1279@github.com>
 <IpzjmCSAYxfa8TjZKuq8vSil9zD4AwrQttpMDlMzOLk=.30818f2b-57e4-4185-b4d5-c1f7493943a1@github.com>
Message-ID: <xbDWlLVUjAEN5NAUBbZzrqfegkuXsDqV2X8HYjZg3Uc=.b28506b0-2fcb-4f2b-b6a9-d9720dac0718@github.com>

On Fri, 23 Jun 2023 17:05:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I'll run our CI, and if all good, I'll approve this PR. If nothing else, this change seems reasonable and correct.
>
> Thanks Pavel for jumping in. I too think this change looks good.

Yep; all good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240336318

From prappo at openjdk.org  Fri Jun 23 20:22:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 20:22:13 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <XFf532ACWGl8SAwAfGa7syCi1T44Qsrwd-fFtpOwK08=.305c1c0c-0740-48f7-9577-662c51a35dd7@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Looks good; thanks.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1495944192

From rriggs at openjdk.org  Fri Jun 23 20:36:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Jun 2023 20:36:09 GMT
Subject: RFR: 8308694: Clarify reversed() default methods' implementation
 requirements [v2]
In-Reply-To: <SsNbvnJT-hBYoXxzwgz3efsfrHTwnXOm1rYzOUjTb08=.3a0f171c-a9c1-40c0-8b83-2971dea6fbfd@github.com>
References: <KiFsVbhggmTq9dInFv1zD21f8JNuMpFVXj1873Q-AtU=.5d9a2431-23d2-4312-9633-70eea5855f8b@github.com>
 <SsNbvnJT-hBYoXxzwgz3efsfrHTwnXOm1rYzOUjTb08=.3a0f171c-a9c1-40c0-8b83-2971dea6fbfd@github.com>
Message-ID: <eZkmhGnn8oSR2TgoMvI_F3Yvivx0c4pGSgmH0sK2yGo=.27b48c0a-0463-411c-a53e-e9c9aca69c67@github.com>

On Thu, 22 Jun 2023 22:07:19 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Can I get a preliminary review of the wording for Deque.reversed()? If the text is good, I'll make corresponding changes to the implSpecs of the other reversed() default methods, namely those in List, SortedMap, and SortedSet and then file the CSR.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to avoid overspecification.

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14504#pullrequestreview-1495967702

From rriggs at openjdk.org  Fri Jun 23 20:40:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Jun 2023 20:40:17 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v6]
In-Reply-To: <ldMsh77B4tz619iaYvUrmmftTCdCSrumt5oWPK-GeP0=.af6372b9-5ad9-4736-b3a8-eea576fd1e65@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <ldMsh77B4tz619iaYvUrmmftTCdCSrumt5oWPK-GeP0=.af6372b9-5ad9-4736-b3a8-eea576fd1e65@github.com>
Message-ID: <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com>

On Fri, 23 Jun 2023 17:19:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8222329: Remove redundancy of length vs. remaining in CharBuffer::read doc

Looks good but for one typo.

src/java.base/share/classes/java/io/Reader.java line 194:

> 192:      * rewinding of the buffer is performed.  If the specified character
> 193:      * buffer has no space {@linkplain java.nio.Buffer#hasRemaining
> 194:      * remaining} or or its {@linkplain java.nio.CharBuffer#length length}

typo: "or or" -> "or"

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1495972372
PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240353636

From rriggs at openjdk.org  Fri Jun 23 20:41:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Jun 2023 20:41:05 GMT
Subject: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]
In-Reply-To: <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
References: <i41whbvbI1rLebQrnQdC5h1GF_SMu7e8bst-FnQ5EpU=.463595d7-2901-42d9-bb6e-e293db1e0ad0@github.com>
 <VIGL8rj2ZK4my8r8r-frJaTmmdS9Q4yXV8HRhjebRMo=.f0e22df6-a40f-4e56-a082-961c771258e9@github.com>
Message-ID: <byTKjqn_004_r1tmp2ZaAf-kTEmxgppbguqKr5iSQ4o=.921aea2a-63c5-4f75-a1f3-0cd4c2a919f2@github.com>

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Just a tiny clean-up to remove racy read within synchronized method
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/io/PipedOutputStream.java
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14589#pullrequestreview-1495974637

From naoto at openjdk.org  Fri Jun 23 20:44:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Jun 2023 20:44:13 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <fvB7deef3tBtzIjFzbEqQpfKtxqvNKIc0QtEOQZtMM8=.fe768c0d-289e-4e03-803c-f25e70a94639@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1495986139

From bpb at openjdk.org  Fri Jun 23 20:49:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 20:49:06 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v6]
In-Reply-To: <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <ldMsh77B4tz619iaYvUrmmftTCdCSrumt5oWPK-GeP0=.af6372b9-5ad9-4736-b3a8-eea576fd1e65@github.com>
 <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com>
Message-ID: <pgFVKhT1KCIEDjBCtVDlGS_iK_a1JjGkyLOtJJJPuJw=.da1b4aef-626c-4007-8c0d-c9c32672889a@github.com>

On Fri, 23 Jun 2023 20:36:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8222329: Remove redundancy of length vs. remaining in CharBuffer::read doc
>
> src/java.base/share/classes/java/io/Reader.java line 194:
> 
>> 192:      * rewinding of the buffer is performed.  If the specified character
>> 193:      * buffer has no space {@linkplain java.nio.Buffer#hasRemaining
>> 194:      * remaining} or or its {@linkplain java.nio.CharBuffer#length length}
> 
> typo: "or or" -> "or"

Bummer. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240371637

From bpb at openjdk.org  Fri Jun 23 20:56:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 20:56:14 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v7]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <ESLMy4UzwWOx8tkvnNA8fDFrhoXnSnLLUi2zJqm227E=.32b94caf-a7fb-4c1c-865c-4639cc454838@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: "or or" -> "or"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/7281b482..8bcf4674

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From bpb at openjdk.org  Fri Jun 23 20:56:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 20:56:16 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v6]
In-Reply-To: <pgFVKhT1KCIEDjBCtVDlGS_iK_a1JjGkyLOtJJJPuJw=.da1b4aef-626c-4007-8c0d-c9c32672889a@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <ldMsh77B4tz619iaYvUrmmftTCdCSrumt5oWPK-GeP0=.af6372b9-5ad9-4736-b3a8-eea576fd1e65@github.com>
 <3DX4IBEr8sb827WoGKZElT7bg7t1n7sToPe-K6IFsn8=.25829915-bf02-4e3f-b9c5-65621d9d9ff9@github.com>
 <pgFVKhT1KCIEDjBCtVDlGS_iK_a1JjGkyLOtJJJPuJw=.da1b4aef-626c-4007-8c0d-c9c32672889a@github.com>
Message-ID: <cL4mT57P8GqxEaXmnnS3O1PU1niv9woYE_cuKdSM-7Y=.dace1068-5244-4d2f-a95d-65379a79b465@github.com>

On Fri, 23 Jun 2023 20:46:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 194:
>> 
>>> 192:      * rewinding of the buffer is performed.  If the specified character
>>> 193:      * buffer has no space {@linkplain java.nio.Buffer#hasRemaining
>>> 194:      * remaining} or or its {@linkplain java.nio.CharBuffer#length length}
>> 
>> typo: "or or" -> "or"
>
> Bummer. Thanks.

Fixed by 8bcf4674c24f72401ab80564541d724336a60d79.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14616#discussion_r1240379682

From rriggs at openjdk.org  Fri Jun 23 21:01:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 23 Jun 2023 21:01:06 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v7]
In-Reply-To: <ESLMy4UzwWOx8tkvnNA8fDFrhoXnSnLLUi2zJqm227E=.32b94caf-a7fb-4c1c-865c-4639cc454838@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <ESLMy4UzwWOx8tkvnNA8fDFrhoXnSnLLUi2zJqm227E=.32b94caf-a7fb-4c1c-865c-4639cc454838@github.com>
Message-ID: <JNS4waoAmec9apYIDo5WHbDWpBB0eembq3JuNn5apb8=.930d9112-1a7c-4361-8a5d-26d472adb665@github.com>

On Fri, 23 Jun 2023 20:56:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8222329: "or or" -> "or"

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1496016282

From jlu at openjdk.org  Fri Jun 23 21:37:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 Jun 2023 21:37:17 GMT
Subject: Integrated: 8310234: Refactor Locale tests to use JUnit
In-Reply-To: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
References: <OEYYU_wd75YNZoDXpaNpXwHrVElmazXVufTR_dWboRg=.45ae9442-af89-4453-a86f-598411503c19@github.com>
Message-ID: <EfFl9PdT_ELvd2ULCsyCADkIe7rHTX_AQeUstd820dI=.573fae3a-dbff-4e78-bacb-b0b770ef289a@github.com>

On Thu, 22 Jun 2023 01:08:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR as apart of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843) which refactors some tests in Locale to use JUnit. Other cleanup and small changes are included as well. More refactoring in Locale tests will be done in separate PRs.
> 
> If the test had a bugNNNNN.java name, it was also renamed to something more [descriptive](https://openjdk.org/jtreg/faq.html#how-should-i-name-a-test).
> 
> Below is a list of all the changes,
> 
> - Refactor Bug4316602.java as LocaleConstructors.java
> - Refactor Bug4210525.java as CaseCheckVariant.java
> - Refactor bug6277243.java as RootLocale.java
> - Refactor bug6312358.java as GetInstanceCheck.java
> - Refactor Bug8154797.java as CompareProviderFormats.java
> - Refactor Bug8004240.java as GetAdapterPreference.java
> - Refactor bug4122700.java into AvailableLocalesTest.java (and combined with StreamAvailableLocales.java)

This pull request has now been integrated.

Changeset: dad7bd9e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dad7bd9efc7ca2c245f7e35267479670f93a53a8
Stats:     1112 lines in 15 files changed: 605 ins; 507 del; 0 mod

8310234: Refactor Locale tests to use JUnit

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14609

From darcy at openjdk.org  Fri Jun 23 22:00:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 22:00:15 GMT
Subject: RFR: JDK-8310571: Use inline @return tag on java.util.Objects [v2]
In-Reply-To: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
References: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
Message-ID: <i3SopET_HJe-BeWrXoVVyXFiX_HjBiO8OTUrgsa3lTw=.5f5ac796-91e2-4eb6-9d50-f4d2047d5ce5@github.com>

> Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

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 four additional commits since the last revision:

 - Respond to review feedback.
 - Merge branch 'master' into JDK-8310571
 - Merge branch 'master' into JDK-8310571
 - JDK-8310571: Use inline @return tag on java.util.Objects

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14608/files
  - new: https://git.openjdk.org/jdk/pull/14608/files/026b3caf..d97eb7ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14608&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14608&range=00-01

  Stats: 1039 lines in 88 files changed: 319 ins; 408 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/14608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14608/head:pull/14608

PR: https://git.openjdk.org/jdk/pull/14608

From prappo at openjdk.org  Fri Jun 23 22:05:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 22:05:14 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

src/java.base/share/classes/sun/util/resources/Bundles.java line 510:

> 508:                     return false;
> 509:                 }
> 510:                 return Objects.equals(locale, otherEntry.locale)

While the proposal is not wrong, you might want to consider reverting the change to those two lines: 511 and 512. The reason being is that neither `locale` nor `name` can be null, if I understand this class correctly. 

NPE was seemingly caught to cover for `other` being null.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240442051

From prappo at openjdk.org  Fri Jun 23 22:05:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 23 Jun 2023 22:05:15 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>
Message-ID: <OszskTdC-PTWw0zp9-wl6gzTQuPYaG1sYlO2AWQFKew=.70b5ea1c-312b-4289-b98d-e4dcba7769c6@github.com>

On Fri, 23 Jun 2023 21:59:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> NPE was seemingly caught to cover for other being null.

Unlike that of other file in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1240446275

From darcy at openjdk.org  Fri Jun 23 22:56:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 22:56:02 GMT
Subject: RFR: JDK-8310571: Use inline @return tag on java.util.Objects [v3]
In-Reply-To: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
References: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
Message-ID: <KdOGTBndx8IxIs7triJ2FaFFf5cdxEJzwR28NSaNYIU=.8e52199d-2a58-497c-9e58-599bf9f69458@github.com>

> Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Make sure there is not an unwanted word break around "non-null".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14608/files
  - new: https://git.openjdk.org/jdk/pull/14608/files/d97eb7ab..7fae1b74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14608&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14608&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14608.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14608/head:pull/14608

PR: https://git.openjdk.org/jdk/pull/14608

From darcy at openjdk.org  Fri Jun 23 22:58:24 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 23 Jun 2023 22:58:24 GMT
Subject: Integrated: JDK-8310571: Use inline @return tag on java.util.Objects
In-Reply-To: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
References: <cyVNe2-aVn8rMsQzyEuM_his2YyQdO8079qw1NVgOW4=.a6e29472-6125-4931-962b-85f96f5eb1ec@github.com>
Message-ID: <AQu4mRmExPKOEQwrwLENk37rsAoWrRetJ0CeCAWL9vA=.1f7a9f9f-cdac-4eca-9e56-c981639dd5d8@github.com>

On Thu, 22 Jun 2023 00:19:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Small cleanup, minor differences in the wording of portions of toString(Object, String), nonNull(Object), requireNonNullElse, and requireNonNullElseGet.

This pull request has now been integrated.

Changeset: 0db63ec7
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0db63ec76d451295e273c8e3272d013e2c3348ef
Stats:     47 lines in 1 file changed: 2 ins; 22 del; 23 mod

8310571: Use inline @return tag on java.util.Objects

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/14608

From bpb at openjdk.org  Fri Jun 23 23:23:07 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Jun 2023 23:23:07 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v8]
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com>

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8222329: Disambiguate length/remaining in Reader and Readable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14616/files
  - new: https://git.openjdk.org/jdk/pull/14616/files/8bcf4674..12f982b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14616&range=06-07

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14616/head:pull/14616

PR: https://git.openjdk.org/jdk/pull/14616

From duke at openjdk.org  Fri Jun 23 23:28:22 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 23 Jun 2023 23:28:22 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v21]
In-Reply-To: <JE6bJgXjC2W4yC8JMdnIQvKYe-dKBd4eCczD-xx0E10=.74bf8d97-11bb-4687-b717-a6e8343714d5@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>
 <JE6bJgXjC2W4yC8JMdnIQvKYe-dKBd4eCczD-xx0E10=.74bf8d97-11bb-4687-b717-a6e8343714d5@github.com>
Message-ID: <vUeqs1Rav2XFPli7OnjUPY0bGVrppftRW4Gu8g3pXhA=.fbdc5e4d-db68-43ed-9270-f364a101b9ba@github.com>

On Fri, 23 Jun 2023 19:30:31 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   format code
>
> src/java.base/share/classes/java/lang/Long.java line 493:
> 
>> 491:                         | H256[((int) lsb) & 0xff]);
>> 492: 
>> 493:         return new String(buf, LATIN1);
> 
> Note?that this?isn?t?correct when?`COMPACT_STRINGS` is?`false`, as?then?`buf` is?always?interpreted as?having a?`coder`?of?`UTF16`.

where COMPACT_STRINGS is false,  jdk.internal.access.JavaLangAccess#fastUUID will use fastUUIDUTF16


 public String fastUUID(long lsb, long msb) {
         return String.COMPACT_STRINGS ? Long.fastUUID(lsb, msb) : Long.fastUUIDUTF16(lsb, msb);
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1240501371

From jvernee at openjdk.org  Fri Jun 23 23:58:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 23 Jun 2023 23:58:05 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v3]
In-Reply-To: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
Message-ID: <k-myLLKzDkkNIirmZzuOzQdOOxCZUcev8uEaThYE1iE=.bb39fb46-47aa-4e55-afe7-0ce402eefba6@github.com>

> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.

Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:

 - review comments
 - Update src/java.base/share/classes/java/lang/foreign/Linker.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Phrasing
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14565/files
  - new: https://git.openjdk.org/jdk/pull/14565/files/f6a111b9..41c678a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14565&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14565&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14565/head:pull/14565

PR: https://git.openjdk.org/jdk/pull/14565

From lancea at openjdk.org  Sat Jun 24 00:55:11 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 24 Jun 2023 00:55:11 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v8]
In-Reply-To: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com>
Message-ID: <c3L_0KcBvbckbiE-aXF-wdX4-XXbJmUJLRffIog5Gzg=.39b62d10-618e-439f-91ac-5942055be797@github.com>

On Fri, 23 Jun 2023 23:23:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8222329: Disambiguate length/remaining in Reader and Readable

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1496255190

From liach at openjdk.org  Sat Jun 24 01:15:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Jun 2023 01:15:35 GMT
Subject: RFR: 8310838: Correct range notations in MethodTypeDesc specification
Message-ID: <EZOORJXKd32cXdad38BN6oW5LD9sG3HeJaXHQ1VedQA=.b9e27ab0-754c-4dc4-9d4e-f0d9951472b7@github.com>

https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/MethodTypeDesc.html

These 3 typos are discovered while browsing the online documentation. It probably doesn't need a CSR for it doesn't change the specification at all.

-------------

Commit messages:
 - 8310838: Correct range notations in MethodTypeDesc specification

Changes: https://git.openjdk.org/jdk/pull/14635/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14635&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310838
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14635.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14635/head:pull/14635

PR: https://git.openjdk.org/jdk/pull/14635

From jvernee at openjdk.org  Sat Jun 24 01:18:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Sat, 24 Jun 2023 01:18:22 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v3]
In-Reply-To: <k-myLLKzDkkNIirmZzuOzQdOOxCZUcev8uEaThYE1iE=.bb39fb46-47aa-4e55-afe7-0ce402eefba6@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <k-myLLKzDkkNIirmZzuOzQdOOxCZUcev8uEaThYE1iE=.bb39fb46-47aa-4e55-afe7-0ce402eefba6@github.com>
Message-ID: <y2-CEcdRBBJQSCcHPPmCvEiGQ6YAKgbvCIBsV7aPP2Y=.ccc55cda-3002-4fa7-b9f9-326d15527382@github.com>

On Fri, 23 Jun 2023 23:58:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.
>
> Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - review comments
>  - Update src/java.base/share/classes/java/lang/foreign/Linker.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Phrasing
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

I've addressed the review comments. I think we're converging so also went ahead and created the CSR for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14565#issuecomment-1605211291

From jwaters at openjdk.org  Sat Jun 24 01:29:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Jun 2023 01:29:26 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v13]
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Leave nullptr for another day
 - src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
   
   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14125/files
  - new: https://git.openjdk.org/jdk/pull/14125/files/d5f74cc2..3fe2a894

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=11-12

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From jwaters at openjdk.org  Sat Jun 24 01:29:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 24 Jun 2023 01:29:26 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v12]
In-Reply-To: <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <alKflVc2cFi7lm9_Xiphx-W9xCFfAEU10Gs_MaFISkY=.a2860b09-d158-40f8-969c-8793004c4e31@github.com>
Message-ID: <U58XcxapZN50QfMSc4fGBWYmUg4jC1txpgiB8E1K9TY=.0cd5d06e-dcd4-4291-b819-ea64f4ae5a48@github.com>

On Fri, 23 Jun 2023 17:09:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Swap to jint in awt_MenuBar.h
>  - Swap to jint in awt_MenuBar.cpp
>  - Swap to jint in awt_Menu.h

Alright, done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1605222563

From duke at openjdk.org  Sat Jun 24 02:37:06 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 02:37:06 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
Message-ID: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>

Using `ByteArrayLittleEndian` is simpler and faster.

`make test TEST="micro:java.util.zip.ZipFileOpen"`:


  Benchmark                     (size)  Mode  Cnt      Score      Error  Units
- ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
+ ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
- ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
+ ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

-------------

Commit messages:
 - use ByteArrayLittleEndian in ZipUtils

Changes: https://git.openjdk.org/jdk/pull/14632/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310837
  Stats: 43 lines in 2 files changed: 35 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14632/head:pull/14632

PR: https://git.openjdk.org/jdk/pull/14632

From liach at openjdk.org  Sat Jun 24 02:37:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Jun 2023 02:37:07 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <_dTUgN3ANeQV2lJWXOFjIKzzlMzcvY3o7ht9IbeSNFY=.f98924b6-d6b3-4c30-8190-0b8eb319c844@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

Looks great. Created https://bugs.openjdk.org/browse/JDK-8310837 for your patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1605200217

From alanb at openjdk.org  Sat Jun 24 05:21:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Jun 2023 05:21:04 GMT
Subject: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is
 returned when there is no remaining space in buffer [v8]
In-Reply-To: <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
 <9zcG8qlnoueAaovh9GHXuR7hmauDCN6mGW0CfXZcnHQ=.73d44ff2-a5b9-4949-aa00-2b9c9fe9ccc7@github.com>
Message-ID: <NnY_9xcH9LzmUbjdKtI7nkPKQG2Ki8UPFiuw_oGhVlE=.5c3d1470-2d39-487a-97ba-d651775c9846@github.com>

On Fri, 23 Jun 2023 23:23:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8222329: Disambiguate length/remaining in Reader and Readable

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14616#pullrequestreview-1496353176

From alanb at openjdk.org  Sat Jun 24 05:28:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Jun 2023 05:28:04 GMT
Subject: RFR: 8310682: No package-info (and @since) for package
 jdk.nio.mapmode
In-Reply-To: <E5ex0jxUOFEh37YeVi_ZzJG4WUGzp61JgdXDncGpdoQ=.1f29c122-2de6-4195-9712-835a15ccec53@github.com>
References: <E5ex0jxUOFEh37YeVi_ZzJG4WUGzp61JgdXDncGpdoQ=.1f29c122-2de6-4195-9712-835a15ccec53@github.com>
Message-ID: <Jcxd7pJU_J2AbsiDF0WzX6HJpgq5CIgBtcUC08S1dOg=.94e83e7b-0b2c-4cae-93d0-0f85abf24870@github.com>

On Fri, 23 Jun 2023 16:30:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `package-info.java` for package `jdk.nio.mapmode`.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14628#pullrequestreview-1496355363

From jpai at openjdk.org  Sat Jun 24 05:28:05 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 24 Jun 2023 05:28:05 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <KUBPOaIWrghhjzjHLlDz4GXYUEB0iznu0JYeQUks4_E=.d468e8b3-2c2c-4dc0-8cec-480bacac48f4@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

src/java.base/share/classes/jdk/internal/util/ByteArrayLittleEndian.java line 150:

> 148:     public static long getUnsignedInt(byte[] array, int offset) {
> 149:         return Integer.toUnsignedLong((int) INT.get(array, offset));
> 150:     }

Hello Glavo, I was going to recommend adding a test method to existing jtreg tests to test these new methods. But it looks like there's no jtreg test for this `ByteArrayLittleEndian` class. Would you mind creating a new test class to (at least) test these methods?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14632#discussion_r1240603525

From alanb at openjdk.org  Sat Jun 24 05:28:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 24 Jun 2023 05:28:03 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <hW64GHoQqTkXbelxusrWX_Wa9cDDdrinhiG_nLDfIFk=.8f00eb67-a157-401d-bdbf-8f1a9fe23232@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

@LanceAndersen This one is going to require checking that startup isn't impacted.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1605273238

From jpai at openjdk.org  Sat Jun 24 05:38:06 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 24 Jun 2023 05:38:06 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <mrqEv612h4rdQHsFqvWtsM0YNhuY7VztJTEfn6qflXE=.01b24acf-b677-4b8f-90ca-23580a97f537@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

On an existing Java runtime, I had a quick look at the classes loaded at application startup to see if `MethodHandles` already gets loaded before `ZipUtils` (and related jar/zip classes). From what I see in the output, `MethodHandles` indeed is already loaded before `ZipUtils`. So I think this change doesn't bring in any new/unexpected usage of `MethodHandles` that could potentially impact startup performance.

P.S: I just noticed Alan has a similar comment about startup performance, so yes, having some numbers for a startup benchmark would be useful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1605275101

From duke at openjdk.org  Sat Jun 24 06:05:02 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 06:05:02 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <hW64GHoQqTkXbelxusrWX_Wa9cDDdrinhiG_nLDfIFk=.8f00eb67-a157-401d-bdbf-8f1a9fe23232@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <hW64GHoQqTkXbelxusrWX_Wa9cDDdrinhiG_nLDfIFk=.8f00eb67-a157-401d-bdbf-8f1a9fe23232@github.com>
Message-ID: <H9U-8gGv6MEM_pwgc-_0nMOFhsrECDyThJsA7l6SP7E=.34a2fcd7-062a-44c5-b23f-180c8e3f5954@github.com>

On Sat, 24 Jun 2023 05:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Using `ByteArrayLittleEndian` is simpler and faster.
>> 
>> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>> 
>> 
>>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
>> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
>> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
>> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
>> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op
>
> @LanceAndersen This one is going to require checking that startup isn't impacted.

@AlanBateman @jaikiran Sorry, I thought about its possible impact on startup time, but I don't know which tests can be used to test JVM startup time. Can you tell me some relevant tests?

In fact, I now have a branch(https://github.com/openjdk/jdk/commit/30289cc48c36bd7a59d6c707118d74383bf5f378) that rewrites `ByteArray` and `ByteArrayLittleEndian` to avoid using `VarHandle` because I hope to be able to use them more inside the JDK later.

I tested its performance with the `-Xint` option on and it is indeed faster than `VarHandle` in interpreter mode. But I think I'm missing some benchmark results of the impact on startup time to justify its necessity.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1605281589

From duke at openjdk.org  Sat Jun 24 06:15:02 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 06:15:02 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <KUBPOaIWrghhjzjHLlDz4GXYUEB0iznu0JYeQUks4_E=.d468e8b3-2c2c-4dc0-8cec-480bacac48f4@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <KUBPOaIWrghhjzjHLlDz4GXYUEB0iznu0JYeQUks4_E=.d468e8b3-2c2c-4dc0-8cec-480bacac48f4@github.com>
Message-ID: <4j2dlVPDcoa5fQhosYIjzV5b1yA-h3Ld8w45taAiRaQ=.c6ead2a9-3c40-4cb5-af3f-b96b0d8738cd@github.com>

On Sat, 24 Jun 2023 05:24:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Glavo, I was going to recommend adding a test method to existing jtreg tests to test these new methods. But it looks like there's no jtreg test for this `ByteArrayLittleEndian` class. Would you mind creating a new test class to (at least) test these methods?

I think I could modify `test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java` to also test `ByteArrayLittleEndian`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14632#discussion_r1240616168

From vsitnikov at openjdk.org  Sat Jun 24 06:51:16 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 24 Jun 2023 06:51:16 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> 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 properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1605290913

From duke at openjdk.org  Sat Jun 24 09:16:15 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 09:16:15 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
Message-ID: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>

`ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.

Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.

This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

-------------

Commit messages:
 - use Preconditions.AIOOBE_FORMATTER
 - delete extraneous whitespace
 - delete extraneous whitespace
 - get/set unsigned int
 - Reimplement ByteArray and ByteArrayLittleEndian with Unsafe

Changes: https://git.openjdk.org/jdk/pull/14636/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310843
  Stats: 268 lines in 2 files changed: 135 ins; 64 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From liach at openjdk.org  Sat Jun 24 09:16:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Jun 2023 09:16:16 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <4a_HN7D6FVCe6AA-WTq21CdpwxVFkaJ7GV5T3VX3oME=.38c380bd-7bb8-4e61-8122-8940466c39f4@github.com>

On Sat, 24 Jun 2023 06:42:18 GMT, Glavo <duke at openjdk.org> wrote:

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Changes requested by liach (Author).

The reimplementation allows parts that invoke package depend on to utilize faster byte array access, namely bytecode generation and Classfile API; which IMO is more important than the reduction on startup time.

Created an issue at https://bugs.openjdk.org/browse/JDK-8310843.
I look forward to this improvement, for it can potentially be used by the Classfile API to speed up Classfile parsing and writing.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 47:

> 45: 
> 46:     private static final BiFunction<String, List<Number>, ArrayIndexOutOfBoundsException>
> 47:             OOBEF = Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new);

Can't this be replaced by `Preconditions.AIOBBE_FORMATTER`? And this lambda expression prevents this class to be used before java.lang.invoke initialization.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14636#pullrequestreview-1496433457
PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1605319678
PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1605325374
PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1240649846

From duke at openjdk.org  Sat Jun 24 09:16:16 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 09:16:16 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <-UzL-pmv5w72JBv4rZ6VKXJNQCh0qFs-Yu8mpIWGJPc=.3044c807-ffec-46d3-b9b0-18f5b978ef2c@github.com>

On Sat, 24 Jun 2023 06:42:18 GMT, Glavo <duke at openjdk.org> wrote:

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

I removed `getFloatRaw`/`getDoubleRaw` because they are exactly the same as `getFloat`/`getDouble`, so they have no meaning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1605293964

From liach at openjdk.org  Sat Jun 24 09:23:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 24 Jun 2023 09:23:04 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <Lqz9O96J6nPjcuzL7Qhsclx9RvwYw2Rz_7L5OmdrgtE=.8a8a1c09-a632-4eb1-8087-cfdc4dcbeeb3@github.com>

On Sat, 24 Jun 2023 06:42:18 GMT, Glavo <duke at openjdk.org> wrote:

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

I recommend documenting that this class is intended to be usable at early startup so we don't accidentally introduce features like lambda into the code.

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 35:

> 33:  * using {@linkplain java.nio.ByteOrder#BIG_ENDIAN big endian order} (aka. "network order").
> 34:  * <p>
> 35:  * All methods in this class will throw an {@linkplain NullPointerException} if {@code null} is

Do the Unsafe methods throw NPE on null array argument?

src/java.base/share/classes/jdk/internal/util/ByteArray.java line 43:

> 41:     }
> 42: 
> 43:     static final Unsafe UNSAFE = Unsafe.getUnsafe();

I recommend documenting the reason to use Unsafe (early startup) and comment that regular users should use VarHandle instead.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14636#pullrequestreview-1496438253
PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1240653787
PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1240653425

From duke at openjdk.org  Sat Jun 24 09:35:04 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 09:35:04 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v2]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <D81UQ18dVmwXBlwXBwf0PqRAjSEOnCGh0Qoku1Hm1LE=.96bb5c33-8761-48f7-a326-0524653bdfd0@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/6b14fa7e..8a507b9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=00-01

  Stats: 400 lines in 1 file changed: 305 ins; 19 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From duke at openjdk.org  Sat Jun 24 10:13:06 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 10:13:06 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v3]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <MNC5x1RkihPhRyAchUvY96igwVDYuMTtuq4CKUsZNeU=.dbfb638c-9227-4189-a6b5-34686797df8f@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  fix test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/8a507b9a..20b7c875

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From duke at openjdk.org  Sat Jun 24 10:14:02 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 10:14:02 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v3]
In-Reply-To: <Lqz9O96J6nPjcuzL7Qhsclx9RvwYw2Rz_7L5OmdrgtE=.8a8a1c09-a632-4eb1-8087-cfdc4dcbeeb3@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <Lqz9O96J6nPjcuzL7Qhsclx9RvwYw2Rz_7L5OmdrgtE=.8a8a1c09-a632-4eb1-8087-cfdc4dcbeeb3@github.com>
Message-ID: <5wsau0PCUQJKho_Im0Q73l_f8k5GIWFAPD3XfbTXVc0=.d620db69-3e08-4c46-b2d0-ec93b8859dd4@github.com>

On Sat, 24 Jun 2023 09:16:38 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do the Unsafe methods throw NPE on null array argument?

No, but `arrayOffset` will throw.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1240681104

From prappo at openjdk.org  Sat Jun 24 10:50:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 24 Jun 2023 10:50:13 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
Message-ID: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>

Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.

This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

-------------

Commit messages:
 - Improve
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14630/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310813
  Stats: 30 lines in 1 file changed: 3 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

PR: https://git.openjdk.org/jdk/pull/14630

From prappo at openjdk.org  Sat Jun 24 10:50:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 24 Jun 2023 10:50:14 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <CTeP2jgEpSpMXkF-Y0vcvWr2h6beeT62QaaBNOEJlIE=.7e61d022-5535-4afa-919c-967c85c42ea8@github.com>

On Fri, 23 Jun 2023 17:27:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

Note, that along with further improvements to `equals`, commit a9cbbe5, boldly suggests dropping `&` in `hashCode` to fold its implementation into a single call to a utility method.

Now, I'm not an expert, but the `test/jdk/java/math` tests pass. To my (non-expert) opinion, `&` was also dulling down `hashCode`; but I'm eager to hear comments from those who understand that more than I do.

Perhaps this PR needs to be accompanied by benchmarks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1605381393

From duke at openjdk.org  Sat Jun 24 11:04:08 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 11:04:08 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v4]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <J6z2p6_nX3oqSJe-eaL_T2BNoJeXQl1NTJDeutkOz6k=.2a9723a2-66bb-4565-a6fe-53c48dd484fe@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  delete extraneous whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/20b7c875..8c3a2087

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From duke at openjdk.org  Sat Jun 24 11:39:02 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 11:39:02 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <4j2dlVPDcoa5fQhosYIjzV5b1yA-h3Ld8w45taAiRaQ=.c6ead2a9-3c40-4cb5-af3f-b96b0d8738cd@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <KUBPOaIWrghhjzjHLlDz4GXYUEB0iznu0JYeQUks4_E=.d468e8b3-2c2c-4dc0-8cec-480bacac48f4@github.com>
 <4j2dlVPDcoa5fQhosYIjzV5b1yA-h3Ld8w45taAiRaQ=.c6ead2a9-3c40-4cb5-af3f-b96b0d8738cd@github.com>
Message-ID: <PF0aGmcR2SnpsRRVKRrk_pnn5eRqT6JMgz33FdWNxis=.2124a54b-b9ee-4641-9a1a-9aba461ffd6f@github.com>

On Sat, 24 Jun 2023 06:11:55 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ByteArrayLittleEndian.java line 150:
>> 
>>> 148:     public static long getUnsignedInt(byte[] array, int offset) {
>>> 149:         return Integer.toUnsignedLong((int) INT.get(array, offset));
>>> 150:     }
>> 
>> Hello Glavo, I was going to recommend adding a test method to existing jtreg tests to test these new methods. But it looks like there's no jtreg test for this `ByteArrayLittleEndian` class. Would you mind creating a new test class to (at least) test these methods?
>
>> Hello Glavo, I was going to recommend adding a test method to existing jtreg tests to test these new methods. But it looks like there's no jtreg test for this `ByteArrayLittleEndian` class. Would you mind creating a new test class to (at least) test these methods?
> 
> I think I could modify `test/jdk/jdk/internal/util/ByteArray/ReadWriteValues.java` to also test `ByteArrayLittleEndian`.

I added a test for `ByteArrayLittleEndian` in #14636

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14632#discussion_r1240723205

From duke at openjdk.org  Sat Jun 24 12:02:08 2023
From: duke at openjdk.org (Glavo)
Date: Sat, 24 Jun 2023 12:02:08 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v5]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <jnOMcI_8Ry6qqO3Vs6V14L3rUGXQp6C9m2QRsXa8738=.2cd1b324-2a33-4012-8002-ba27ab4addf9@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request incrementally with two additional commits since the last revision:

 - delete extraneous whitespace
 - add javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/8c3a2087..4ac26325

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=03-04

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From duke at openjdk.org  Sat Jun 24 23:39:05 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 24 Jun 2023 23:39:05 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v21]
In-Reply-To: <vUeqs1Rav2XFPli7OnjUPY0bGVrppftRW4Gu8g3pXhA=.fbdc5e4d-db68-43ed-9270-f364a101b9ba@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>
 <JE6bJgXjC2W4yC8JMdnIQvKYe-dKBd4eCczD-xx0E10=.74bf8d97-11bb-4687-b717-a6e8343714d5@github.com>
 <vUeqs1Rav2XFPli7OnjUPY0bGVrppftRW4Gu8g3pXhA=.fbdc5e4d-db68-43ed-9270-f364a101b9ba@github.com>
Message-ID: <ch6I1lUTCybgQsM8byMM3JB0h-rgD4hUvH2QDxHLxpg=.f635eaa9-d453-4af8-9648-c895482f1213@github.com>

On Fri, 23 Jun 2023 23:25:25 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Long.java line 493:
>> 
>>> 491:                         | H256[((int) lsb) & 0xff]);
>>> 492: 
>>> 493:         return new String(buf, LATIN1);
>> 
>> Note?that this?isn?t?correct when?`COMPACT_STRINGS` is?`false`, as?then?`buf` is?always?interpreted as?having a?`coder`?of?`UTF16`.
>
> where COMPACT_STRINGS is false,  jdk.internal.access.JavaLangAccess#fastUUID using fastUUIDUTF16
> 
> 
>  public String fastUUID(long lsb, long msb) {
>          return String.COMPACT_STRINGS ? Long.fastUUID(lsb, msb) : Long.fastUUIDUTF16(lsb, msb);
> }

There?should?probably be?a?check or?something at?the?top of?this?method that?`COMPACT_STRINGS` is?`true`?then, e.g.:

if (!COMPACT_STRINGS) {
	throw new InternalError("...");
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1240970991

From liach at openjdk.org  Sun Jun 25 03:08:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 03:08:10 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields
Message-ID: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>

This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

-------------

Commit messages:
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

Changes: https://git.openjdk.org/jdk/pull/14640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310848
  Stats: 242 lines in 6 files changed: 62 ins; 93 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

PR: https://git.openjdk.org/jdk/pull/14640

From liach at openjdk.org  Sun Jun 25 04:20:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 04:20:14 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v2]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <KqRmmONiSSKwyn6k6hB5ufOArHj7kuoDOpRZacrCeZw=.4c410db9-6518-4675-bf23-69bbc0f22578@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14640/files
  - new: https://git.openjdk.org/jdk/pull/14640/files/3194e6b7..82442aac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

PR: https://git.openjdk.org/jdk/pull/14640

From liach at openjdk.org  Sun Jun 25 04:36:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 04:36:29 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v21]
In-Reply-To: <tljEeFn3OP_CPwsaV8VwNnlcPJszv4wn0BNMt79TFNA=.305b3b2d-11cc-4fec-b224-6c202640a7a8@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <nwpjbkel_ktKqqbRTsaxNqTiu1u9xZNaK-9HiQGC3b4=.929c985d-e3aa-46c0-bb9c-ac0ef9470e47@github.com>
 <tljEeFn3OP_CPwsaV8VwNnlcPJszv4wn0BNMt79TFNA=.305b3b2d-11cc-4fec-b224-6c202640a7a8@github.com>
Message-ID: <-RWaMlgoehLJsFigEgnktx_G294VsF5qsC612ZRWlDI=.55f8566c-ed56-4a96-b07b-139399f21101@github.com>

On Wed, 21 Jun 2023 06:29:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ClassfileBenchmark::transformWithNewMaps changed to transformWithAddedNOP
>
> I think we've resolved controversy about global static CHR cache (by having no global static CHR cache ;) and turned all performance issues into minor improvements. A new `ClassfileBenchmark` has been added for more precise future continuous performance monitoring.
> 
> This PR is now waiting for review to unblock all follow-up conversion work.
> 
> Thank you,
> Adam

@asotona I've sent a patch to your fork for a few API problems spotted a while ago and reported on the mailing list. Feel free to review my patch when you are back to work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1605866429

From alanb at openjdk.org  Sun Jun 25 05:52:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Jun 2023 05:52:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
Message-ID: <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>

On Fri, 23 Jun 2023 04:52:16 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused import
>
> Latest benchmark results (commit id [0d34655](https://github.com/openjdk/jdk/pull/14578/commits/0d346558e00cfab899e435acd0eb83d39d5b7169) ):
> 
> * [aliyun_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) (+32.17% )
> cpu : intel xeon sapphire rapids (x64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
> +UUIDBench.toString   20000  thrpt   15  82.550 ? 0.704  ops/us
> 
> 
> * [aliyun_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) (+46.88%)
> cpu : amd epc genoa (x64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
> +UUIDBench.toString   20000  thrpt   15  96.461 ? 0.293  ops/us
> 
> 
> * [aliyun_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) (+57.97%)
> cpu : aliyun yitian 710 (aarch64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
> +UUIDBench.toString   20000  thrpt   15  50.864 ? 1.305  ops/us
> 
> 
> * aws_c5.xlarge (+49.42% )
> aws x64
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
> +UUIDBench.toString   20000  thrpt   15  68.741 ? 0.199  ops/us
> 
> 
> * MacBook Pro M1 Pro (+201.14%)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score    Error   Units
> -UUIDBench.toString   20000  thrpt   15   36.875 ? 0.902  ops/us
> +UUIDBench.toString   20000  thrpt   15  111.049 ? 0.783  ops/us
> 
> 
> * [Orange Pi 5 Plus](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html) (+64.97%)
> cpu : RK3588 (aarch64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  21.691 ? 0.204  ops/us
> +UUIDBench.toString   20000  thrpt   15  35.785 ? 0.447  ops/us

@wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1605883578

From duke at openjdk.org  Sun Jun 25 07:08:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 07:08:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
Message-ID: <KL0C8P0cNvp1ZexHRqMWPxXQNfmhcE0wRqUg18zzLNo=.18b1a24f-a431-4968-87a3-397584a7fda2@github.com>

On Fri, 23 Jun 2023 04:52:16 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused import
>
> Latest benchmark results (commit id [0d34655](https://github.com/openjdk/jdk/pull/14578/commits/0d346558e00cfab899e435acd0eb83d39d5b7169) ):
> 
> * [aliyun_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) (+32.17% )
> cpu : intel xeon sapphire rapids (x64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
> +UUIDBench.toString   20000  thrpt   15  82.550 ? 0.704  ops/us
> 
> 
> * [aliyun_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) (+46.88%)
> cpu : amd epc genoa (x64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
> +UUIDBench.toString   20000  thrpt   15  96.461 ? 0.293  ops/us
> 
> 
> * [aliyun_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) (+57.97%)
> cpu : aliyun yitian 710 (aarch64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
> +UUIDBench.toString   20000  thrpt   15  50.864 ? 1.305  ops/us
> 
> 
> * aws_c5.xlarge (+49.42% )
> aws x64
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
> +UUIDBench.toString   20000  thrpt   15  68.741 ? 0.199  ops/us
> 
> 
> * MacBook Pro M1 Pro (+201.14%)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score    Error   Units
> -UUIDBench.toString   20000  thrpt   15   36.875 ? 0.902  ops/us
> +UUIDBench.toString   20000  thrpt   15  111.049 ? 0.783  ops/us
> 
> 
> * [Orange Pi 5 Plus](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html) (+64.97%)
> cpu : RK3588 (aarch64)
> ``` diff
>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
> -UUIDBench.toString   20000  thrpt   15  21.691 ? 0.204  ops/us
> +UUIDBench.toString   20000  thrpt   15  35.785 ? 0.447  ops/us

> @wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?

@AlanBateman 
it's ready for review,. thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1605903338

From duke at openjdk.org  Sun Jun 25 07:26:07 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 07:26:07 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
Message-ID: <ZNxSykWz2cpd4rrAiAxWnQHGxet2wA5xHCgI8oNwhYI=.0fcb31fe-568f-4fe7-be44-bde176e4fd31@github.com>

On Sun, 25 Jun 2023 05:49:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Latest benchmark results (commit id [0d34655](https://github.com/openjdk/jdk/pull/14578/commits/0d346558e00cfab899e435acd0eb83d39d5b7169) ):
>> 
>> * [aliyun_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) (+32.17% )
>> cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
>> +UUIDBench.toString   20000  thrpt   15  82.550 ? 0.704  ops/us
>> 
>> 
>> * [aliyun_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) (+46.88%)
>> cpu : amd epc genoa (x64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
>> +UUIDBench.toString   20000  thrpt   15  96.461 ? 0.293  ops/us
>> 
>> 
>> * [aliyun_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) (+57.97%)
>> cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
>> +UUIDBench.toString   20000  thrpt   15  50.864 ? 1.305  ops/us
>> 
>> 
>> * aws_c5.xlarge (+49.42% )
>> aws x64
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
>> +UUIDBench.toString   20000  thrpt   15  68.741 ? 0.199  ops/us
>> 
>> 
>> * MacBook Pro M1 Pro (+201.14%)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score    Error   Units
>> -UUIDBench.toString   20000  thrpt   15   36.875 ? 0.902  ops/us
>> +UUIDBench.toString   20000  thrpt   15  111.049 ? 0.783  ops/us
>> 
>> 
>> * [Orange Pi 5 Plus](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html) (+64.97%)
>> cpu : RK3588 (aarch64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  21.691 ? 0.204  ops/us
>> +UUIDBench.toString   20000  thrpt   15  35.785 ? 0.447  ops/us
>
> @wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?

@AlanBateman so sorry, this is the first time i submit code to openjdk, i am not familiar with compiling and testing jdk, so i have modified it many times. i've noticed the problem and finally i'd a full benchmark. i am waiting for your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1605911618

From duke at openjdk.org  Sun Jun 25 08:30:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 08:30:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v21]
In-Reply-To: <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <fsqm0a7iheXUD2oQ3Q3JaiMCk-Gj8DC0H84XMrDo_oc=.7535bbbb-cd91-4e34-9c1f-c70ad8a2879b@github.com>
Message-ID: <ErDKYNM3vV1YdGUfF62ne2gWGnFHt-OCzud3Srgq6NQ=.d295630c-6b37-4499-998c-ea0a8674c598@github.com>

On Fri, 23 Jun 2023 11:24:23 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format code

i found a class with the same functionality called 'java.util.HexDigits', but is non-public. 

should i rename it to 'jdk.util.HexDigits' and make it public so that multiple locations can be shared it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1605930630

From liach at openjdk.org  Sun Jun 25 09:26:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 09:26:23 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType cleanup in
 j.l.invoke and j.l.reflect
Message-ID: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>

This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.

-------------

Commit messages:
 - 8310849: Pattern matching for instanceof and arrayType cleanup in j.l.invoke and j.l.reflect

Changes: https://git.openjdk.org/jdk/pull/14642/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310849
  Stats: 210 lines in 34 files changed: 0 ins; 19 del; 191 mod
  Patch: https://git.openjdk.org/jdk/pull/14642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14642/head:pull/14642

PR: https://git.openjdk.org/jdk/pull/14642

From duke at openjdk.org  Sun Jun 25 10:03:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 10:03:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
Message-ID: <Rt55R1p4G5Tm8JJ_ywkogkX3Rn4RFWMsHDNaJxQHDOM=.b3cb003a-8d2e-4aa4-86c7-e2c3582c0b5e@github.com>

On Sun, 25 Jun 2023 05:49:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Latest benchmark results (commit id [0d34655](https://github.com/openjdk/jdk/pull/14578/commits/0d346558e00cfab899e435acd0eb83d39d5b7169) ):
>> 
>> * [aliyun_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) (+32.17% )
>> cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
>> +UUIDBench.toString   20000  thrpt   15  82.550 ? 0.704  ops/us
>> 
>> 
>> * [aliyun_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) (+46.88%)
>> cpu : amd epc genoa (x64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
>> +UUIDBench.toString   20000  thrpt   15  96.461 ? 0.293  ops/us
>> 
>> 
>> * [aliyun_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) (+57.97%)
>> cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
>> +UUIDBench.toString   20000  thrpt   15  50.864 ? 1.305  ops/us
>> 
>> 
>> * aws_c5.xlarge (+49.42% )
>> aws x64
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
>> +UUIDBench.toString   20000  thrpt   15  68.741 ? 0.199  ops/us
>> 
>> 
>> * MacBook Pro M1 Pro (+201.14%)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score    Error   Units
>> -UUIDBench.toString   20000  thrpt   15   36.875 ? 0.902  ops/us
>> +UUIDBench.toString   20000  thrpt   15  111.049 ? 0.783  ops/us
>> 
>> 
>> * [Orange Pi 5 Plus](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html) (+64.97%)
>> cpu : RK3588 (aarch64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  21.691 ? 0.204  ops/us
>> +UUIDBench.toString   20000  thrpt   15  35.785 ? 0.447  ops/us
>
> @wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?

@AlanBateman 

i found an implementation with minor changes, but slower when COMPACT_STRINGS is false.

https://github.com/wenshao/jdk/commit/4a3da4b20fe0f7244c2c7bde3d9a0e2c8b91455a

do you suggest using a new implementation? if yes, i commit new changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1605999627

From liach at openjdk.org  Sun Jun 25 10:56:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 Jun 2023 10:56:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <Rt55R1p4G5Tm8JJ_ywkogkX3Rn4RFWMsHDNaJxQHDOM=.b3cb003a-8d2e-4aa4-86c7-e2c3582c0b5e@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
 <Rt55R1p4G5Tm8JJ_ywkogkX3Rn4RFWMsHDNaJxQHDOM=.b3cb003a-8d2e-4aa4-86c7-e2c3582c0b5e@github.com>
Message-ID: <WNRzyYra6fK-rby4t84zWWWTEN2Kzel6ejfuvrZAeVQ=.965a7369-2317-4d2c-a11b-18f63d82272a@github.com>

On Sun, 25 Jun 2023 10:00:23 GMT, ??? <duke at openjdk.org> wrote:

>> @wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?
>
> @AlanBateman 
> 
> i found an implementation with minor changes, but slower when COMPACT_STRINGS is false.
> 
> https://github.com/wenshao/jdk/commit/4a3da4b20fe0f7244c2c7bde3d9a0e2c8b91455a
> 
> do you suggest using a new implementation? if yes, i commit new changes.

@wenshao I don't think this is feasible, for this uses a new feature and hampers backport to jdk11. I suggest adding such a cache array in jdk.internal packages that digits class can use as well

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606024491

From duke at openjdk.org  Sun Jun 25 12:20:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 12:20:17 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  add jdk.util.HexDigits, sharing cache array across multiple classes, including :
  java.lang.Long#fastUUID
  java.util.HexDigits
  java.lang.Long#toHexString(future)
  java.lang.Integer#toHexString(future)
  java.util.HexFormat(future)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/f08444f4..17a9f169

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=20-21

  Stats: 125 lines in 4 files changed: 55 ins; 33 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Sun Jun 25 12:23:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 12:23:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
Message-ID: <ctNa5rx0cF9hkdIZpRENzIHVAMZVTTROJRnIUVqrnPA=.aaf02803-d2b4-4304-b934-395c37abb3af@github.com>

On Sun, 25 Jun 2023 05:49:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Latest benchmark results (commit id [0d34655](https://github.com/openjdk/jdk/pull/14578/commits/0d346558e00cfab899e435acd0eb83d39d5b7169) ):
>> 
>> * [aliyun_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i) (+32.17% )
>> cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  62.457 ? 0.226  ops/us
>> +UUIDBench.toString   20000  thrpt   15  82.550 ? 0.704  ops/us
>> 
>> 
>> * [aliyun_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a) (+46.88%)
>> cpu : amd epc genoa (x64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  65.673 ? 0.110  ops/us
>> +UUIDBench.toString   20000  thrpt   15  96.461 ? 0.293  ops/us
>> 
>> 
>> * [aliyun_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y) (+57.97%)
>> cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  32.198 ? 0.907  ops/us
>> +UUIDBench.toString   20000  thrpt   15  50.864 ? 1.305  ops/us
>> 
>> 
>> * aws_c5.xlarge (+49.42% )
>> aws x64
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  46.003 ? 0.291  ops/us
>> +UUIDBench.toString   20000  thrpt   15  68.741 ? 0.199  ops/us
>> 
>> 
>> * MacBook Pro M1 Pro (+201.14%)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score    Error   Units
>> -UUIDBench.toString   20000  thrpt   15   36.875 ? 0.902  ops/us
>> +UUIDBench.toString   20000  thrpt   15  111.049 ? 0.783  ops/us
>> 
>> 
>> * [Orange Pi 5 Plus](http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-plus.html) (+64.97%)
>> cpu : RK3588 (aarch64)
>> ``` diff
>>  Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> -UUIDBench.toString   20000  thrpt   15  21.691 ? 0.204  ops/us
>> +UUIDBench.toString   20000  thrpt   15  35.785 ? 0.447  ops/us
>
> @wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?

@AlanBateman i have modified according to liach's suggestion, it's ready for review also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606063419

From duke at openjdk.org  Sun Jun 25 13:53:19 2023
From: duke at openjdk.org (Sam Brannen)
Date: Sun, 25 Jun 2023 13:53:19 GMT
Subject: RFR: JDK-8310267: Javadoc for Class#isPrimitive() is incorrect
 regarding Class objects for primitives [v4]
In-Reply-To: <OLl-tLDgExtySNhmim7KZx1Wm1HfRYxQJGlsTwjKRH0=.f4abfcdb-1102-44e6-a355-be10f67c13e7@github.com>
References: <29nlPYmkmvI9zPlISHnpHKgvXXEN3pJupE9gsCQMg4M=.c6c97451-1ecd-4312-884f-fa5255181a1f@github.com>
 <OLl-tLDgExtySNhmim7KZx1Wm1HfRYxQJGlsTwjKRH0=.f4abfcdb-1102-44e6-a355-be10f67c13e7@github.com>
Message-ID: <Y9BeCqvOyJEG5nsqskUjXnHYrhNGYK4ST7L3k8Z6jes=.3406975c-9bfc-44bf-8513-02590eb26f91@github.com>

On Fri, 23 Jun 2023 19:41:17 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Correct misstatement that the Class object for a primitive type can only be be access via fields like java.lang.Integer.TYPE.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another typo and reflow paragraphs.

Thanks for improving the documentation, @jddarcy. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14574#issuecomment-1606100595

From javalists at cbfiddle.com  Sun Jun 25 15:21:54 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 25 Jun 2023 08:21:54 -0700
Subject: jpackage code signing identity
Message-ID: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>

I?m having trouble using the code signing feature of jpackage for macOS.

The problem appears to be here:

result = MacBaseInstallerBundler.findKey(
                            "Developer ID Application: ", user, keychain);
                    }

     boolean useAsIs = teamName.startsWith(keyPrefix)
                || teamName.startsWith("Developer ID")
                || teamName.startsWith("3rd Party Mac");

        String key = (useAsIs) ? teamName : (keyPrefix + teamName);



My certificate has a different prefix ?Apple Development: ? in the keychain.
I don?t think I made this up, so I don?t think I should try to change it.

Why is jpackage being so restrictive in its lookup of the signing key?
Why doesn?t it just pass the string to codesign, which has its own rules for interpreting signing identities (see below)?

I typically use the 10 character alphanumeric key that is part of the name when I use codesign directly.

The identity is first considered as the full name of a keychain identity preference. If such a preference exists, it directly names the identity used. Otherwise, the identity is located by searching all keychains for a certificate whose subject common name (only) contains the identity string given. If there are multiple matches, the operation fails and no signing is performed; however, an exact match is preferred over a partial match. These comparisons are case sensitive. Multiple instances of the exactly same certificate in multiple keychains are tolerated as harmless.
If identity consists of exactly forty hexadecimal digits, it is instead interpreted as the SHA-1 hash of the certificate part of the desired identity. In this case, the identity's subject name is not considered.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230625/fa37a9fd/attachment.htm>

From mik3hall at gmail.com  Sun Jun 25 15:34:18 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 25 Jun 2023 10:34:18 -0500
Subject: jpackage code signing identity
In-Reply-To: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>
References: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>
Message-ID: <873BD0A7-EE0A-4F2D-9617-885D1B9AE9B7@gmail.com>



> On Jun 25, 2023, at 10:21 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> I?m having trouble using the code signing feature of jpackage for macOS.
> 

FWIW, I have?

SIGNING_CERT_3RD_PARTY="3rd Party Mac Developer Application: Michael Hall (??????????)"
DEFAULT_SIGNING_CERT="Michael Hall"
DEVELOPER_ID_APPLICATION="Developer ID Application: Michael Hall (??????????)"
SIGNING_CERT=$DEVELOPER_ID_APPLICATION

	--mac-sign \
	--mac-signing-key-user-name "$SIGNING_CERT? \

I think these are public certs but obfuscated the last bit just to be safe.

You should be able to verify what you have with the keychain app.

Mike




From javalists at cbfiddle.com  Sun Jun 25 15:41:58 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 25 Jun 2023 08:41:58 -0700
Subject: jpackage code signing identity
In-Reply-To: <873BD0A7-EE0A-4F2D-9617-885D1B9AE9B7@gmail.com>
References: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>
 <873BD0A7-EE0A-4F2D-9617-885D1B9AE9B7@gmail.com>
Message-ID: <48DE6813-9D0D-42E8-A6CD-1955E6B2A81D@cbfiddle.com>

My certificate is different, as I stated. I don?t know why.



> On Jun 25, 2023, at 8:34 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jun 25, 2023, at 10:21 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> I?m having trouble using the code signing feature of jpackage for macOS.
>> 
> 
> FWIW, I have?
> 
> SIGNING_CERT_3RD_PARTY="3rd Party Mac Developer Application: Michael Hall (??????????)"
> DEFAULT_SIGNING_CERT="Michael Hall"
> DEVELOPER_ID_APPLICATION="Developer ID Application: Michael Hall (??????????)"
> SIGNING_CERT=$DEVELOPER_ID_APPLICATION
> 
> 	--mac-sign \
> 	--mac-signing-key-user-name "$SIGNING_CERT? \
> 
> I think these are public certs but obfuscated the last bit just to be safe.
> 
> You should be able to verify what you have with the keychain app.
> 
> Mike
> 
> 
> 


From jwaters at openjdk.org  Sun Jun 25 15:57:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 15:57:08 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
Message-ID: <zQsqobjLOQ-GppzX8gsbDxpKhuhWiF8Jp5iXMpgLuqU=.2b070d4d-c6ae-4e17-a3fd-93797540c381@github.com>

On Thu, 8 Jun 2023 11:20:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> I'll take a look? hopefully next week.

@aivanov-jdk Is the final change ok with you?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1606140949

From jwaters at openjdk.org  Sun Jun 25 16:01:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 16:01:26 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
Message-ID: <4byEsN8A77TyPs1uUYoCajUiOUy54KE1TRl_PeQG7MA=.3ead4dde-1553-4499-adc0-9a2ba6d53022@github.com>

On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'openjdk:master' into patch-6
>  - Whitespace
>  - Revert
>  - _MSC_VER
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert
>  - Semicolon
>  - gcc offset_of
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606141758

From mik3hall at gmail.com  Sun Jun 25 16:06:40 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 25 Jun 2023 11:06:40 -0500
Subject: jpackage code signing identity
In-Reply-To: <48DE6813-9D0D-42E8-A6CD-1955E6B2A81D@cbfiddle.com>
References: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>
 <873BD0A7-EE0A-4F2D-9617-885D1B9AE9B7@gmail.com>
 <48DE6813-9D0D-42E8-A6CD-1955E6B2A81D@cbfiddle.com>
Message-ID: <D2FCF71C-256D-4AF2-9C5D-E7E9F6D4156A@gmail.com>



> On Jun 25, 2023, at 10:41 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> My certificate is different, as I stated. I don?t know why.

Again, FWIW.

As shown Apple provides some different certificates for different purposes.

What I show works for me. 

If in the Keychain Access you have a certificate with a common name matching yours, and, that certificate is set with it?s info showing?

Extension   Subject Key Identifier (2.5.29.37)
Critical.       No
Purpose #1 Code Signing (1.3.6.1.5.5.7.3.3)

I would think it should work. If you don?t it might not.

Gl

Mike


From alanb at openjdk.org  Sun Jun 25 16:13:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Jun 2023 16:13:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <ctNa5rx0cF9hkdIZpRENzIHVAMZVTTROJRnIUVqrnPA=.aaf02803-d2b4-4304-b934-395c37abb3af@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
 <ctNa5rx0cF9hkdIZpRENzIHVAMZVTTROJRnIUVqrnPA=.aaf02803-d2b4-4304-b934-395c37abb3af@github.com>
Message-ID: <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>

On Sun, 25 Jun 2023 12:20:14 GMT, ??? <duke at openjdk.org> wrote:

>> @wenshao The patch has changed 19 times in the last 3 days, is it ready for review now?
>
> @AlanBateman i have modified according to liach's suggestion, it's ready for review also.

> @wenshao I don't think this is feasible, for this uses a new feature and hampers backport to jdk11.

I don't think backporting should be in the discussion here. The important thing is that we converge on agreement for a maintainable patch for the main line.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606145696

From duke at openjdk.org  Sun Jun 25 16:24:10 2023
From: duke at openjdk.org (ExE Boss)
Date: Sun, 25 Jun 2023 16:24:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
Message-ID: <oSiYM-a45zDJr1Kyv3CZPJxM66tbbS_2vfVsM0XU6AI=.a6ff7c98-0814-4546-b86f-418e760675ac@github.com>

On Sun, 25 Jun 2023 12:20:17 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jdk.util.HexDigits, sharing cache array across multiple classes, including :
>   java.lang.Long#fastUUID
>   java.util.HexDigits
>   java.lang.Long#toHexString(future)
>   java.lang.Integer#toHexString(future)
>   java.util.HexFormat(future)

src/java.base/share/classes/java/lang/Long.java line 451:

> 449:     }
> 450: 
> 451:     static String fastUUID(long lsb, long msb) {

This?method should?probably have?an?assert or?something that?`COMPACT_STRINGS` is?`true`, e.g.:
Suggestion:

    static String fastUUID(long lsb, long msb) {
        if (!COMPACT_STRINGS) {
            throw new InternalError("Long::fastUUID requires compact strings");
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241232478

From aivanov at openjdk.org  Sun Jun 25 16:27:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 25 Jun 2023 16:27:07 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v13]
In-Reply-To: <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
Message-ID: <ZT6k0naheyEW_RQ2JW0f9TjuSa_fZkE9_wpfRmOd4iE=.655efdb2-c60c-402f-9011-8fcfc6680b1b@github.com>

On Sat, 24 Jun 2023 01:29:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Leave nullptr for another day
>  - src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1497128460

From aivanov at openjdk.org  Sun Jun 25 16:27:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sun, 25 Jun 2023 16:27:10 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v4]
In-Reply-To: <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <3VAC9z-WjItzbkXeNreX7PGi18ypbaom-RjBJgHb9L4=.1e90295d-c012-47dd-b5fe-fa7889ce2c84@github.com>
 <LUJcge3wyT-mPJc7yyEBtuZjksoNf355ycA_0s10rF0=.5e9a6d07-ab49-44d9-9047-f934c90948ab@github.com>
Message-ID: <QbL4jd8c7y6nvdmPRyxZPbsTul6broWyq9OhFmI4W_M=.9a21d6f0-9aa0-414a-9a35-cd8e6feef1af@github.com>

On Thu, 8 Jun 2023 11:20:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the code that is actually warning
>
> I'll take a look? hopefully next week.

> @aivanov-jdk Is the final change ok with you?

Looks good now. Thanks!

I've run client tests, all is green.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1606149816

From mdoerr at openjdk.org  Sun Jun 25 16:37:11 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sun, 25 Jun 2023 16:37:11 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
Message-ID: <4bzCgX1KLhuApHrpGtMLeqBXyiywwiJVtz1m0e8RF10=.e714dcdf-98bb-4934-8ac8-27c407f0b4c4@github.com>

On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'openjdk:master' into patch-6
>  - Whitespace
>  - Revert
>  - _MSC_VER
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert
>  - Semicolon
>  - gcc offset_of
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13258#pullrequestreview-1497130480

From duke at openjdk.org  Sun Jun 25 16:51:06 2023
From: duke at openjdk.org (Glavo)
Date: Sun, 25 Jun 2023 16:51:06 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
 <ctNa5rx0cF9hkdIZpRENzIHVAMZVTTROJRnIUVqrnPA=.aaf02803-d2b4-4304-b934-395c37abb3af@github.com>
 <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>
Message-ID: <QysqH3_jD0wO1uQdGnmMmwIFeLySAEFI-4YeQatgwS8=.efbd43da-f04e-4c7f-bf28-90c4c7ec178f@github.com>

On Sun, 25 Jun 2023 16:09:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think this is feasible, for this uses a new feature and hampers backport to jdk11.

I don't think affecting backports in general should be a reason to discourage new features from being used.

https://github.com/wenshao/jdk/commit/4a3da4b20fe0f7244c2c7bde3d9a0e2c8b91455a is great for me.

Implementing some functions of UUID in `Long` is inherently illogical. Now that we can implement it efficiently in the `UUID` class, there's no reason why we shouldn't.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606154954

From duke at openjdk.org  Sun Jun 25 16:51:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 16:51:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <oSiYM-a45zDJr1Kyv3CZPJxM66tbbS_2vfVsM0XU6AI=.a6ff7c98-0814-4546-b86f-418e760675ac@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
 <oSiYM-a45zDJr1Kyv3CZPJxM66tbbS_2vfVsM0XU6AI=.a6ff7c98-0814-4546-b86f-418e760675ac@github.com>
Message-ID: <YWYxGDPn0qNvYqPdyrNDqJnAl5hDwisW8tmgTr7TTdk=.2eeed5c5-cb65-4506-aa00-b9eeab227d29@github.com>

On Sun, 25 Jun 2023 16:20:15 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add jdk.util.HexDigits, sharing cache array across multiple classes, including :
>>   java.lang.Long#fastUUID
>>   java.util.HexDigits
>>   java.lang.Long#toHexString(future)
>>   java.lang.Integer#toHexString(future)
>>   java.util.HexFormat(future)
>
> src/java.base/share/classes/java/lang/Long.java line 451:
> 
>> 449:     }
>> 450: 
>> 451:     static String fastUUID(long lsb, long msb) {
> 
> This?method should?probably have?an?assert or?something that?`COMPACT_STRINGS` is?`true`, e.g.:
> Suggestion:
> 
>     static String fastUUID(long lsb, long msb) {
>         if (!COMPACT_STRINGS) {
>             throw new InternalError("Long::fastUUID requires compact strings");
>         }

it's none-public method, only for UUID.toString

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241236769

From duke at openjdk.org  Sun Jun 25 16:56:08 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 16:56:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <YWYxGDPn0qNvYqPdyrNDqJnAl5hDwisW8tmgTr7TTdk=.2eeed5c5-cb65-4506-aa00-b9eeab227d29@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
 <oSiYM-a45zDJr1Kyv3CZPJxM66tbbS_2vfVsM0XU6AI=.a6ff7c98-0814-4546-b86f-418e760675ac@github.com>
 <YWYxGDPn0qNvYqPdyrNDqJnAl5hDwisW8tmgTr7TTdk=.2eeed5c5-cb65-4506-aa00-b9eeab227d29@github.com>
Message-ID: <hhFiyvClleu30SYb_UuDts8eviZjfmPUlnRkTga2SY0=.0d32e3c9-754d-4322-a2d1-6facaf895a06@github.com>

On Sun, 25 Jun 2023 16:48:06 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Long.java line 451:
>> 
>>> 449:     }
>>> 450: 
>>> 451:     static String fastUUID(long lsb, long msb) {
>> 
>> This?method should?probably have?an?assert or?something that?`COMPACT_STRINGS` is?`true`, e.g.:
>> Suggestion:
>> 
>>     static String fastUUID(long lsb, long msb) {
>>         if (!COMPACT_STRINGS) {
>>             throw new InternalError("Long::fastUUID requires compact strings");
>>         }
>
> it's none-public method, only for UUID.toString

now the fastUUID method codeSize is 325, which is equal to the maximum value of FreqInlineSize under aarch64 and x64. if additional assertion is added, the method codeSize > 325, cannot be inlined, resulting in performance degradation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241237407

From duke at openjdk.org  Sun Jun 25 17:07:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 17:07:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
Message-ID: <Jca9tllbCPx8EJG8Vy4dsC3VUJF6fOD44552IW289zk=.b50235b5-6fb7-4ca9-ae07-8ab2ee97ac93@github.com>

On Sun, 25 Jun 2023 12:20:17 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jdk.util.HexDigits, sharing cache array across multiple classes, including :
>   java.lang.Long#fastUUID
>   java.util.HexDigits
>   java.lang.Long#toHexString(future)
>   java.lang.Integer#toHexString(future)
>   java.util.HexFormat(future)

i agree that backport is not the goal, but in the two packages java.util and java.lang share a cache array, it is more appropriate to put it in jdk.util.

> 



> > I don't think this is feasible, for this uses a new feature and hampers backport to jdk11.
> 
> I don't think affecting backports in general should be a reason to discourage new features from being used.
> 
> [wenshao at 4a3da4b](https://github.com/wenshao/jdk/commit/4a3da4b20fe0f7244c2c7bde3d9a0e2c8b91455a) is great for me.
> 
> Implementing some functions of UUID in `Long` is inherently illogical. Now that we can implement it efficiently in the `UUID` class, there's no reason why we shouldn't.

this implementation is cleaner and is my favorite.

the implementation of changing JavaLangAccess and Long for UUID.toString in the baseline is too intrusive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606156842
PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606161285

From duke at openjdk.org  Sun Jun 25 17:22:09 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 17:22:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
Message-ID: <SFh0bIDiVmyDjxEsIjfrBYFyXcg1zunqYNlhovPWKZE=.ec92be93-856e-47d8-9a69-a9c8f5f69414@github.com>

On Sun, 25 Jun 2023 12:20:17 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add jdk.util.HexDigits, sharing cache array across multiple classes, including :
>   java.lang.Long#fastUUID
>   java.util.HexDigits
>   java.lang.Long#toHexString(future)
>   java.lang.Integer#toHexString(future)
>   java.util.HexFormat(future)

Should we consider that when COMPACT_STRINGS is false, should it only be guaranteed to work correctly, not the best performance. If based on this principle, the implementation code will be much simpler.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606171084

From duke at openjdk.org  Sun Jun 25 17:40:08 2023
From: duke at openjdk.org (Glavo)
Date: Sun, 25 Jun 2023 17:40:08 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <SFh0bIDiVmyDjxEsIjfrBYFyXcg1zunqYNlhovPWKZE=.ec92be93-856e-47d8-9a69-a9c8f5f69414@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
 <SFh0bIDiVmyDjxEsIjfrBYFyXcg1zunqYNlhovPWKZE=.ec92be93-856e-47d8-9a69-a9c8f5f69414@github.com>
Message-ID: <P8KFb7XfTR8WwyIaY6vQVs1nywiQMUa78C4e_3gGTMw=.cdcf26a0-f4c0-401e-bd23-06e9cba25659@github.com>

On Sun, 25 Jun 2023 17:19:22 GMT, ??? <duke at openjdk.org> wrote:

> Should we consider that when COMPACT_STRINGS is false, should it only be guaranteed to work correctly, not the best performance. If based on this principle, the implementation code will be much simpler.

I'm also curious about this question.

To be honest, I have never seen anyone actually use the `-XX:-CompactStrings`. Perhaps at some point in the future, we can investigate its usage and consider deprecate it to reduce the maintenance cost of JDK?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606179108

From stsypanov at openjdk.org  Sun Jun 25 18:17:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 25 Jun 2023 18:17:31 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v4]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request with a new target base 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:

 - 8301492: Revert
 - Merge branch 'master' into bundles
 - Restore logic
 - Fix logic
 - Copyright year update
 - Modernize Bubldes.equals()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/2b07e47e..e304cfe7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=02-03

  Stats: 1043296 lines in 10517 files changed: 730181 ins; 218415 del; 94700 mod
  Patch: https://git.openjdk.org/jdk/pull/12328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12328/head:pull/12328

PR: https://git.openjdk.org/jdk/pull/12328

From stsypanov at openjdk.org  Sun Jun 25 18:17:31 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 25 Jun 2023 18:17:31 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <OszskTdC-PTWw0zp9-wl6gzTQuPYaG1sYlO2AWQFKew=.70b5ea1c-312b-4289-b98d-e4dcba7769c6@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
 <vTFTcMG1igLICIfS79Xz7lvNVFd_cOtp6GW7IQxz0wk=.979a4c3f-dcc1-4292-af4c-dd5ece653b43@github.com>
 <OszskTdC-PTWw0zp9-wl6gzTQuPYaG1sYlO2AWQFKew=.70b5ea1c-312b-4289-b98d-e4dcba7769c6@github.com>
Message-ID: <3f2oJ0MGQmTpvMaZIoPO8l2ByJgWqj7SE3YexxWSKTU=.59883f2b-f13e-4732-9c7b-3a19aff36e67@github.com>

On Fri, 23 Jun 2023 22:02:22 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/resources/Bundles.java line 510:
>> 
>>> 508:                     return false;
>>> 509:                 }
>>> 510:                 return Objects.equals(locale, otherEntry.locale)
>> 
>> While the proposal is not wrong, you might want to consider reverting the change to those two lines: 511 and 512. The reason being is that neither `locale` nor `name` can be null, if I understand this class correctly. 
>> 
>> NPE was seemingly caught to cover for `other` being null.
>
>> NPE was seemingly caught to cover for other being null.
> 
> Unlike that of other file in this PR.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12328#discussion_r1241256825

From prappo at openjdk.org  Sun Jun 25 18:45:15 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 25 Jun 2023 18:45:15 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v4]
In-Reply-To: <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
Message-ID: <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>

On Sun, 25 Jun 2023 18:17:31 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request with a new target base 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:
> 
>  - 8301492: Revert
>  - Merge branch 'master' into bundles
>  - Restore logic
>  - Fix logic
>  - Copyright year update
>  - Modernize Bubldes.equals()

I'll re-run our CI, and if all good, I'll sponsor this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1606214132

From duke at openjdk.org  Sun Jun 25 20:25:28 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 20:25:28 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v23]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <XTGODr8v8dw2tEbkoqJMSt0Ba1IE1gsYL2BCfyED38o=.c808f9ae-1719-4afd-b5b8-5e27e3f3ddf4@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  move fastUUID implementation to UUID.toString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/17a9f169..efaa8692

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=21-22

  Stats: 168 lines in 4 files changed: 52 ins; 114 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Sun Jun 25 20:25:28 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 20:25:28 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
 <ctNa5rx0cF9hkdIZpRENzIHVAMZVTTROJRnIUVqrnPA=.aaf02803-d2b4-4304-b934-395c37abb3af@github.com>
 <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>
Message-ID: <IusQZDrWJKgJHiORrOB4WKi2hF_Mhvh344d4aNtWzws=.bbb106e4-040d-4e65-927d-4eb445970d4e@github.com>

On Sun, 25 Jun 2023 16:09:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman i have modified according to liach's suggestion, it's ready for review also.
>
>> @wenshao I don't think this is feasible, for this uses a new feature and hampers backport to jdk11.
> 
> I don't think backporting should be in the discussion here. The important thing is that we converge on agreement for a maintainable patch for the main line.

@AlanBateman i have modified according to @Glavo and @ExE-Boss 's suggestion, it's ready for review also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606250317

From aturbanov at openjdk.org  Sun Jun 25 20:25:28 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 25 Jun 2023 20:25:28 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v23]
In-Reply-To: <XTGODr8v8dw2tEbkoqJMSt0Ba1IE1gsYL2BCfyED38o=.c808f9ae-1719-4afd-b5b8-5e27e3f3ddf4@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <XTGODr8v8dw2tEbkoqJMSt0Ba1IE1gsYL2BCfyED38o=.c808f9ae-1719-4afd-b5b8-5e27e3f3ddf4@github.com>
Message-ID: <6erq9wUtnvsOt8acHbmyClPyMI82u-El4UXUBi5ztHc=.110d31cb-85c2-47f6-8732-7b975b290193@github.com>

On Sun, 25 Jun 2023 20:20:00 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move fastUUID implementation to UUID.toString

src/java.base/share/classes/java/util/UUID.java line 466:

> 464:     @Override
> 465:     public String toString() {
> 466:         return jla.fastUUID(leastSigBits, mostSigBits);

`JavaLangAccess.fastUUID` method now can be removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241280550

From duke at openjdk.org  Sun Jun 25 20:38:28 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 20:38:28 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v24]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <xyiTtfzIKEyfSaF803b_cY5DljYm-XOO0OPFVV5MQQg=.584d7009-3c43-4157-8085-d9832b6a98d3@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  remove JavaLangAccess#fastUUID

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/efaa8692..4b5019fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=22-23

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Sun Jun 25 20:38:49 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 20:38:49 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v24]
In-Reply-To: <6erq9wUtnvsOt8acHbmyClPyMI82u-El4UXUBi5ztHc=.110d31cb-85c2-47f6-8732-7b975b290193@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <XTGODr8v8dw2tEbkoqJMSt0Ba1IE1gsYL2BCfyED38o=.c808f9ae-1719-4afd-b5b8-5e27e3f3ddf4@github.com>
 <6erq9wUtnvsOt8acHbmyClPyMI82u-El4UXUBi5ztHc=.110d31cb-85c2-47f6-8732-7b975b290193@github.com>
Message-ID: <czLralBvRg_vUbRqcXAGxCI-g55KtRGJfhYkJ1XfbpY=.3c6b23b6-a861-42b3-beb1-7adf4ed8c2f8@github.com>

On Sun, 25 Jun 2023 20:19:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove JavaLangAccess#fastUUID
>
> src/java.base/share/classes/java/util/UUID.java line 466:
> 
>> 464:     @Override
>> 465:     public String toString() {
>> 466:         return jla.fastUUID(leastSigBits, mostSigBits);
> 
> `JavaLangAccess.fastUUID` method now can be removed

it fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241283098

From duke at openjdk.org  Sun Jun 25 20:41:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 25 Jun 2023 20:41:11 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v19]
In-Reply-To: <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <qpYHrGAvFgwD7VMENkfRsEXSfYNiC3I0Of3iUnz7TDY=.dc6df225-4701-40d2-a41b-4c71bf2aac6d@github.com>
 <cnXev_TV3fFvsDt-gIIY0k7RqWCrN4ic_83kn6ZJNqE=.8a0776e4-55e2-441b-b23c-31bc720779c8@github.com>
 <A6xum6T10XXdj6_zIvqpowLcQmohsHQAVfBZV5Jssno=.27baf814-e116-4a57-9567-bfd8a0225acf@github.com>
 <ctNa5rx0cF9hkdIZpRENzIHVAMZVTTROJRnIUVqrnPA=.aaf02803-d2b4-4304-b934-395c37abb3af@github.com>
 <uaylmChITlioNQyN4yPieb4LcuL_66ryn0XvYwgelzU=.b2e5b6ec-2617-47df-9a07-c48a779c9a48@github.com>
Message-ID: <NIjA_3U8iX_oBgszpKkpu51LCX9rL7ac59_HLB8aa1U=.01385777-1e97-4bf1-852b-907b6dbe7276@github.com>

On Sun, 25 Jun 2023 16:09:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman i have modified according to liach's suggestion, it's ready for review also.
>
>> @wenshao I don't think this is feasible, for this uses a new feature and hampers backport to jdk11.
> 
> I don't think backporting should be in the discussion here. The important thing is that we converge on agreement for a maintainable patch for the main line.

@AlanBateman i have modified according to @Glavo and @ExE-Boss 's suggestion, it's ready for review also.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1606255791

From prappo at openjdk.org  Sun Jun 25 22:35:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sun, 25 Jun 2023 22:35:07 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v4]
In-Reply-To: <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
 <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
Message-ID: <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>

On Sun, 25 Jun 2023 18:42:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I'll re-run our CI, and if all good, I'll sponsor this PR.

The CI tests I started have just passed. While this PR is already good, I wonder if we make it even better.

I doubt highly that we need null-checks for CacheKey's name and locale. My suspicion comes from these two facts:

* CacheKey's hashCode calls methods on these fields without checking them for null, and
* CacheKey instances are queried and stored in ConcurrentHashMap, which certainly uses both `equals` and `hashCode`

So, what I'm saying is that if those fields were null, there would be unhandled NPE somewhere; but I cannot see such NPE.  Additionally, those fields are used in toString(). Furthermore, locale is known to not be null because the only place from where it is passed to a CacheKey consturctor is ResourceBundle.getBundleImpl(Module, Module, String, Locale, ResourceBundle.Control), which explicitly checks that locale for not being null.

Does it make sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1606291015

From jwaters at openjdk.org  Sun Jun 25 23:42:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 23:42:09 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows [v13]
In-Reply-To: <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <WNzDDvyuiP1pzyRIP5Otsavh5u1PdDoZhobfLllSUQU=.234e4800-1aeb-46dc-a862-326da9337dfb@github.com>
Message-ID: <g9W5Zu_YwH-B81CT-WrOUXlr9hD3JrkGP3Z1AtL-cNo=.b2f493fb-10ac-483e-8747-e988bd104d7b@github.com>

On Sat, 24 Jun 2023 01:29:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Leave nullptr for another day
>  - src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp
>    
>    Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Haha, thanks Alexsey!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1606329100

From jwaters at openjdk.org  Sun Jun 25 23:46:17 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 23:46:17 GMT
Subject: Integrated: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <MXS9qJEUSawtZOjSVthEal4GTj6-igakdl6GvYg200s=.fe2c1484-8ea9-4584-b4da-d5def77bb101@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

This pull request has now been integrated.

Changeset: c92b049d
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c92b049db7853a061ce05cebdc1fd73205ed0c83
Stats:     28 lines in 10 files changed: 0 ins; 5 del; 23 mod

8308780: Fix the Java Integer types on Windows

Reviewed-by: dholmes, djelinski, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/14125

From dholmes at openjdk.org  Mon Jun 26 00:35:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 00:35:18 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <4byEsN8A77TyPs1uUYoCajUiOUy54KE1TRl_PeQG7MA=.3ead4dde-1553-4499-adc0-9a2ba6d53022@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
 <4byEsN8A77TyPs1uUYoCajUiOUy54KE1TRl_PeQG7MA=.3ead4dde-1553-4499-adc0-9a2ba6d53022@github.com>
Message-ID: <p_dBY8Ae1WxhGzhecNFJt_ZqAjqRDXaXOsjfWaf7L6o=.ef745d47-9310-41d0-a0aa-d3f78bf4bc72@github.com>

On Sun, 25 Jun 2023 15:58:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge branch 'openjdk:master' into patch-6
>>  - Whitespace
>>  - Revert
>>  - _MSC_VER
>>  - Restore visCPP
>>  - Restore gcc attribute
>>  - Revert gcc
>>  - Revert
>>  - Semicolon
>>  - gcc offset_of
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3
>
> Bumping

@TheShermanTanker  this is causing build failures in our CI in tier1:

 c:\sb\prod\1687737602\workspace\open\src\jdk.jdwp.agent\share\native\libjdwp\ArrayReferenceImpl.c(26): fatal error C1083: Cannot open include file: 'stdalign.h': No such file or directory

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606360752

From jwaters at openjdk.org  Mon Jun 26 00:35:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 00:35:18 GMT
Subject: Integrated: 8305341: Alignment should be enforced by alignas instead
 of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <UqgCujJEUXTyx3J7e8Ke9FGudpp1ZlW_o93Up74yNoo=.b5e64a90-3819-4514-aa9d-576b55024a10@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

This pull request has now been integrated.

Changeset: 78c38317
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78c3831701667069e7e048cd56b534ae2d8d15a1
Stats:     11 lines in 3 files changed: 5 ins; 0 del; 6 mod

8305341: Alignment should be enforced by alignas instead of compiler specific attributes

Reviewed-by: mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/13258

From dholmes at openjdk.org  Mon Jun 26 00:40:21 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 00:40:21 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
Message-ID: <lhL7RF6SKE6ROGAZqUMto-zB60CZ_6Wl42dTBg0zq0Y=.2568f0db-57d0-4bc8-8bf7-cf6b972946e6@github.com>

On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'openjdk:master' into patch-6
>  - Whitespace
>  - Revert
>  - _MSC_VER
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert
>  - Semicolon
>  - gcc offset_of
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

Filed: [JDK-8310863](https://bugs.openjdk.org/browse/JDK-8310863)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606362416

From jwaters at openjdk.org  Mon Jun 26 02:38:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 02:38:02 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
Message-ID: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>

Microsoft, your C "conformance" is garbage

-------------

Commit messages:
 - ArrayReferenceImpl.c
 - GSSLibStub.c
 - 8310863

Changes: https://git.openjdk.org/jdk/pull/14645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310863
  Stats: 11 lines in 3 files changed: 0 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14645/head:pull/14645

PR: https://git.openjdk.org/jdk/pull/14645

From jwaters at openjdk.org  Mon Jun 26 02:41:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 02:41:02 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <sPGNzMkMcmQFZKaOKLdJMOmexX6lLWu5jSJ6XC4U-go=.cefd4a94-429c-4a12-b7fb-8c92c8f8dfe7@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Microsoft, your C "conformance" is garbage

@dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606505881

From dholmes at openjdk.org  Mon Jun 26 04:18:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:18:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Microsoft, your C "conformance" is garbage

https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606567568

From jwaters at openjdk.org  Mon Jun 26 04:27:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 04:27:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <gIfm8qZ2FsA7vWIyk33EByUzYQ6Fw-x44H2JMZWwuBE=.da6757dc-7554-4eb9-abb9-a7324584c5a2@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

_Alignas does work on Microsoft Visual C, fortunately

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570803

From jwaters at openjdk.org  Mon Jun 26 04:27:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 04:27:01 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
 <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
Message-ID: <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>

On Mon, 26 Jun 2023 04:15:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170

:/

> How was the original change tested? How was this change tested?

I made the mistake of testing the original on gcc instead of the native compiler for Windows, I recompiled this one with the microsoft toolchain before writing the fix, which fortunately passes the compile step as is evident in the tests for this PR

Sorry for the goof :(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570640
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606572218

From dholmes at openjdk.org  Mon Jun 26 04:27:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:27:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <ieVDNTDPPmqOp5p9LGSKXLJo9UCaASLclqfI7K-FfkQ=.c0c1548a-a301-4681-a765-fd71d15ac9d6@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

How was the original change tested? How was this change tested?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606571300

From dholmes at openjdk.org  Mon Jun 26 04:30:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:30:07 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
 <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
 <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>
Message-ID: <fF9PMyjiDtj0uYFyHPpO584H_yVNacE4k300-EZUef8=.bcd6b4cf-9284-4f73-8dc8-190fca8e3e21@github.com>

On Mon, 26 Jun 2023 04:23:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> as is evident in the tests for this PR

You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606573575

From jwaters at openjdk.org  Mon Jun 26 04:41:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 04:41:02 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <fF9PMyjiDtj0uYFyHPpO584H_yVNacE4k300-EZUef8=.bcd6b4cf-9284-4f73-8dc8-190fca8e3e21@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
 <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
 <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>
 <fF9PMyjiDtj0uYFyHPpO584H_yVNacE4k300-EZUef8=.bcd6b4cf-9284-4f73-8dc8-190fca8e3e21@github.com>
Message-ID: <h9OrsAqvs6OYNLkpnAu45lb8uZ-eY1Dk9GetYUp0v9o=.0b228d52-f784-4ad5-9a05-51c6833c0c0a@github.com>

On Mon, 26 Jun 2023 04:26:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > as is evident in the tests for this PR
> 
> You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target.

I can't recompile the JDK at the moment to compile ArrayReferenceImpl.c, but I can devise a simple test for this:


#include <stdio.h>

int main() {
    _Alignas(8)
    int i = 7;
    printf("%i", i);
    return 0;
}


`cl.exe -nologo -std:c11 -Fo:align.o align.c`


align.exe
7


The _Alignas specifier does the same thing as the __declspec(align()) one, so there's no difference in which is used (which also means that the other places where this is used being able to compile is proof of it working as well)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606579037

From dholmes at openjdk.org  Mon Jun 26 04:41:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:41:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <GcoRdVwL-m1RqrVHwpFCTXgENFSa_I6Yyj5Fq9h3yBc=.f950417d-92e6-47dc-b08b-8d6b1fce25f2@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

Okay I have it running through our tier1 builds at the moment. If that passes I will approve the PR. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606580347

From thartmann at openjdk.org  Mon Jun 26 05:08:02 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 26 Jun 2023 05:08:02 GMT
Subject: RFR: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
In-Reply-To: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>
References: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>
Message-ID: <1vmj0h4iaeclaAWNDkCrtUsF0iKVTHzdenMYBK4KNgI=.833866fa-4df2-49cc-a421-e191d97b52d2@github.com>

On Fri, 23 Jun 2023 16:43:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Backing out shuffle related overhaul done with [JDK-8304450](https://bugs.openjdk.org/browse/JDK-8304450), we saw significant performance degradation in VectorAPI JMH micros and some of our internal benchmarks. Following two issues were filed on this recently.
> 
> 1/ [JDK-8310459](https://bugs.openjdk.org/browse/JDK-8310459): Performance drop in VectorAPI slice / unslice performance w.r.t to JDK-20.
> 2/ [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373): Performance drop in Vector-API based kernel with JDK-21.
> 
> A follow-up JBS [JDK-8310691](https://bugs.openjdk.org/browse/JDK-8310691) is created to address this in JDK-22.
> 
> Best Regards,
> Jatin

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14629#pullrequestreview-1497576693

From cjplummer at openjdk.org  Mon Jun 26 05:14:03 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 05:14:03 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <y6e_N1LMrTBZdZekhjzGj2KwcMhVO-qFNgnUXudcgE8=.20369c56-290f-4f8c-ae2e-a2399fcde214@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
 <y6e_N1LMrTBZdZekhjzGj2KwcMhVO-qFNgnUXudcgE8=.20369c56-290f-4f8c-ae2e-a2399fcde214@github.com>
Message-ID: <XFE3cHwoEO7y4dB1gKsSXxFoR7clRga_op-MvwUFbfE=.26f21c73-1ff1-488a-88e8-34fafbfb3bfb@github.com>

On Fri, 23 Jun 2023 08:37:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Chris are you okay with the latest rev. of this change?

Sorry, I've been on vacation the past few days. I will have a look at it tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1606661232

From dholmes at openjdk.org  Mon Jun 26 05:30:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 05:30:10 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <JP0QBb6B31vaJbtU67lM3LQTpdkEkbLYuxgFB7YEKbU=.e2aa89c0-6deb-4db1-863f-d714970d249e@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

Our tier 1 builds have passed.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14645#pullrequestreview-1497595990

From jwaters at openjdk.org  Mon Jun 26 05:41:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 05:41:09 GMT
Subject: Integrated: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <1sF7T0TaWs_9uqjxf3c0f1P6LAvg9ONJjMnPvhy1wR8=.f8a77de2-f674-4733-8be3-b43bf66e6a4f@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

This pull request has now been integrated.

Changeset: 8242c647
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8242c647b9d31320757363b69e7048a109ce86df
Stats:     11 lines in 3 files changed: 0 ins; 5 del; 6 mod

8310863: Build failure after  JDK- 8305341

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/14645

From jpai at openjdk.org  Mon Jun 26 06:07:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 06:07:25 GMT
Subject: RFR: 8310868: Thread.interrupt() method's javadoc has an incorrect
 {@link}
Message-ID: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>

Can I please get a review of this trivial change which fixes a javadoc issue reported in https://bugs.openjdk.org/browse/JDK-8310868?

I ran `make docs-image` locally with this change and the link is now correctly rendered in the generated javadoc.

-------------

Commit messages:
 - 8310868: Thread.interrupt() method's javadoc has an incorrect {@link}

Changes: https://git.openjdk.org/jdk/pull/14646/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14646&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310868
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14646/head:pull/14646

PR: https://git.openjdk.org/jdk/pull/14646

From jpai at openjdk.org  Mon Jun 26 06:13:04 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 06:13:04 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <9iTNXLdKIZNHSUAJb6GKj5eGoHoks7qFKWfKaCf7Sls=.cfd6c7a5-4930-4e91-8241-a897d7063e90@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

Hello Glavo,

> @AlanBateman @jaikiran Sorry, I thought about its possible impact on startup time, but I don't know which tests can be used to test JVM startup time. Can you tell me some relevant tests?
> 
> In fact, I now have a branch(#14636) that rewrites `ByteArray` and `ByteArrayLittleEndian` to avoid using `VarHandle` because I hope to be able to use them more inside the JDK later.
> 

I think this PR should then wait for a bit to see what comes out of https://github.com/openjdk/jdk/pull/14636. That will then help us understand what kind of additional testing might have to be considered for this current PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1606715060

From alanb at openjdk.org  Mon Jun 26 06:22:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jun 2023 06:22:04 GMT
Subject: RFR: 8310868: Thread.interrupt() method's javadoc has an incorrect
 {@link}
In-Reply-To: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>
References: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>
Message-ID: <sYzRkazR3Q4yz11QIvgi5b91R4P0aZaQ7cSecg0to6k=.b37ee7e2-44c4-472b-b791-370f71593b70@github.com>

On Mon, 26 Jun 2023 05:58:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which fixes a javadoc issue reported in https://bugs.openjdk.org/browse/JDK-8310868?
> 
> I ran `make docs-image` locally with this change and the link is now correctly rendered in the generated javadoc.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14646#pullrequestreview-1497648617

From jpai at openjdk.org  Mon Jun 26 06:29:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 06:29:09 GMT
Subject: RFR: 8310868: Thread.interrupt() method's javadoc has an incorrect
 {@link}
In-Reply-To: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>
References: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>
Message-ID: <nYxnYNCC11qTqi1SQkJEBVr5nfGfC1lxCEraJ6b07Nc=.5a5a7850-c7a7-47d0-94c0-a68f1bf20ae4@github.com>

On Mon, 26 Jun 2023 05:58:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which fixes a javadoc issue reported in https://bugs.openjdk.org/browse/JDK-8310868?
> 
> I ran `make docs-image` locally with this change and the link is now correctly rendered in the generated javadoc.

Thank you Alan for the review. 

Given this is a doc-only change, I'll propose a backport to 21 repo shortly after this is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14646#issuecomment-1606733211

From jpai at openjdk.org  Mon Jun 26 06:29:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 06:29:10 GMT
Subject: Integrated: 8310868: Thread.interrupt() method's javadoc has an
 incorrect {@link}
In-Reply-To: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>
References: <gWd-KsINaRFNL-sCwZk0_SJHpq0O4LsTbUSDnzLYME4=.ced42b47-4da0-46b9-9ee3-bf4ee2f9ab67@github.com>
Message-ID: <ZbY1hfoCG-RjeUK0UP2sKdGIotgaK644JyeFzNuC5MM=.df2742a5-7e3e-401a-a136-812eafec9afc@github.com>

On Mon, 26 Jun 2023 05:58:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which fixes a javadoc issue reported in https://bugs.openjdk.org/browse/JDK-8310868?
> 
> I ran `make docs-image` locally with this change and the link is now correctly rendered in the generated javadoc.

This pull request has now been integrated.

Changeset: 013367b4
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/013367b4831094cdd330564378de69deccd0dc4b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310868: Thread.interrupt() method's javadoc has an incorrect {@link}

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14646

From jpai at openjdk.org  Mon Jun 26 06:36:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 06:36:23 GMT
Subject: [jdk21] RFR: 8310868: Thread.interrupt() method's javadoc has an
 incorrect {@link}
Message-ID: <10s-ah49FVGRHGPMEFEtyaRAGjOgtD4TeVXoP8cG6uE=.63bfc93a-71ae-4690-8976-ea7a49a34673@github.com>

Hi all,

  This pull request contains a backport of commit [013367b4](https://github.com/openjdk/jdk/commit/013367b4831094cdd330564378de69deccd0dc4b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

  The commit being backported was authored by Jaikiran Pai on 26 Jun 2023 and was reviewed by Alan Bateman.

  Thanks!

-------------

Commit messages:
 - Backport 013367b4831094cdd330564378de69deccd0dc4b

Changes: https://git.openjdk.org/jdk21/pull/62/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=62&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310868
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/62/head:pull/62

PR: https://git.openjdk.org/jdk21/pull/62

From duke at openjdk.org  Mon Jun 26 07:03:22 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 07:03:22 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v6]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <pOvLWlwkhuJBmWjY3aG9T_vUK3IMuqLh3vxpYhdXXek=.8ad03f6c-4b4a-4d01-81e8-8ff0a937d07a@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  delete incorrect comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/4ac26325..217caa3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=04-05

  Stats: 16 lines in 2 files changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From stsypanov at openjdk.org  Mon Jun 26 07:07:08 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 26 Jun 2023 07:07:08 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v4]
In-Reply-To: <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
 <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
 <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
Message-ID: <pmUBg2WVYPSlGg3RhUwUv_b-yU_ucRn2KQ5FxpTxHLc=.c01b721e-deec-40c2-98d4-9e39de57ed0f@github.com>

On Sun, 25 Jun 2023 22:32:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'll re-run our CI, and if all good, I'll sponsor this PR.
>
>> I'll re-run our CI, and if all good, I'll sponsor this PR.
> 
> The CI tests I started have just passed. While this PR is already good, I wonder if we make it even better.
> 
> I doubt highly that we need null-checks for CacheKey's name and locale. My suspicion comes from these two facts:
> 
> * CacheKey's hashCode calls methods on these fields without checking them for null, and
> * CacheKey instances are queried and stored in ConcurrentHashMap, which certainly uses both `equals` and `hashCode`
> 
> So, what I'm saying is that if those fields were null, there would be unhandled NPE somewhere; but I cannot see such NPE.  Additionally, those fields are used in toString(). Furthermore, locale is known to not be null because the only place from where it is passed to a CacheKey consturctor is ResourceBundle.getBundleImpl(Module, Module, String, Locale, ResourceBundle.Control), which explicitly checks that locale for not being null.
> 
> Does it make sense?

@pavelrappo you mean we can revert changes to ResourceBundle.java in lines 729 and 733?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1606832885

From duke at openjdk.org  Mon Jun 26 07:12:06 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 07:12:06 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v6]
In-Reply-To: <pOvLWlwkhuJBmWjY3aG9T_vUK3IMuqLh3vxpYhdXXek=.8ad03f6c-4b4a-4d01-81e8-8ff0a937d07a@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <pOvLWlwkhuJBmWjY3aG9T_vUK3IMuqLh3vxpYhdXXek=.8ad03f6c-4b4a-4d01-81e8-8ff0a937d07a@github.com>
Message-ID: <Qi92DOk4kYykz5F2zFEiYAaq1N-xPztobdmsSa3PgMQ=.b8879da8-be21-4839-acd3-f6b1fe5dc410@github.com>

On Mon, 26 Jun 2023 07:03:22 GMT, Glavo <duke at openjdk.org> wrote:

>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
>> 
>> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
>> 
>> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete incorrect comments

I deleted some incorrect comments.

The original author of these two classes misunderstood the behavior of `intBitsToFloat` and `longBitsToDouble`. These two methods never collapse NaN values to a "canonical" NaN value, so the comments is incorrect.

I deleted those comments because conversions from `int`/`long` to `float`/`double` don't need to differentiate that behavior, their difference only exists when converting from `float`/`double` to `int`/`long`.

The conversion methods in the `Float`/`Double` class also exhibits this: there is only one method for converting from `int`/`long` to `float`/`double` , but there are two methods for converting from `float`/`double` to `int`/`long`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1606840551

From asotona at openjdk.org  Mon Jun 26 08:29:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 08:29:57 GMT
Subject: RFR: 8294982: Implementation of Classfile API [v58]
In-Reply-To: <N03UdVNXyGJo0u-6MEwmonhM4bARM-0gKvxdAHrxXGo=.12bed3bf-f4e4-4714-b7c3-15c65e8dd95f@github.com>
References: <UKzYfj5k6Mph8uI8wDUsVWdeEpBeKKOAV2QaeuIsOu8=.141e8462-8b6e-4dd6-867d-e854716634bd@github.com>
 <ruUYxaG6_D79Pkfk-oNqLjuiX_uP2Qi4yfX8aJgfvUo=.042bd99e-d968-4252-8a49-b20dfe0bc17f@github.com>
 <N03UdVNXyGJo0u-6MEwmonhM4bARM-0gKvxdAHrxXGo=.12bed3bf-f4e4-4714-b7c3-15c65e8dd95f@github.com>
Message-ID: <y2FOiUm1i-tenFzpg7_AI9wc5l9fLHHCBCTZixg3xQo=.a4a6c8e4-699c-4415-90fa-368860fc2a72@github.com>

On Fri, 23 Jun 2023 09:05:21 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed obsolete javadoc from implementation classes
>
> src/java.base/share/classes/jdk/internal/classfile/instruction/ConstantInstruction.java line 139:
> 
>> 137:         Util.checkKind(op, Opcode.Kind.CONSTANT);
>> 138:         if (op != Opcode.BIPUSH && op != Opcode.SIPUSH)
>> 139:             throw new IllegalArgumentException(String.format("Wrong opcode specified; found %s, expected BIPUSH or SIPUSH", op, op.kind()));
> 
> IDEA shows warning here.
> Too many arguments for format string (found: 2, expected: 1)
> 
> Seems op.kind() parameter is unused in the format string.
> 
> And the same issue in `jdk.internal.classfile.instruction.ConstantInstruction#ofLoad`

I'll fix it, thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10982#discussion_r1241816908

From asotona at openjdk.org  Mon Jun 26 08:30:21 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 08:30:21 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v23]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <0xM98KB1so7P2R2B3PvqPgb2RAwIJYSBsnYNi0xvN_M=.37db35eb-8501-4021-b5e6-03a4ed35da59@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from liachmodded/fix/sotona-cf-obj-improvements
   
   Changes discussed on mailing list plus minor doc error
 - Changes discussed on mailing list plus minor doc error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/4017e28b..700b5b60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=21-22

  Stats: 56 lines in 4 files changed: 25 ins; 2 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Mon Jun 26 08:52:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 08:52:13 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v24]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <7cP9PBaTb3kovEA4bwUp-WSfhbIvAxxu2KpPIeayGlw=.5e273d1d-dfe3-4fe7-a29e-b24d6a909e64@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixed String format arguments
 - Classfile API javadoc make patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/700b5b60..73b5ca9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=22-23

  Stats: 41 lines in 3 files changed: 37 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From prappo at openjdk.org  Mon Jun 26 09:24:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 09:24:12 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v4]
In-Reply-To: <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <nDkzMZrOjCfIUeFTn-k9DzYVZPzBGvmEMgkO00_Hg_g=.2fcd7689-8b26-41e8-838d-ef196783efa9@github.com>
 <rHIF4SWTMVdGPOOI6wowYIkY_GYASBEmrXlC6BDcOwY=.f2e3ee5a-a059-4f28-adf2-e985ef607673@github.com>
 <DSg0mpjPUki92LSwEmhxY_F3zhrusciy792-pKmZzIk=.c7294529-a7c2-4d4a-95ca-bb63f910ba0f@github.com>
Message-ID: <SD0KiFCK5z1o_F7uEeGxSE4g9gGE69sI3J9d5tgQY3Q=.8229aa98-1e80-4305-aa78-0d76842d4a37@github.com>

On Sun, 25 Jun 2023 22:32:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'll re-run our CI, and if all good, I'll sponsor this PR.
>
>> I'll re-run our CI, and if all good, I'll sponsor this PR.
> 
> The CI tests I started have just passed. While this PR is already good, I wonder if we make it even better.
> 
> I doubt highly that we need null-checks for CacheKey's name and locale. My suspicion comes from these two facts:
> 
> * CacheKey's hashCode calls methods on these fields without checking them for null, and
> * CacheKey instances are queried and stored in ConcurrentHashMap, which certainly uses both `equals` and `hashCode`
> 
> So, what I'm saying is that if those fields were null, there would be unhandled NPE somewhere; but I cannot see such NPE.  Additionally, those fields are used in toString(). Furthermore, locale is known to not be null because the only place from where it is passed to a CacheKey consturctor is ResourceBundle.getBundleImpl(Module, Module, String, Locale, ResourceBundle.Control), which explicitly checks that locale for not being null.
> 
> Does it make sense?

> @pavelrappo you mean we can revert changes to ResourceBundle.java in lines 729 and 733?

Yes, those lines. We can revert to x.equals(otherEntry.x).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1607062302

From aturbanov at openjdk.org  Mon Jun 26 09:29:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Jun 2023 09:29:12 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v24]
In-Reply-To: <xyiTtfzIKEyfSaF803b_cY5DljYm-XOO0OPFVV5MQQg=.584d7009-3c43-4157-8085-d9832b6a98d3@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <xyiTtfzIKEyfSaF803b_cY5DljYm-XOO0OPFVV5MQQg=.584d7009-3c43-4157-8085-d9832b6a98d3@github.com>
Message-ID: <14OlNCw3eVys8q4CsCdVCy3utJJki-cvZ99Pkw-bqIc=.c47d8b70-2885-44c2-9c95-83ea1c9c4590@github.com>

On Sun, 25 Jun 2023 20:38:28 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove JavaLangAccess#fastUUID

src/java.base/share/classes/java/util/UUID.java line 515:

> 513: 
> 514:         try {
> 515:             return jla.newStringNoRepl(buf, StandardCharsets.ISO_8859_1);

in java.base it's better to use `ISO_8859_1.INSTANCE` directly instead of `StandardCharsets.ISO_8859_1`.
See [JDK-8234147](https://bugs.openjdk.org/browse/JDK-8234147)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241889942

From erikj at openjdk.org  Mon Jun 26 09:32:19 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Jun 2023 09:32:19 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
Message-ID: <G2HH46a1taYMgOcec5NyuO8VdM0f22Km2LRV5HkEAqg=.dd217011-3a2d-4357-ba0e-bf46f725822a@github.com>

On Sat, 24 Jun 2023 06:47:48 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

> I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

I think that sounds like a reasonable idea. I'm not following that mailing list. I think you can just post a PR with your suggested contents and target build-dev (through the `build` label). I'm not familiar with this kind of file, so an explanation of which IDEs support it would be good to include.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1607073914

From stsypanov at openjdk.org  Mon Jun 26 09:46:08 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 26 Jun 2023 09:46:08 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v5]
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8301492: Revert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12328/files
  - new: https://git.openjdk.org/jdk/pull/12328/files/e304cfe7..28f0e270

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12328&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12328.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12328/head:pull/12328

PR: https://git.openjdk.org/jdk/pull/12328

From duke at openjdk.org  Mon Jun 26 09:57:31 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 26 Jun 2023 09:57:31 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/4b5019fd..6b61a715

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=23-24

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Mon Jun 26 09:57:31 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 26 Jun 2023 09:57:31 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v24]
In-Reply-To: <14OlNCw3eVys8q4CsCdVCy3utJJki-cvZ99Pkw-bqIc=.c47d8b70-2885-44c2-9c95-83ea1c9c4590@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <xyiTtfzIKEyfSaF803b_cY5DljYm-XOO0OPFVV5MQQg=.584d7009-3c43-4157-8085-d9832b6a98d3@github.com>
 <14OlNCw3eVys8q4CsCdVCy3utJJki-cvZ99Pkw-bqIc=.c47d8b70-2885-44c2-9c95-83ea1c9c4590@github.com>
Message-ID: <YKeBCB1T7-jTvlLdiYRPd_1lDl52ADqdIZSVVwPdmUE=.f3851a70-e903-4ad4-9bad-e7d0ab7563df@github.com>

On Mon, 26 Jun 2023 09:26:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove JavaLangAccess#fastUUID
>
> src/java.base/share/classes/java/util/UUID.java line 515:
> 
>> 513: 
>> 514:         try {
>> 515:             return jla.newStringNoRepl(buf, StandardCharsets.ISO_8859_1);
> 
> in java.base it's better to use `ISO_8859_1.INSTANCE` directly instead of `StandardCharsets.ISO_8859_1`.
> See [JDK-8234147](https://bugs.openjdk.org/browse/JDK-8234147)

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1241927553

From alanb at openjdk.org  Mon Jun 26 10:06:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jun 2023 10:06:03 GMT
Subject: [jdk21] RFR: 8310868: Thread.interrupt() method's javadoc has an
 incorrect {@link}
In-Reply-To: <10s-ah49FVGRHGPMEFEtyaRAGjOgtD4TeVXoP8cG6uE=.63bfc93a-71ae-4690-8976-ea7a49a34673@github.com>
References: <10s-ah49FVGRHGPMEFEtyaRAGjOgtD4TeVXoP8cG6uE=.63bfc93a-71ae-4690-8976-ea7a49a34673@github.com>
Message-ID: <VX4DZrNA4IyRbgChyEQRqQpoCAtEsKMjwE0OjsWMAVo=.8f227151-d77a-4f90-b67b-61df08cd6d48@github.com>

On Mon, 26 Jun 2023 06:28:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hi all,
> 
>   This pull request contains a backport of commit [013367b4](https://github.com/openjdk/jdk/commit/013367b4831094cdd330564378de69deccd0dc4b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>   The commit being backported was authored by Jaikiran Pai on 26 Jun 2023 and was reviewed by Alan Bateman.
> 
>   Thanks!

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/62#pullrequestreview-1498136891

From jpai at openjdk.org  Mon Jun 26 10:12:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 10:12:10 GMT
Subject: [jdk21] Integrated: 8310868: Thread.interrupt() method's javadoc has
 an incorrect {@link}
In-Reply-To: <10s-ah49FVGRHGPMEFEtyaRAGjOgtD4TeVXoP8cG6uE=.63bfc93a-71ae-4690-8976-ea7a49a34673@github.com>
References: <10s-ah49FVGRHGPMEFEtyaRAGjOgtD4TeVXoP8cG6uE=.63bfc93a-71ae-4690-8976-ea7a49a34673@github.com>
Message-ID: <kijmAbrHMo0ZbwJpXkAaT8C69Vl_MEaqH15vIwcMzgc=.2620269f-cc3d-4962-bc30-9aabb9d3e7a1@github.com>

On Mon, 26 Jun 2023 06:28:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hi all,
> 
>   This pull request contains a backport of commit [013367b4](https://github.com/openjdk/jdk/commit/013367b4831094cdd330564378de69deccd0dc4b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
>   The commit being backported was authored by Jaikiran Pai on 26 Jun 2023 and was reviewed by Alan Bateman.
> 
>   Thanks!

This pull request has now been integrated.

Changeset: 63d419ed
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/63d419edd135b3e5e9856cd676e0526024b03fda
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310868: Thread.interrupt() method's javadoc has an incorrect {@link}

Reviewed-by: alanb
Backport-of: 013367b4831094cdd330564378de69deccd0dc4b

-------------

PR: https://git.openjdk.org/jdk21/pull/62

From jpai at openjdk.org  Mon Jun 26 10:51:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 10:51:34 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v18]
In-Reply-To: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
Message-ID: <JUoiisocaBpxS-Yg0B7YoxEE53SQHHorIFOJch63Jxc=.df4b46d6-a31a-4aad-bed0-239970da34a1@github.com>

> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
> 
> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
> 
> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
> 
> A new jtreg test has been added which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - update jdk.tools.jlink.internal.Platform class to be aware of non-current platform's endianness
 - remove no longer needed constructor
 - merge latest from master branch
 - foo
 - merge latest from master branch
 - cleanup test - rename method and update code comment as suggested by Alan
 - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES
 - use test.jdk system property in test
 - don't iterate over the properties file keys and instead do lookup when needed
 - update CDSPluginTest to correctly "simulate" cross-platform test
 - ... and 30 more: https://git.openjdk.org/jdk/compare/013367b4...532ea3f6

-------------

Changes: https://git.openjdk.org/jdk/pull/11943/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11943&range=17
  Stats: 220 lines in 10 files changed: 175 ins; 14 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/11943.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11943/head:pull/11943

PR: https://git.openjdk.org/jdk/pull/11943

From jpai at openjdk.org  Mon Jun 26 10:54:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 10:54:07 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v6]
In-Reply-To: <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>
Message-ID: <2Y8nBtOcZ9_MPPAr-Eg3IWBlSz8a24zdcEij8q5Ewtg=.e460b777-593b-40c1-8295-1df18d81b873@github.com>

On Thu, 22 Jun 2023 19:24:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Refactored test to make it easier to add new Architectures
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Remove duplicate import
>  - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Correct handling of ppc64le/ppc64 using non-canonical architecture.
>    Keep canonical architecture names for s390, amd/x86_64.
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Review suggestions
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/72501cf7...2e04a1ca

src/java.base/share/classes/jdk/internal/util/Architecture.java line 60:

> 58: 
> 59:     /**
> 60:      * Construct an Arctecture with number of address bits and byte order.

Hello Roger, there is a typo here "Arctecture" instead of "Architecture"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14063#discussion_r1241997511

From jpai at openjdk.org  Mon Jun 26 11:05:12 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 11:05:12 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v6]
In-Reply-To: <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>
Message-ID: <n4r4uQ0V_tSPYWJb9XxQR45k3gbGJpNM67NH9P9RBNk=.cab502c7-9773-45b1-9f4a-4201c513daa8@github.com>

On Thu, 22 Jun 2023 19:24:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Refactored test to make it easier to add new Architectures
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Remove duplicate import
>  - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Correct handling of ppc64le/ppc64 using non-canonical architecture.
>    Keep canonical architecture names for s390, amd/x86_64.
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Review suggestions
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/72501cf7...2e04a1ca

The changes in this PR look OK to me. The introduction of instance method `byteOrder()` in the `Architecture` enum, as proposed in this PR, will help with the changes being proposed in https://github.com/openjdk/jdk/pull/11943. That way jlink won't have to have its own mapping of osname-architecture to endianness.
Once this PR is integrated, I'll update that other PR to use this new API and remove the endianness mappings being proposed in that PR.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1498241091

From jpai at openjdk.org  Mon Jun 26 11:07:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 26 Jun 2023 11:07:24 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v18]
In-Reply-To: <JUoiisocaBpxS-Yg0B7YoxEE53SQHHorIFOJch63Jxc=.df4b46d6-a31a-4aad-bed0-239970da34a1@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <JUoiisocaBpxS-Yg0B7YoxEE53SQHHorIFOJch63Jxc=.df4b46d6-a31a-4aad-bed0-239970da34a1@github.com>
Message-ID: <Ggj3fDW7PGb9mdJ8MJiVFrJvHY10P-L1TtGWEGaXhkg=.a8c91064-4904-4144-b7e9-355e3857ff12@github.com>

On Mon, 26 Jun 2023 10:51:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - update jdk.tools.jlink.internal.Platform class to be aware of non-current platform's endianness
>  - remove no longer needed constructor
>  - merge latest from master branch
>  - foo
>  - merge latest from master branch
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES
>  - use test.jdk system property in test
>  - don't iterate over the properties file keys and instead do lookup when needed
>  - update CDSPluginTest to correctly "simulate" cross-platform test
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/013367b4...532ea3f6

This PR has been updated to address the merge conflicts. Additional changes are expected and will be done once https://github.com/openjdk/jdk/pull/14063 is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1607224772

From prappo at openjdk.org  Mon Jun 26 11:21:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 11:21:10 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v5]
In-Reply-To: <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
Message-ID: <tZVsNpdIIExL_-1ZuTLBWEIo0mSPqDHUXPFW0P36nYU=.1bd8f165-2878-405c-9515-b2905c72b2fe@github.com>

On Mon, 26 Jun 2023 09:46:08 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301492: Revert

Thanks, the fix now looks good and simple; testing.

-------------

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1498284842

From liach at openjdk.org  Mon Jun 26 12:13:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 12:13:26 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v2]
In-Reply-To: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
Message-ID: <0RSndddQOQSo4-rJPSPMUWVSxvXLZZNg4NpWOJFLKjc=.a1f0aacf-4c97-41b9-90a6-587ef87ed8dc@github.com>

> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.

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 two additional commits since the last revision:

 - Merge branch 'master' into cleanup/invoke-instanceof
 - 8310849: Pattern matching for instanceof and arrayType cleanup in j.l.invoke and j.l.reflect

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14642/files
  - new: https://git.openjdk.org/jdk/pull/14642/files/86808e33..4f5829e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=00-01

  Stats: 332 lines in 30 files changed: 129 ins; 20 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/14642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14642/head:pull/14642

PR: https://git.openjdk.org/jdk/pull/14642

From liach at openjdk.org  Mon Jun 26 12:15:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 12:15:11 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v3]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <kkIgmVsYJ5mfMI40wNd3DyDlSkYI0NLLVW8j3H4SlSU=.4f4d3ce9-479b-488b-a33b-7f32ab5537f6@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

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:

 - Merge branch 'master' into fix/cd-usage
 - Fix build
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14640/files
  - new: https://git.openjdk.org/jdk/pull/14640/files/82442aac..04cec5e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=01-02

  Stats: 332 lines in 30 files changed: 129 ins; 20 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

PR: https://git.openjdk.org/jdk/pull/14640

From duke at openjdk.org  Mon Jun 26 13:09:15 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 13:09:15 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v2]
In-Reply-To: <0RSndddQOQSo4-rJPSPMUWVSxvXLZZNg4NpWOJFLKjc=.a1f0aacf-4c97-41b9-90a6-587ef87ed8dc@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <0RSndddQOQSo4-rJPSPMUWVSxvXLZZNg4NpWOJFLKjc=.a1f0aacf-4c97-41b9-90a6-587ef87ed8dc@github.com>
Message-ID: <n5CduMmeu1DboTLcwvvnHiO4-Typm7KuRATVLoFYl0Y=.6480bbd5-60b6-4540-bf90-9dc4a2fe0267@github.com>

On Mon, 26 Jun 2023 12:13:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into cleanup/invoke-instanceof
>  - 8310849: Pattern matching for instanceof and arrayType cleanup in j.l.invoke and j.l.reflect

Changes requested by Glavo at github.com (no known OpenJDK username).

src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 359:

> 357:         if (staticArguments == null)
> 358:             return "BSA0=null";
> 359:         return "BSA1="+staticArguments;

Suggestion:

        return switch (staticArguments) {
            case Object[] array -> "BSA="+java.util.Arrays.asList(array);
            case int[] array -> "BSA@"+java.util.Arrays.toString(array);
            case null -> "BSA0=null";
            default -> "BSA1="+staticArguments;
        };

src/java.base/share/classes/sun/invoke/util/ValueConversions.java line 239:

> 237:             return ZERO_INT;
> 238:         }
> 239:         if (x instanceof Number n) {

Number res = switch (x) {
    case Number n -> n;
    case Boolean b -> b ? ONE_INT : ZERO_INT;
    case Character c -> (int) c;
    // this will fail with the required ClassCastException:
    default -> (Number) x;
};

src/java.base/share/classes/sun/invoke/util/ValueConversions.java line 262:

> 260:      */
> 261:     public static int widenSubword(Object x) {
> 262:         if (x instanceof Integer i)

return switch (x) {
    case Integer i -> i;
    case Boolean b -> fromBoolean(b);
    case Character c -> c;
    case Short s -> s;
    case Byte b -> b;
    // Fail with a ClassCastException.
    case null, default -> (int) x;
};

src/java.base/share/classes/sun/invoke/util/Wrapper.java line 583:

> 581: 
> 582:     private static Number numberValue(Object x) {
> 583:         if (x instanceof Number n)     return n;

return switch (x) {
    case Number n -> n;
    case Character c -> (int) c;
    case Boolean b -> b ? 1 : 0;
    // Remaining allowed case of void: Must be a null reference.
    case null, default -> (Number) x;
};

src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java line 252:

> 250:         @Override
> 251:         public boolean equals(Object o) {
> 252:             if (o instanceof AnnotatedType that &&

return o instanceof AnnotatedType that &&
     !(o instanceof AnnotatedArrayType) &&
     !(o instanceof AnnotatedTypeVariable) &&
     !(o instanceof AnnotatedParameterizedType) &&
     !(o instanceof AnnotatedWildcardType) &&
     equalsTypeAndAnnotations(that);

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/GenericArrayTypeImpl.java line 73:

> 71:     @Override
> 72:     public boolean equals(Object o) {
> 73:         if (o instanceof GenericArrayType that) {

return o instanceof GenericArrayType that 
    && Objects.equals(genericComponentType, that.getGenericComponentType());

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/WildcardTypeImpl.java line 171:

> 169:     @Override
> 170:     public boolean equals(Object o) {
> 171:         if (o instanceof WildcardType that) {

return o instanceof WildcardType that
        && Arrays.equals(this.getLowerBounds(), that.getLowerBounds()) 
        && Arrays.equals(this.getUpperBounds(), that.getUpperBounds());

-------------

PR Review: https://git.openjdk.org/jdk/pull/14642#pullrequestreview-1498452572
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242146325
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242152785
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242155031
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242163198
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242161073
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242157078
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242158469

From liach at openjdk.org  Mon Jun 26 13:10:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 13:10:15 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v24]
In-Reply-To: <7cP9PBaTb3kovEA4bwUp-WSfhbIvAxxu2KpPIeayGlw=.5e273d1d-dfe3-4fe7-a29e-b24d6a909e64@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <7cP9PBaTb3kovEA4bwUp-WSfhbIvAxxu2KpPIeayGlw=.5e273d1d-dfe3-4fe7-a29e-b24d6a909e64@github.com>
Message-ID: <XFsl5a2XOOg7pcT3RBcNXtfNp3F4tSed53_V3vzGZIE=.ce4c50d5-e20b-4f2b-bf4a-963c37354079@github.com>

On Mon, 26 Jun 2023 08:52:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed String format arguments
>  - Classfile API javadoc make patch

Since you fixed the string format typos, can you fix this typo as well? https://bugs.openjdk.org/browse/JDK-8308646 and remember to include that issue with `/issue add JDK-8308646` if you do.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607433774

From liach at openjdk.org  Mon Jun 26 13:22:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 13:22:05 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v2]
In-Reply-To: <n5CduMmeu1DboTLcwvvnHiO4-Typm7KuRATVLoFYl0Y=.6480bbd5-60b6-4540-bf90-9dc4a2fe0267@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <0RSndddQOQSo4-rJPSPMUWVSxvXLZZNg4NpWOJFLKjc=.a1f0aacf-4c97-41b9-90a6-587ef87ed8dc@github.com>
 <n5CduMmeu1DboTLcwvvnHiO4-Typm7KuRATVLoFYl0Y=.6480bbd5-60b6-4540-bf90-9dc4a2fe0267@github.com>
Message-ID: <IIzKpXHMEm4BOOX6zXbwSaEg-GmyUETpthINsVS4l1s=.f33d6115-2594-4e27-b540-07edd21c11ae@github.com>

On Mon, 26 Jun 2023 12:53:32 GMT, Glavo <duke 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into cleanup/invoke-instanceof
>>  - 8310849: Pattern matching for instanceof and arrayType cleanup in j.l.invoke and j.l.reflect
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java line 359:
> 
>> 357:         if (staticArguments == null)
>> 358:             return "BSA0=null";
>> 359:         return "BSA1="+staticArguments;
> 
> Suggestion:
> 
>         return switch (staticArguments) {
>             case Object[] array -> "BSA="+java.util.Arrays.asList(array);
>             case int[] array -> "BSA@"+java.util.Arrays.toString(array);
>             case null -> "BSA0=null";
>             default -> "BSA1="+staticArguments;
>         };

Nice observation and suggestions that I've totally missed, but unfortunately these code is used to set up boostrap methods, so pattern matching switches, which are implemented with bootstrap method [`SwitchBootstraps::typeSwitch`](https://github.com/openjdk/jdk/blob/4f5829e3433270d21f75ee949fbc056ae309a494/src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java#L144), cannot be used or it will lead to infinite loops like using lambdas in early startup code.

Meanwhile, even though Supplier, Consumer etc. are loaded as collections are loaded very early in startup, lambdas in their implementation methods are not called until j.l.invoke is ready, so they are safe. It's just some early startup shenanigans. Same story for early-startup records: https://github.com/openjdk/jdk/blob/4f5829e3433270d21f75ee949fbc056ae309a494/src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java#L574-L578

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242181811

From liach at openjdk.org  Mon Jun 26 13:32:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 13:32:13 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v2]
In-Reply-To: <n5CduMmeu1DboTLcwvvnHiO4-Typm7KuRATVLoFYl0Y=.6480bbd5-60b6-4540-bf90-9dc4a2fe0267@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <0RSndddQOQSo4-rJPSPMUWVSxvXLZZNg4NpWOJFLKjc=.a1f0aacf-4c97-41b9-90a6-587ef87ed8dc@github.com>
 <n5CduMmeu1DboTLcwvvnHiO4-Typm7KuRATVLoFYl0Y=.6480bbd5-60b6-4540-bf90-9dc4a2fe0267@github.com>
Message-ID: <cUFDfCHtEjfwFwszpOc4xdUNDkV1Fg9Dg1voUQG2JAs=.09f53b1e-41dc-4b39-8534-c0f5c4d3e5b5@github.com>

On Mon, 26 Jun 2023 12:57:34 GMT, Glavo <duke 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into cleanup/invoke-instanceof
>>  - 8310849: Pattern matching for instanceof and arrayType cleanup in j.l.invoke and j.l.reflect
>
> src/java.base/share/classes/sun/invoke/util/ValueConversions.java line 239:
> 
>> 237:             return ZERO_INT;
>> 238:         }
>> 239:         if (x instanceof Number n) {
> 
> Number res = switch (x) {
>     case Number n -> n;
>     case Boolean b -> b ? ONE_INT : ZERO_INT;
>     case Character c -> (int) c;
>     // this will fail with the required ClassCastException:
>     default -> (Number) x;
> };

Unfortunately, this is used by MethodHandleImpl, so can't use indy switches.

> src/java.base/share/classes/sun/invoke/util/ValueConversions.java line 262:
> 
>> 260:      */
>> 261:     public static int widenSubword(Object x) {
>> 262:         if (x instanceof Integer i)
> 
> return switch (x) {
>     case Integer i -> i;
>     case Boolean b -> fromBoolean(b);
>     case Character c -> c;
>     case Short s -> s;
>     case Byte b -> b;
>     // Fail with a ClassCastException.
>     case null, default -> (int) x;
> };

Also used by MethodHandles.insertArgumentPrimitive, likely not safe.

> src/java.base/share/classes/sun/invoke/util/Wrapper.java line 583:
> 
>> 581: 
>> 582:     private static Number numberValue(Object x) {
>> 583:         if (x instanceof Number n)     return n;
> 
> return switch (x) {
>     case Number n -> n;
>     case Character c -> (int) c;
>     case Boolean b -> b ? 1 : 0;
>     // Remaining allowed case of void: Must be a null reference.
>     case null, default -> (Number) x;
> };

This is used by Wrapper.convert and MethodHandles.insertArgumentPrimitive, which I don't think is a safe candidate either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242192173
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242196620
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242195548

From asotona at openjdk.org  Mon Jun 26 13:33:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 13:33:38 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v25]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8308646: Typo in ConstantValueAttribute

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/73b5ca9f..5723e66a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=23-24

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From liach at openjdk.org  Mon Jun 26 13:51:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 13:51:25 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v3]
In-Reply-To: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
Message-ID: <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>

> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  simplify equals by replacing if with and operators

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14642/files
  - new: https://git.openjdk.org/jdk/pull/14642/files/4f5829e3..7879c150

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=01-02

  Stats: 88 lines in 5 files changed: 0 ins; 63 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/14642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14642/head:pull/14642

PR: https://git.openjdk.org/jdk/pull/14642

From rgiulietti at openjdk.org  Mon Jun 26 14:18:06 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 26 Jun 2023 14:18:06 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <E4LZn6_Opk55iDQbFLQqSlm579v9tEdc3-HtLZYBlsM=.d9b7a164-163c-4a23-902b-3203df7272e8@github.com>

On Fri, 23 Jun 2023 17:27:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

src/java.base/share/classes/java/math/BigInteger.java line 3955:

> 3953:         int i = Arrays.mismatch(m1, 0, len1, m2, 0, len2);
> 3954:         if (i != -1)
> 3955:             return ((m1[i] & LONG_MASK) < (m2[i] & LONG_MASK)) ? -1 : 1;

return Integer.compareUnsigned(m1[i], m2[i]);

or, if you want to be on the safe side

            return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;

While the spec of `compareUnsigned` speaks of negative (<0), zero (==0), and positive (>0) return values (but in fact returns -1, 0, 1), `BigInteger.compareTo()` is more specific for some reason: -1, 0, 1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1242245875

From lancea at openjdk.org  Mon Jun 26 14:18:04 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Jun 2023 14:18:04 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <lzRbaZT9ys-2v-ZszyWYRdugXXPu_Q2_Pq_PfFxrDhY=.0af0f7c4-eb05-4ed8-9279-0f99f3a05d14@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

> @LanceAndersen This one is going to require checking that startup isn't impacted.



> @LanceAndersen This one is going to require checking that startup isn't impacted.

ZipFS has a slightly different macro for `SH`:

  ```
 static final int SH(byte[] b, int n) {
        return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + 1]) << 8);
    }


I think as we compare performance, we also should strive for consistency between Zip and ZipFS implementation as well

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1607586514

From duke at openjdk.org  Mon Jun 26 14:23:03 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 14:23:03 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <lzRbaZT9ys-2v-ZszyWYRdugXXPu_Q2_Pq_PfFxrDhY=.0af0f7c4-eb05-4ed8-9279-0f99f3a05d14@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <lzRbaZT9ys-2v-ZszyWYRdugXXPu_Q2_Pq_PfFxrDhY=.0af0f7c4-eb05-4ed8-9279-0f99f3a05d14@github.com>
Message-ID: <OAGrkEW87Y06qrJUna7TJWKT_v6Vb9nNnyzAb5AE0uQ=.7e32a39c-8a53-430b-8ffc-4c68027ac5e3@github.com>

On Mon, 26 Jun 2023 14:14:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think as we compare performance, we also should strive for consistency between Zip and ZipFS implementation as well

Can we move `ZipUtils`, `ZipCoder`, and `ZipConstants` to other package (such as `jdk.internal.zip`)? Then we can share them between `java.util.zip` and zipfs.

If there's no reason to stop us from doing this, I can open a new PR to do this after this PR is merged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1607592460

From rgiulietti at openjdk.org  Mon Jun 26 14:24:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 26 Jun 2023 14:24:04 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <9yeqS8-ag63bGyQQ7JKvODTwOK1txZUfLI8--XS-dRo=.a1405b62-70a3-4d02-911e-79da2739c448@github.com>

On Fri, 23 Jun 2023 17:27:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

src/java.base/share/classes/java/math/BigInteger.java line 1:

> 1: /*

On L.3932, I think you can simplify

        return signum > val.signum ? 1 : -1;

with

        return signum;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1242282379

From alanb at openjdk.org  Mon Jun 26 14:28:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jun 2023 14:28:02 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <OAGrkEW87Y06qrJUna7TJWKT_v6Vb9nNnyzAb5AE0uQ=.7e32a39c-8a53-430b-8ffc-4c68027ac5e3@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <lzRbaZT9ys-2v-ZszyWYRdugXXPu_Q2_Pq_PfFxrDhY=.0af0f7c4-eb05-4ed8-9279-0f99f3a05d14@github.com>
 <OAGrkEW87Y06qrJUna7TJWKT_v6Vb9nNnyzAb5AE0uQ=.7e32a39c-8a53-430b-8ffc-4c68027ac5e3@github.com>
Message-ID: <q6GF9bcFJJhaGF4WAUS_GBH7m23b2zWVWEURML-T6hI=.43163356-ca8c-4147-8a80-41a720bcc8a9@github.com>

On Mon, 26 Jun 2023 14:18:15 GMT, Glavo <duke at openjdk.org> wrote:

> If there's no reason to stop us from doing this, I can open a new PR to do this after this PR is merged.

We shouldn't rush into that as it it creates coupling between java.base and jdk.zipfs that is problematic for maintenance, integrity and security. Need to be careful with every qualified exports that is added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1607604204

From duke at openjdk.org  Mon Jun 26 14:36:03 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 14:36:03 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <q6GF9bcFJJhaGF4WAUS_GBH7m23b2zWVWEURML-T6hI=.43163356-ca8c-4147-8a80-41a720bcc8a9@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
 <lzRbaZT9ys-2v-ZszyWYRdugXXPu_Q2_Pq_PfFxrDhY=.0af0f7c4-eb05-4ed8-9279-0f99f3a05d14@github.com>
 <OAGrkEW87Y06qrJUna7TJWKT_v6Vb9nNnyzAb5AE0uQ=.7e32a39c-8a53-430b-8ffc-4c68027ac5e3@github.com>
 <q6GF9bcFJJhaGF4WAUS_GBH7m23b2zWVWEURML-T6hI=.43163356-ca8c-4147-8a80-41a720bcc8a9@github.com>
Message-ID: <aQbBvLevKTiqyGi_JIczDG-R6MQiUV6WdK67UwmvoLs=.a07be4a1-bdaa-413c-b819-91b6b88eb0b1@github.com>

On Mon, 26 Jun 2023 14:25:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We shouldn't rush into that as it it creates coupling between java.base and jdk.zipfs that is problematic for maintenance, integrity and security. Need to be careful with every qualified exports that is added.

Oh well. I'm just confused as to why these few classes are being duplicated, is it for historical reasons?

Another question that confuses me is why `ZipUtils` needs to use `Unsafe` to get the `hb` and `offset` fields of `ByteBuffer`. Is it because of performance?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14632#issuecomment-1607619193

From prappo at openjdk.org  Mon Jun 26 14:42:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 14:42:05 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <9yeqS8-ag63bGyQQ7JKvODTwOK1txZUfLI8--XS-dRo=.a1405b62-70a3-4d02-911e-79da2739c448@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9yeqS8-ag63bGyQQ7JKvODTwOK1txZUfLI8--XS-dRo=.a1405b62-70a3-4d02-911e-79da2739c448@github.com>
Message-ID: <4k1fh-2VE3vBr8mCj0cRTQ34r3F8M96zuBFkelfSUIY=.fdf63337-39b6-46d1-9251-916143d5e0a2@github.com>

On Mon, 26 Jun 2023 14:21:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> src/java.base/share/classes/java/math/BigInteger.java line 1:
> 
>> 1: /*
> 
> On L.3932, I think you can simplify
> 
>         return signum > val.signum ? 1 : -1;
> 
> with
> 
>         return signum;

Thanks for looking at this. My reply to both of your comments, is that there are further improvements possible, and I'd be happy to explore such possibilities later. Right now I'm more concerned with `hashCode` and possible performance degradation, which my local benchmarks on arm64 showed approx. 10%.

On your signum suggestion: signum of 0 is what makes that suggestion inapplicable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1242308794

From rriggs at openjdk.org  Mon Jun 26 14:43:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 14:43:13 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <P8KFb7XfTR8WwyIaY6vQVs1nywiQMUa78C4e_3gGTMw=.cdcf26a0-f4c0-401e-bd23-06e9cba25659@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
 <SFh0bIDiVmyDjxEsIjfrBYFyXcg1zunqYNlhovPWKZE=.ec92be93-856e-47d8-9a69-a9c8f5f69414@github.com>
 <P8KFb7XfTR8WwyIaY6vQVs1nywiQMUa78C4e_3gGTMw=.cdcf26a0-f4c0-401e-bd23-06e9cba25659@github.com>
Message-ID: <7rUoucqiT2zF5MgliY0SNNBge35eBD-W7EKarqIqGHE=.6ecc8e3a-a3cf-47c9-b17a-4fb08b24bf73@github.com>

On Sun, 25 Jun 2023 17:37:27 GMT, Glavo <duke at openjdk.org> wrote:

> To be honest, I have never seen anyone actually use the `-XX:-CompactStrings`. Perhaps at some point in the future, we can investigate its usage and consider deprecate it to reduce the maintenance cost of JDK?

The implementation should do its best whether or not CompactStrings is true or false. (Until the time it is deprecated and remove).  Throwing an internal error is not an option.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1607631421

From rriggs at openjdk.org  Mon Jun 26 14:43:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 14:43:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v24]
In-Reply-To: <YKeBCB1T7-jTvlLdiYRPd_1lDl52ADqdIZSVVwPdmUE=.f3851a70-e903-4ad4-9bad-e7d0ab7563df@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <xyiTtfzIKEyfSaF803b_cY5DljYm-XOO0OPFVV5MQQg=.584d7009-3c43-4157-8085-d9832b6a98d3@github.com>
 <14OlNCw3eVys8q4CsCdVCy3utJJki-cvZ99Pkw-bqIc=.c47d8b70-2885-44c2-9c95-83ea1c9c4590@github.com>
 <YKeBCB1T7-jTvlLdiYRPd_1lDl52ADqdIZSVVwPdmUE=.f3851a70-e903-4ad4-9bad-e7d0ab7563df@github.com>
Message-ID: <cJanWFSDbatDl-jAYS-JLBFQWfuNISu8gVdxOenLsOY=.c55bfbf2-8a86-4e21-b586-d1c38aa21779@github.com>

On Mon, 26 Jun 2023 09:52:10 GMT, ??? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 515:
>> 
>>> 513: 
>>> 514:         try {
>>> 515:             return jla.newStringNoRepl(buf, StandardCharsets.ISO_8859_1);
>> 
>> in java.base it's better to use `ISO_8859_1.INSTANCE` directly instead of `StandardCharsets.ISO_8859_1`.
>> See [JDK-8234147](https://bugs.openjdk.org/browse/JDK-8234147)
>
> done

I don't see that it is better and it is unnecessarily spreading around parts of the implementation of charsets that can use the public API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1242307186

From rgiulietti at openjdk.org  Mon Jun 26 14:45:04 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 26 Jun 2023 14:45:04 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <4k1fh-2VE3vBr8mCj0cRTQ34r3F8M96zuBFkelfSUIY=.fdf63337-39b6-46d1-9251-916143d5e0a2@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <9yeqS8-ag63bGyQQ7JKvODTwOK1txZUfLI8--XS-dRo=.a1405b62-70a3-4d02-911e-79da2739c448@github.com>
 <4k1fh-2VE3vBr8mCj0cRTQ34r3F8M96zuBFkelfSUIY=.fdf63337-39b6-46d1-9251-916143d5e0a2@github.com>
Message-ID: <TnQtpTsqbn-Cbkf8hKAwq9kyS9hW98gVJGUbqKfUAHo=.6c70029e-cc77-4833-a1b5-aa274e6eac1e@github.com>

On Mon, 26 Jun 2023 14:38:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 1:
>> 
>>> 1: /*
>> 
>> On L.3932, I think you can simplify
>> 
>>         return signum > val.signum ? 1 : -1;
>> 
>> with
>> 
>>         return signum;
>
> Thanks for looking at this. My reply to both of your comments, is that there are further improvements possible, and I'd be happy to explore such possibilities later. Right now I'm more concerned with `hashCode` and possible performance degradation, which my local benchmarks on arm64 showed approx. 10%.
> 
> On your signum suggestion: signum of 0 is what makes that suggestion inapplicable.

Yep, you're right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1242313577

From alanb at openjdk.org  Mon Jun 26 14:52:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Jun 2023 14:52:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <7rUoucqiT2zF5MgliY0SNNBge35eBD-W7EKarqIqGHE=.6ecc8e3a-a3cf-47c9-b17a-4fb08b24bf73@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
 <SFh0bIDiVmyDjxEsIjfrBYFyXcg1zunqYNlhovPWKZE=.ec92be93-856e-47d8-9a69-a9c8f5f69414@github.com>
 <P8KFb7XfTR8WwyIaY6vQVs1nywiQMUa78C4e_3gGTMw=.cdcf26a0-f4c0-401e-bd23-06e9cba25659@github.com>
 <7rUoucqiT2zF5MgliY0SNNBge35eBD-W7EKarqIqGHE=.6ecc8e3a-a3cf-47c9-b17a-4fb08b24bf73@github.com>
Message-ID: <WuN2Ul0aWsiNUnXOyyFoS0wZCIkPcV1n8FeT85U1ABM=.825cac5f-53cb-4603-bbd9-f37dfde82d41@github.com>

On Mon, 26 Jun 2023 14:40:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To be honest, I have never seen anyone actually use the `-XX:-CompactStrings`. Perhaps at some point in the future, we can investigate its usage and consider deprecate it to reduce the maintenance cost of JDK?

It's come up a few times. I don't think we have any data on usage. It's possible that there are down stream projects (like the J9 VM) that use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1607648505

From rriggs at openjdk.org  Mon Jun 26 14:57:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 14:57:11 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v7]
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14063/files
  - new: https://git.openjdk.org/jdk/pull/14063/files/2e04a1ca..0161e12b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From rriggs at openjdk.org  Mon Jun 26 14:57:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 14:57:16 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v6]
In-Reply-To: <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <_NrhUzV4n1flIdyD06FO5OHL-Wj1nAIpGrMcCKtBsa0=.cad3f2be-19ef-4b4e-bca6-8b6139ffde38@github.com>
Message-ID: <emlvIQOOVYUxFj6bUjZki33EBXkD2lVxyZsrp6GWyPg=.b92097c1-7638-4892-a2c2-5c08616f373d@github.com>

On Thu, 22 Jun 2023 19:24:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Refactored test to make it easier to add new Architectures
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Remove duplicate import
>  - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Correct handling of ppc64le/ppc64 using non-canonical architecture.
>    Keep canonical architecture names for s390, amd/x86_64.
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Review suggestions
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/72501cf7...2e04a1ca

I think this has settled down.
If anyone would care to test it on S390, PPC, LOONGARCH64, or MIPS that would be appreciated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14063#issuecomment-1607655293

From liach at openjdk.org  Mon Jun 26 14:59:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 14:59:24 GMT
Subject: RFR: 8308899: Introduce Classfile.Context and improve
 Classfile.Option(s) [v25]
In-Reply-To: <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
Message-ID: <yosFTn7Qjr_2YovB-RqToUbZ3LEFmhSOfgyk2hrueok=.e17d197d-e07e-4acf-8807-7483cf472677@github.com>

On Mon, 26 Jun 2023 13:33:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308646: Typo in ConstantValueAttribute

I ran `make docs-classfile-api-javadoc` and the results look good in general. There are a few spec and API issues scattered across the whole API, which I think I will probably collect and list them in the mailing list later.

One thing of note is that the JDK itself has a `@sealedGraph` taglet to render the sealed class hierarchy of any class. We might want to add that tag to all our sealed public classes or interfaces. But it requires a somewhat more complicated build process (including generating dot files with graphviz and rendering them to svg) and you might tweak the `SetupExecute` to a full-on `SetupApiDocsGeneration`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607661040

From duke at openjdk.org  Mon Jun 26 15:01:19 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 15:01:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]
In-Reply-To: <7rUoucqiT2zF5MgliY0SNNBge35eBD-W7EKarqIqGHE=.6ecc8e3a-a3cf-47c9-b17a-4fb08b24bf73@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <SXJu2DBLiy6PyW9I7BhiJKJFAmARGEOQCam9gGjOnek=.6d7dc11b-dbbb-47aa-825e-985a0ca2c19b@github.com>
 <SFh0bIDiVmyDjxEsIjfrBYFyXcg1zunqYNlhovPWKZE=.ec92be93-856e-47d8-9a69-a9c8f5f69414@github.com>
 <P8KFb7XfTR8WwyIaY6vQVs1nywiQMUa78C4e_3gGTMw=.cdcf26a0-f4c0-401e-bd23-06e9cba25659@github.com>
 <7rUoucqiT2zF5MgliY0SNNBge35eBD-W7EKarqIqGHE=.6ecc8e3a-a3cf-47c9-b17a-4fb08b24bf73@github.com>
Message-ID: <5IU6kaRFDQg7FSMIb8E0Gu9RQ4OmefAFxNVS5CezJ9Q=.ada1842c-730f-421e-a768-0ecdf6d730b3@github.com>

On Mon, 26 Jun 2023 14:40:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The implementation should do its best whether or not CompactStrings is true or false. (Until the time it is deprecated and remove). Throwing an internal error is not an option.

I understand that we must provide a working implementation for it, but do we really need to do our best to optimize for it?

Take this PR as an example. By using `newStringNoRepl`, it has the best performance when `COMPACT_STRINGS` is `true` and can also work when `COMPACT_STRINGS` is `false`.

But if we want the best performance in both cases, then we will have to create another method to carefully optimize for situations where `COMPACT_STRINGS` is `false`.

What I want to know is whether it is necessary for us to do so? Or do we only need to focus on optimizing situations where `COMPACT_STRINGS` is `true`, while other situations do not require careful optimization?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1607664719

From liach at openjdk.org  Mon Jun 26 15:24:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 15:24:14 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <wIu4Vt1U-yfXg6M__wwwQtwX1jOSgCgDaItN4QEiYCU=.b41991a4-f064-4f67-aef4-29a184415104@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

I think we can work towards only optimizing the (compat string) case. Many other optimization patches improve the performance of certain scenarios without affecting, or at a slight cost for, other scenarios. I think this patch would be acceptable as long as the non-compat case doesn't get a significant overhead compared to the baseline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1607711346

From mcimadamore at openjdk.org  Mon Jun 26 15:43:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jun 2023 15:43:12 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
Message-ID: <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>

On Mon, 26 Jun 2023 13:33:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308646: Typo in ConstantValueAttribute

The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.

A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14180#pullrequestreview-1498842746

From mcimadamore at openjdk.org  Mon Jun 26 15:43:13 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 26 Jun 2023 15:43:13 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
Message-ID: <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>

On Mon, 26 Jun 2023 15:39:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.
> 
> A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?

Also, another observation: the number of updates snippets in javadoc seems rather low for something that touches the main entry point by which client interacts with classfiles. This seems a sign of perhaps not having many end to end examples in the API javadoc?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607741386

From rriggs at openjdk.org  Mon Jun 26 15:49:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 15:49:14 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <yglVHiSh8PsklAOtganUN0fNN0e5OBbLqtmizvlt5AE=.bfbad16d-e449-4f43-9de4-8a8b2cc351bd@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

With respect to performance, it can't be worse than it is today, all optimization is about tradeoffs; in this case I would agree it does not need to be better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1607753363

From liach at openjdk.org  Mon Jun 26 15:57:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 15:57:14 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
 <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
Message-ID: <8p7b9v3BV-JeWZ9rxt3FieJRMBbkuR6sk_CToOgH7BA=.b37309b1-82bc-4d87-8685-10d72fcc18be@github.com>

On Mon, 26 Jun 2023 15:40:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Also, another observation: the number of updates snippets in javadoc seems rather low for something that touches the main entry point by which client interacts with classfiles. This seems a sign of perhaps not having many end to end examples in the API javadoc?

This is because the Classfile object update mostly affects the obtaining of ClassModel and how a ClassBuilder is converted to bytecode. Many examples interact with existing models, or builders for methods/fields/code, so they 
stay unchanged during the snippet update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607765692

From duke at openjdk.org  Mon Jun 26 16:01:08 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 16:01:08 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl
Message-ID: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>

Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.

Reasons:

* Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
* Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

-------------

Commit messages:
 - clean newStringNoRepl1
 - clean newStringNoRepl1
 - Rename jla to JLA
 - Create new method JavaLangAccess::newStringLatin1NoRepl

Changes: https://git.openjdk.org/jdk/pull/14655/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310901
  Stats: 66 lines in 4 files changed: 22 ins; 29 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

PR: https://git.openjdk.org/jdk/pull/14655

From liach at openjdk.org  Mon Jun 26 16:01:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 16:01:09 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <EMy4XoDLvZeZeSr3fC6lCngFMuk8yZi7ICXNg1pnWS4=.cd4ad892-5cc6-49b7-a8ab-200f8b1cc27c@github.com>

On Mon, 26 Jun 2023 15:25:08 GMT, Glavo <duke at openjdk.org> wrote:

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

Since it appears you missed my edit to my comment, this part can be replaced by the newStringLatin1NoRepl as well:
https://github.com/openjdk/jdk/blob/5ff42d14294199eb3bf10b66530f9249fb68810d/src/java.base/share/classes/java/lang/String.java#L812-L814

after this block:

        if (cd instanceof ArrayDecoder ad &&
                ad.isASCIICompatible() &&
                !StringCoding.hasNegatives(src, 0, src.length)) {

I've created a JBS ticket for this patch: https://bugs.openjdk.org/browse/JDK-8310901

In the ticket, I included a more comprehensive description about the whole situation (which is also why I strongly support this patch)

src/java.base/share/classes/java/lang/String.java line 803:

> 801:         }
> 802:         if (cs == US_ASCII.INSTANCE) {
> 803:             if (!StringCoding.hasNegatives(src, 0, src.length)) {

The duplicated compact_string logic below this line and that one for arraydecoder can be replaced by a simple newStringLatin1NoRepl as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1607741464
PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1607760378
PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242379842

From liach at openjdk.org  Mon Jun 26 16:06:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 16:06:02 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <xjDIHc5n3b3OvOWBh585G2nxXFkfMd7xzQte98yrnhU=.e091f5d7-cdb8-49b3-9f49-d25eee4c26e8@github.com>

On Mon, 26 Jun 2023 15:25:08 GMT, Glavo <duke at openjdk.org> wrote:

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 345:

> 343:      *
> 344:      * The caller of this method shall relinquish and transfer the ownership of
> 345:      * the byte array to the callee since the later will not make a copy.

This comment isn't quite right; the byte array is simply trusted/shared, that it should never be changed or modifiable. The caller can freely retain the array (such as in a field) as long as it doesn't change the array.

This is just a copycat of the original newStringNoRepl, which should be fixed; newStringUTF8NoRepl has no such issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242426598

From duke at openjdk.org  Mon Jun 26 16:17:08 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 16:17:08 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v2]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <XG85Y20TAQHoK5mBrqUGIVeQKNe7SMLGQ7gGFkf_oZY=.472df0c1-03c0-409f-966c-70cd1f044de8@github.com>

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/6f682a3c..27bacac1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=00-01

  Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

PR: https://git.openjdk.org/jdk/pull/14655

From duke at openjdk.org  Mon Jun 26 16:19:04 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 16:19:04 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v2]
In-Reply-To: <xjDIHc5n3b3OvOWBh585G2nxXFkfMd7xzQte98yrnhU=.e091f5d7-cdb8-49b3-9f49-d25eee4c26e8@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <xjDIHc5n3b3OvOWBh585G2nxXFkfMd7xzQte98yrnhU=.e091f5d7-cdb8-49b3-9f49-d25eee4c26e8@github.com>
Message-ID: <BZ-c04bl3RCHNnxWHrVBIJMzUCpN-Wq5bCvfc1qbpeY=.92e4c0a2-2532-4e5c-8fca-612a91643915@github.com>

On Mon, 26 Jun 2023 16:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> This is just a copycat of the original newStringNoRepl, which should be fixed; newStringUTF8NoRepl has no such issue.

Unfortunately, the behavior of `newStringUTF8NoRepl` is not the same as that of `newStringNoRepl`, as it actually always copy the byte array.

I have tried to change its behavior to be consistent with newStringNoRepl, but unfortunately it was not accepted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14655#discussion_r1242442737

From bpb at openjdk.org  Mon Jun 26 16:32:10 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Jun 2023 16:32:10 GMT
Subject: Integrated: 8310682: No package-info (and @since) for package
 jdk.nio.mapmode
In-Reply-To: <E5ex0jxUOFEh37YeVi_ZzJG4WUGzp61JgdXDncGpdoQ=.1f29c122-2de6-4195-9712-835a15ccec53@github.com>
References: <E5ex0jxUOFEh37YeVi_ZzJG4WUGzp61JgdXDncGpdoQ=.1f29c122-2de6-4195-9712-835a15ccec53@github.com>
Message-ID: <1p_gsWD60Skm0tSheSK_v2sIwO4lch14jY0E1u1ZSV4=.e52249fc-74e8-40c8-92cc-52d73de23c04@github.com>

On Fri, 23 Jun 2023 16:30:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `package-info.java` for package `jdk.nio.mapmode`.

This pull request has now been integrated.

Changeset: d32eb015
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d32eb015f056b09fa9ae99a2a84b7056cd3d9259
Stats:     33 lines in 1 file changed: 33 ins; 0 del; 0 mod

8310682: No package-info (and @since) for package jdk.nio.mapmode

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14628

From asotona at openjdk.org  Mon Jun 26 16:33:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 16:33:12 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <9_Dn5sX83fcA-bb9T7dbcEl3Htju8KfaxEjItycxeYM=.605f298e-694c-4cd7-bd5c-0be71a9f01f5@github.com>
 <R3oDbZcvnsp0NqhvYei1mVUdQhDX-JN66X4w4YqI4C8=.1ab9eab7-aaa9-4e38-8fd3-4b3b196eb2cf@github.com>
Message-ID: <gsNtfgNBTYx8qOGoTodHpJPr3uj16Au-pS9Lcqqdf30=.438ab44a-5567-4198-ab5c-46e0304fda59@github.com>

On Mon, 26 Jun 2023 15:40:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.
>> 
>> A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?
>
>> The API changes look great. I like the instance usages of ClassFile, and how CF is now used in a centralized fashion to double down as a cache/option store (and entry point for transformation). Seems like a step in a good direction, and make the API feel a little more cohesive.
>> 
>> A small subjective comment - I'm not too fond of using "context" as a variable/accessor name for all the places where we use a classfile. E.g. if classfile is the context, perhaps these variable/accessor should just be named "classfile" ?
> 
> Also, another observation: the number of updates snippets in javadoc seems rather low for something that touches the main entry point by which client interacts with classfiles. This seems a sign of perhaps not having many end to end examples in the API javadoc?

@mcimadamore thank you for review!
Description of `Classfile` instances as "context" is intentional compromise between discoverability (as originally proposed `Classfile.Context` didn't work very well) and clarity of the function (as `Classfile` instances may be simply confused with `ClassModel` instances).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607827611

From asotona at openjdk.org  Mon Jun 26 16:47:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 16:47:46 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v26]
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <-cKMdI--Y3dO60Pyt4xnqkpal7yHUyTflvTi18f8uh0=.2100aac0-9d5e-42af-91c9-692558279f3b@github.com>

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Classfile API javadoc make patch"
  
  This reverts commit dad094d1686e4e16ccd379c091db258bec0087c5.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14180/files
  - new: https://git.openjdk.org/jdk/pull/14180/files/5723e66a..d3d3831c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14180&range=24-25

  Stats: 39 lines in 2 files changed: 0 ins; 37 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14180/head:pull/14180

PR: https://git.openjdk.org/jdk/pull/14180

From asotona at openjdk.org  Mon Jun 26 16:47:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 26 Jun 2023 16:47:48 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v25]
In-Reply-To: <yosFTn7Qjr_2YovB-RqToUbZ3LEFmhSOfgyk2hrueok=.e17d197d-e07e-4acf-8807-7483cf472677@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <xOQK4GaNToZwPtE86CKiD1psLVWjAlKzb1Idd_rt_VA=.74ab8fd9-dfc5-40eb-9e55-9c598c90d9c6@github.com>
 <yosFTn7Qjr_2YovB-RqToUbZ3LEFmhSOfgyk2hrueok=.e17d197d-e07e-4acf-8807-7483cf472677@github.com>
Message-ID: <GPxU-CoyMYg2g2jbVmjSN5SGNEhCs1CmvLYMM4SCuko=.77bc7fd0-4847-4308-9164-63e5144c2e8f@github.com>

On Mon, 26 Jun 2023 14:56:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> I ran `make docs-classfile-api-javadoc` 

Thanks for pointing this out. The makefile patches accidentally fell into this PR.

> One thing of note is that the JDK itself has a `@sealedGraph` taglet to render the sealed class hierarchy of any class. 

I'll look at adding the tags, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1607840084

From naoto at openjdk.org  Mon Jun 26 17:02:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 17:02:12 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v5]
In-Reply-To: <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <To-lwnc01XZ3JzQJ__iFt94bNSSIMd4D6a0NA4xU0hs=.1c48a2c0-6cd4-42ba-a081-a5a8f095d814@github.com>
Message-ID: <N_UJNuThH3Ccndsmbut0tM4l75q2fmwkdHep1NOfZl0=.63bed739-143a-40c4-9432-10ea6b020834@github.com>

On Mon, 26 Jun 2023 09:46:08 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8301492: Revert

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12328#pullrequestreview-1498996353

From jjg at openjdk.org  Mon Jun 26 17:08:10 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Jun 2023 17:08:10 GMT
Subject: [jdk21] RFR: 8309670: java -help output for --module-path / -p is
 incomplete
In-Reply-To: <-okyrcCmSJNm1rmsjkaypjSIpewpNJOOmUWx7GScD6c=.ca60bbd8-2e28-47ff-be83-b90f6bb2e496@github.com>
References: <-okyrcCmSJNm1rmsjkaypjSIpewpNJOOmUWx7GScD6c=.ca60bbd8-2e28-47ff-be83-b90f6bb2e496@github.com>
Message-ID: <IpM8G50mNe5dlPhI0VE6_oYcCX7B7YAQO1Gz8vsTJeI=.de530758-d2f2-485e-aafd-45e617066bdf@github.com>

On Fri, 23 Jun 2023 11:32:04 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4bf78162](https://github.com/openjdk/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christian Stein on 23 Jun 2023 and was reviewed by Mandy Chung and Alan Bateman.
> 
> Thanks!

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/57#pullrequestreview-1499007038

From duke at openjdk.org  Mon Jun 26 17:17:22 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 17:17:22 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v2]
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <IXlWgLkEgh5t6650DS6uT5wlfaysgUo2QviX6YDWMFE=.0b85d214-d854-42c4-83ee-c185496d856b@github.com>

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

Glavo has updated the pull request with a new target base 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 'openjdk:master' into zip-utils
 - use ByteArrayLittleEndian in ZipUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14632/files
  - new: https://git.openjdk.org/jdk/pull/14632/files/bd67e7a3..6ba44e49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=00-01

  Stats: 1887 lines in 77 files changed: 902 ins; 676 del; 309 mod
  Patch: https://git.openjdk.org/jdk/pull/14632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14632/head:pull/14632

PR: https://git.openjdk.org/jdk/pull/14632

From duke at openjdk.org  Mon Jun 26 17:17:27 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 17:17:27 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v3]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <TMDN-iKj2C6Nr7JN5nTmo32vtOpfesnM_Z6RTFqOKAc=.b09bb166-bd2c-4244-99a6-e35b04d7e994@github.com>

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into latin1-no-repl
 - update javadoc
 - clean newStringNoRepl1
 - clean newStringNoRepl1
 - Rename jla to JLA
 - Create new method JavaLangAccess::newStringLatin1NoRepl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/27bacac1..9958348b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=01-02

  Stats: 147 lines in 13 files changed: 90 ins; 15 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

PR: https://git.openjdk.org/jdk/pull/14655

From duke at openjdk.org  Mon Jun 26 17:17:36 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 17:17:36 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v7]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <cxQzRzE2oSWlibmeors60F2jxZf9eGl_o-tLPoJNhlQ=.01ea8b54-8fcf-4f92-9d1e-4d8ed3482d77@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'openjdk:master' into unsafe
 - delete incorrect comments
 - delete extraneous whitespace
 - add javadoc
 - delete extraneous whitespace
 - fix test
 - update tests
 - use Preconditions.AIOOBE_FORMATTER
 - delete extraneous whitespace
 - delete extraneous whitespace
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b293be1a...2b5a4b01

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/217caa3c..2b5a4b01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=05-06

  Stats: 1887 lines in 77 files changed: 902 ins; 676 del; 309 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From duke at openjdk.org  Mon Jun 26 17:18:48 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 26 Jun 2023 17:18:48 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v2]
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <05Z_2UwEO5NRsetKSOV9SZULjyAaJ52uW3fhKo-S6T8=.86abf55a-19cc-40d3-9606-bb95024dd89b@github.com>

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

Glavo has updated the pull request with a new target base 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 'openjdk:master' into tr-locale
 - list mode of jmod and jimage cannot be used normally in turkish locale

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12281/files
  - new: https://git.openjdk.org/jdk/pull/12281/files/da344340..ae8219b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12281&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12281&range=00-01

  Stats: 1045369 lines in 10554 files changed: 731022 ins; 219332 del; 95015 mod
  Patch: https://git.openjdk.org/jdk/pull/12281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12281/head:pull/12281

PR: https://git.openjdk.org/jdk/pull/12281

From cjplummer at openjdk.org  Mon Jun 26 17:30:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 17:30:07 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <_h7vnjrzdStRA3c3IARtSbjUsih9GqMoi72cXMkmzL0=.e2fb94d1-fd87-4d4b-9212-f255f2321477@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Changes requested by cjplummer (Reviewer).

test/lib/jdk/test/lib/Platform.java line 276:

> 274:     }
> 275: 
> 276:     public static boolean hasPlistEntriesOSX() throws IOException {

Although I understand why you chose this API name (it mimics the form used for `isHardenedOSX`), I don't think it is a good choice. `isHardenedOSX` is short for "is this a hardened OSX system". That mapping does not work with `hasPlistEntriesOSX`, which is more like "does this OSX system have plist entries". I would suggest `hasOSXPlistEntries`.

test/lib/jdk/test/lib/util/CoreUtils.java line 154:

> 152:                 }
> 153:             } else {
> 154:                 // codesign has to add entitlements using the plist, if this is not present we might not generate a core file

Suggestion:

                // codesign has to add entitlements using the plist. If this is not present we might not generate a core file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1499040669
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1242519320
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1242520818

From sviswanathan at openjdk.org  Mon Jun 26 17:33:03 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 26 Jun 2023 17:33:03 GMT
Subject: RFR: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
In-Reply-To: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>
References: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>
Message-ID: <2X2ET6_aDFY_R_AsCbN0Y7YHXUyVRs9WoirObnV-zrs=.d1bce1c7-9c94-4224-9d3e-0c828276aa38@github.com>

On Fri, 23 Jun 2023 16:43:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Backing out shuffle related overhaul done with [JDK-8304450](https://bugs.openjdk.org/browse/JDK-8304450), we saw significant performance degradation in VectorAPI JMH micros and some of our internal benchmarks. Following two issues were filed on this recently.
> 
> 1/ [JDK-8310459](https://bugs.openjdk.org/browse/JDK-8310459): Performance drop in VectorAPI slice / unslice performance w.r.t to JDK-20.
> 2/ [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373): Performance drop in Vector-API based kernel with JDK-21.
> 
> A follow-up JBS [JDK-8310691](https://bugs.openjdk.org/browse/JDK-8310691) is created to address this in JDK-22.
> 
> Best Regards,
> Jatin

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14629#pullrequestreview-1499048603

From naoto at openjdk.org  Mon Jun 26 17:39:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 17:39:14 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime when
 tick is 1 microsecond
Message-ID: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>

Fixing the `/ by zero` exception with tick durations less than a millisecond.

-------------

Commit messages:
 - refactor return statement
 - 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

Changes: https://git.openjdk.org/jdk/pull/14657/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14657&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310232
  Stats: 13 lines in 2 files changed: 10 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14657/head:pull/14657

PR: https://git.openjdk.org/jdk/pull/14657

From mchung at openjdk.org  Mon Jun 26 17:53:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 17:53:05 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v7]
In-Reply-To: <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>
Message-ID: <9rbld_NScb9S0zKG5FoeqiRa21R7ug5MxQHrQzWzMh8=.fbde1561-f12b-4af6-a535-7f1eb81d7347@github.com>

On Mon, 26 Jun 2023 14:57:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

This change looks fine to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1499090206

From prappo at openjdk.org  Mon Jun 26 18:02:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:02:13 GMT
Subject: RFR: 8310890: Normalize identifier names
Message-ID: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>

Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.

Also, this PR fixes a few related typos.

-------------

Commit messages:
 - Improve further
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14653/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310890
  Stats: 184 lines in 10 files changed: 0 ins; 0 del; 184 mod
  Patch: https://git.openjdk.org/jdk/pull/14653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14653/head:pull/14653

PR: https://git.openjdk.org/jdk/pull/14653

From iris at openjdk.org  Mon Jun 26 18:10:03 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 26 Jun 2023 18:10:03 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond
In-Reply-To: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
Message-ID: <bIBohEY6Xdfze3edi2qkHDNBtzuxXxfOHp4XQKmP7-c=.3489889b-72fd-4550-af88-c09d030c6498@github.com>

On Mon, 26 Jun 2023 17:31:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `/ by zero` exception with tick durations less than a millisecond.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14657#pullrequestreview-1499116940

From naoto at openjdk.org  Mon Jun 26 18:15:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 18:15:03 GMT
Subject: RFR: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <7gkL2YRq3AiwC62ppD-ZcdJD6KIqSh0jJKaLHXuOaR0=.46b62a7b-a334-485b-897a-c752c58a881c@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

Looks fine to me

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14653#pullrequestreview-1499124651

From rriggs at openjdk.org  Mon Jun 26 18:25:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 18:25:03 GMT
Subject: RFR: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <n-PTCkbhnAgSlgnp5ceEqtttihoysxfSj0zBs2nNlZI=.1cfb44b7-2ac0-455f-875b-4dbf149e11f9@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

Looks good, with or without the suggestion.

src/java.base/share/classes/java/util/EnumMap.java line 690:

> 688:             Object otherValue = em.vals[i];
> 689:             if (otherValue != ourValue &&
> 690:                 (otherValue == null || !otherValue.equals(ourValue)))

Is this the same as java.util.Objects:  
  `!Objects.equals(vals[i], em.vals[i]);`

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14653#pullrequestreview-1499137712
PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242585695

From rriggs at openjdk.org  Mon Jun 26 18:26:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 18:26:02 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond
In-Reply-To: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
Message-ID: <wM0vvbXNrahXaW5cFs14SaU5Bng0Scm3Cma43EMpiP8=.5dd8d667-c46c-4353-b0c2-34625f1ba47d@github.com>

On Mon, 26 Jun 2023 17:31:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `/ by zero` exception with tick durations less than a millisecond.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14657#pullrequestreview-1499140711

From naoto at openjdk.org  Mon Jun 26 18:32:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 18:32:05 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation
In-Reply-To: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
Message-ID: <yzul_J4ddrLszSE-5Y8w8r_ywwi_lhQLc-Ret2M0RJo=.fc81a5be-f9ea-43df-bb9c-0b0587f39a1f@github.com>

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
> The code is refactored in `compareInstant` to do the comparison of `LocalDateTime` exactly once, if it is needed.
> 
> This case is covered by existing tests in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

src/java.base/share/classes/java/time/OffsetDateTime.java line 173:

> 171:      * to distinguish them. This step is needed to make the ordering
> 172:      * consistent with {@code equals()}.
> 173:      *

This method is also called from the public `timeLineOrder()` method. Could this change cause a different order?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14618#discussion_r1242593059

From lancea at openjdk.org  Mon Jun 26 18:32:13 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Jun 2023 18:32:13 GMT
Subject: RFR: 8310828: java.sql java.sql.rowset packages have no `@since` info
Message-ID: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>

Hi all,

Please review this trivial change which adds the `@since` javadoc tag to the various ` java.sql `and `java.sql.rowset` packages.

Best
Lance

-------------

Commit messages:
 - Remove empty line
 - Add @since to package-info.java

Changes: https://git.openjdk.org/jdk/pull/14652/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14652&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310828
  Stats: 19 lines in 7 files changed: 7 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14652.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14652/head:pull/14652

PR: https://git.openjdk.org/jdk/pull/14652

From duke at openjdk.org  Mon Jun 26 18:34:07 2023
From: duke at openjdk.org (Jens Lidestrom)
Date: Mon, 26 Jun 2023 18:34:07 GMT
Subject: RFR: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

make/data/charsetmapping/charsets line 149:

> 147:     package sun.nio.cs
> 148:     type    sbcs
> 149:     histname ISO8859_2

Should this column be re-aligned with the longer name?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242595069

From jbhateja at openjdk.org  Mon Jun 26 18:38:12 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 26 Jun 2023 18:38:12 GMT
Subject: Integrated: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
In-Reply-To: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>
References: <lJHlmxH_j5Cod7YNe1uucm7giDtK0HLAz98bF_ngd-g=.a0ac3306-0ae4-4c34-994e-cc8cbe448f9b@github.com>
Message-ID: <lBxu-xUlTCqgkvDVP_oAoHAbyx5_Xwi1hqB2ILN1zxY=.205f8c8f-557b-4ae5-8000-6f99cc5300b5@github.com>

On Fri, 23 Jun 2023 16:43:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Backing out shuffle related overhaul done with [JDK-8304450](https://bugs.openjdk.org/browse/JDK-8304450), we saw significant performance degradation in VectorAPI JMH micros and some of our internal benchmarks. Following two issues were filed on this recently.
> 
> 1/ [JDK-8310459](https://bugs.openjdk.org/browse/JDK-8310459): Performance drop in VectorAPI slice / unslice performance w.r.t to JDK-20.
> 2/ [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373): Performance drop in Vector-API based kernel with JDK-21.
> 
> A follow-up JBS [JDK-8310691](https://bugs.openjdk.org/browse/JDK-8310691) is created to address this in JDK-22.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: ff9a7541
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff9a7541097bd853306a8594c97774f36877a0f9
Stats:     3895 lines in 64 files changed: 1169 ins; 1819 del; 907 mod

8310459: [BACKOUT] 8304450: [vectorapi] Refactor VectorShuffle implementation

Reviewed-by: thartmann, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/14629

From naoto at openjdk.org  Mon Jun 26 18:39:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 18:39:05 GMT
Subject: RFR: 8310828: java.sql java.sql.rowset packages have no `@since`
 info
In-Reply-To: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
References: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
Message-ID: <vn_RgFlFcv6EiSoD3225hJioGMybFt0G_NmeJS_1dMo=.420de9b2-6bac-40ff-8d24-576c8a919002@github.com>

On Mon, 26 Jun 2023 13:00:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which adds the `@since` javadoc tag to the various ` java.sql `and `java.sql.rowset` packages.
> 
> Best
> Lance

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14652#pullrequestreview-1499157778

From iris at openjdk.org  Mon Jun 26 18:39:06 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 26 Jun 2023 18:39:06 GMT
Subject: RFR: 8310828: java.sql java.sql.rowset packages have no `@since`
 info
In-Reply-To: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
References: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
Message-ID: <wIGxDW6ufgSZARad8QNXhDTrpoOU1frGcuQco3cEYa4=.ed08a8cb-addc-47ef-a1c6-a157afd75a7e@github.com>

On Mon, 26 Jun 2023 13:00:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which adds the `@since` javadoc tag to the various ` java.sql `and `java.sql.rowset` packages.
> 
> Best
> Lance

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14652#pullrequestreview-1499165248

From jjg at openjdk.org  Mon Jun 26 18:39:19 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Jun 2023 18:39:19 GMT
Subject: RFR: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
Message-ID: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>

Please review a trivial update to remove a redundant `@since` tag.

-------------

Commit messages:
 - JDK-8310909: java.io.InvalidObjectException has redundant `@since` tag

Changes: https://git.openjdk.org/jdk/pull/14662/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310909
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14662/head:pull/14662

PR: https://git.openjdk.org/jdk/pull/14662

From prappo at openjdk.org  Mon Jun 26 18:41:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:41:06 GMT
Subject: RFR: 8310890: Normalize identifier names
In-Reply-To: <n-PTCkbhnAgSlgnp5ceEqtttihoysxfSj0zBs2nNlZI=.1cfb44b7-2ac0-455f-875b-4dbf149e11f9@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
 <n-PTCkbhnAgSlgnp5ceEqtttihoysxfSj0zBs2nNlZI=.1cfb44b7-2ac0-455f-875b-4dbf149e11f9@github.com>
Message-ID: <Qk6uNgHT6GqAohSQBgJYkjNp77K4__vTrow6idqQ89o=.4f0b2408-ce32-4f1d-91fb-e328c1ba7d1d@github.com>

On Mon, 26 Jun 2023 18:21:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
>> 
>> Also, this PR fixes a few related typos.
>
> src/java.base/share/classes/java/util/EnumMap.java line 690:
> 
>> 688:             Object otherValue = em.vals[i];
>> 689:             if (otherValue != ourValue &&
>> 690:                 (otherValue == null || !otherValue.equals(ourValue)))
> 
> Is this the same as java.util.Objects:  
>   `!Objects.equals(vals[i], em.vals[i]);`

You are right: we can fold this if-else construct into that utility method. That said, it in *this* PR, I'd prefer not to.

The reason is that I've been preparing a much bigger PR that uses Objects.equals as well as other utility methods and modern language features to improve some equals, hashCode, and compareTo implementations across java.base. I'm planning to publish that PR soon. In fact, this change to Java variable names was cherry-picked from that bigger PR, to separate trivial renames from code changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242608041

From lancea at openjdk.org  Mon Jun 26 18:43:02 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 26 Jun 2023 18:43:02 GMT
Subject: RFR: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
In-Reply-To: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
References: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
Message-ID: <yLq4S4JmT6yDtJf-1UYefiN1sl9j-qh7ZUX5avapY3U=.e0de9bc3-2b3a-47a5-8f6a-37a8e83ee7bd@github.com>

On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to remove a redundant `@since` tag.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14662#pullrequestreview-1499179572

From naoto at openjdk.org  Mon Jun 26 18:47:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 26 Jun 2023 18:47:03 GMT
Subject: RFR: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
In-Reply-To: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
References: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
Message-ID: <_NNjuBfmUFNbK4hQpGIWPyxTATRlEwvSkAK_XqX18tg=.57289fb2-1b88-4446-83a1-c3ef70e73bdd@github.com>

On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to remove a redundant `@since` tag.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14662#pullrequestreview-1499185740

From prappo at openjdk.org  Mon Jun 26 18:47:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:47:05 GMT
Subject: RFR: 8310890: Normalize identifier names
In-Reply-To: <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
 <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>
Message-ID: <SAjhx4th-mMHrLFybNA4wfm-CyJKv-hJox8lULAMmFk=.a31ea21b-40f1-4855-b2e8-4b20c9a871ea@github.com>

On Mon, 26 Jun 2023 18:31:06 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
>> 
>> Also, this PR fixes a few related typos.
>
> make/data/charsetmapping/charsets line 149:
> 
>> 147:     package sun.nio.cs
>> 148:     type    sbcs
>> 149:     histname ISO8859_2
> 
> Should this column be re-aligned with the longer name?

I thought about it before publishing the PR. I decided not to re-align anything because (i) the change would be bigger and (ii) the fact that there was already a property that is similarly misaligned; search for:

    internal true

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242617579

From mchung at openjdk.org  Mon Jun 26 18:56:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 18:56:09 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v7]
In-Reply-To: <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
Message-ID: <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>

On Thu, 22 Jun 2023 01:38:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed recommendations from Alan

src/java.base/share/classes/java/lang/invoke/MethodType.java line 1229:

> 1227:      * Note that this is not a strict inverse of {@link #fromMethodDescriptorString fromMethodDescriptorString}.
> 1228:      * Two distinct classes which share a common name but have different class loaders
> 1229:      * will appear identical when viewed within descriptor strings.

Re-reading this, I think this api note reads fine.   OTOH I find a little confusing how you rephrased it.  "A method type produced by changing a component class object to...".   I understand you tried to make it crystal clear two method types may have the identical descriptor strings even if its parameter type or return type are distinct Class objects.   

I think the original version is clear enough and less lengthy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242627816

From prappo at openjdk.org  Mon Jun 26 18:58:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 26 Jun 2023 18:58:03 GMT
Subject: RFR: 8310890: Normalize identifier names
In-Reply-To: <SAjhx4th-mMHrLFybNA4wfm-CyJKv-hJox8lULAMmFk=.a31ea21b-40f1-4855-b2e8-4b20c9a871ea@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
 <QV9dS8UG0P8m8Krb2liDi-97z2VSxhM7MU7tpXjJcDY=.1e5d769f-b219-4a1f-9d07-afb29ff52793@github.com>
 <SAjhx4th-mMHrLFybNA4wfm-CyJKv-hJox8lULAMmFk=.a31ea21b-40f1-4855-b2e8-4b20c9a871ea@github.com>
Message-ID: <KAH4dSHp8umZJ8rfYehG7hlDJYVUTeCfJtZErbIXPyI=.8216967e-a1aa-45ec-bcd6-67cd1bd6457a@github.com>

On Mon, 26 Jun 2023 18:44:42 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> make/data/charsetmapping/charsets line 149:
>> 
>>> 147:     package sun.nio.cs
>>> 148:     type    sbcs
>>> 149:     histname ISO8859_2
>> 
>> Should this column be re-aligned with the longer name?
>
> I thought about it before publishing the PR. I decided not to re-align anything because (i) the change would be bigger and (ii) the fact that there was already a property that is similarly misaligned; search for:
> 
>     internal true

If you are concerned with functionality rather than looks, then I can tell you this:

1. The build succeeds and tier1 tests pass.
2. The code that parses that file expect one or more whitespace characters as a separator:

        String[] tokens = line.split("\\s+");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14653#discussion_r1242629052

From bpb at openjdk.org  Mon Jun 26 18:59:01 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Jun 2023 18:59:01 GMT
Subject: RFR: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
In-Reply-To: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
References: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
Message-ID: <OY3AKX8Ue3PDn1xexPk7hkgimC6x5QrAir8NA3HJhwA=.dc8b137b-5c3a-4592-9ae0-21ce6022b4bc@github.com>

On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to remove a redundant `@since` tag.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14662#pullrequestreview-1499208126

From darcy at openjdk.org  Mon Jun 26 19:04:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 19:04:05 GMT
Subject: RFR: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
In-Reply-To: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
References: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
Message-ID: <Pw5UrwBHGEVk5QTgRil7TVAgUTvVArJQunU7_N69kxA=.65e05665-28c0-4dd9-af2e-2d257dfafbec@github.com>

On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to remove a redundant `@since` tag.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14662#pullrequestreview-1499215438

From darcy at openjdk.org  Mon Jun 26 19:04:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 19:04:06 GMT
Subject: RFR: 8310828: java.sql java.sql.rowset packages have no `@since`
 info
In-Reply-To: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
References: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
Message-ID: <elSiiu4j-38dGlUy5pZeMI4aicKpFI84wG2OFCAo5MI=.25a4fd79-14b3-4b1d-a00c-041a06ee9c75@github.com>

On Mon, 26 Jun 2023 13:00:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which adds the `@since` javadoc tag to the various ` java.sql `and `java.sql.rowset` packages.
> 
> Best
> Lance

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14652#pullrequestreview-1499214654

From bpb at openjdk.org  Mon Jun 26 19:09:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Jun 2023 19:09:03 GMT
Subject: RFR: 8310828: java.sql java.sql.rowset packages have no `@since`
 info
In-Reply-To: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
References: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
Message-ID: <D2hAhoMxuFE0XEMG2Vx6J1sEUV1mOVFq5fwUOHLHnpc=.332f84e6-b394-4d98-a618-6dc8d882e374@github.com>

On Mon, 26 Jun 2023 13:00:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which adds the `@since` javadoc tag to the various ` java.sql `and `java.sql.rowset` packages.
> 
> Best
> Lance

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14652#pullrequestreview-1499225427

From iris at openjdk.org  Mon Jun 26 19:11:02 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 26 Jun 2023 19:11:02 GMT
Subject: RFR: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
In-Reply-To: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
References: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
Message-ID: <iwZG9OqnJfngQX6Sny2flZxK7FmdU62o3MnT3u8PmNg=.7d08f035-6c3a-4854-9bcd-4238e9098af2@github.com>

On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to remove a redundant `@since` tag.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14662#pullrequestreview-1499227762

From jvernee at openjdk.org  Mon Jun 26 19:37:23 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 26 Jun 2023 19:37:23 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v2]
In-Reply-To: <-hS98wCfpghUkzWuyf0MzhpIpCIjOiDDitZ39kx4aeU=.c2dbc3eb-a649-489e-b0cb-eb14d7f55dbf@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
 <dMQ238rubrgCcyRv-456L2yibOvwrz1gWFPUOQTM5TQ=.31dcad26-a466-4806-ab72-33eb1c89a6ef@github.com>
 <i6cFFRmj8BY5ykF4ROioLuh1J0kFrKTRgyHf4fIFeSM=.aeeba4fe-3efa-4b3d-b31e-3f428b0c33f5@github.com>
 <adPNJWEXLNY6LPaqX2N0eeiYUQDyRlp4rfJBqZYWoNI=.5ee36196-7bb8-4e28-adde-3cdd09eab781@github.com>
 <-hS98wCfpghUkzWuyf0MzhpIpCIjOiDDitZ39kx4aeU=.c2dbc3eb-a649-489e-b0cb-eb14d7f55dbf@github.com>
Message-ID: <0zmCETHcp1YHJ7K6BvmpLz7fA9a9qlPdCCEDFFt1WPU=.1c1b9ef6-fa14-45ad-a71d-bf439498a691@github.com>

On Wed, 7 Dec 2022 09:24:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I'm not sure what the conventional move here would be. Adding them to the problem list doesn't seem to make the failures go away in GHA at least. I can exclude them with `@requires` as well.
>
> Hello Jorn,
> 
>> Adding them to the problem list doesn't seem to make the failures go away in GHA at least.
> 
> It appears that these 2 problem listed lines are malformed (it's missing a bug id in each of these lines https://openjdk.org/guide/#problemlisting-jtreg-tests) Maybe that's why those tests didn't get problem listed in the GHA runs?
> 
> I found a more detailed explanation of the syntax here https://openjdk.org/jtreg/faq.html#what-is-a-problemlist.txt-file

Sorry, I didn't notice this comment. I think it didn't show up for me on GitHub since I had resolved the conversation already.

I've created: https://github.com/openjdk/jdk/pull/14664 to fix this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11019#discussion_r1242671538

From stsypanov at openjdk.org  Mon Jun 26 19:45:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 26 Jun 2023 19:45:16 GMT
Subject: Integrated: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey
In-Reply-To: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
Message-ID: <tOgE-FVvX6lj2iE1DCaQ6cMEtLlkN_DUQQGTysHw4V4=.37f0af57-16fe-4435-93a0-1b7d2b0b3317@github.com>

On Tue, 31 Jan 2023 11:40:43 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.

This pull request has now been integrated.

Changeset: 297c7996
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/297c7996311e1e29d4a82fc8ffc7ad322e8ef107
Stats:     7 lines in 2 files changed: 0 ins; 4 del; 3 mod

8301492: Modernize equals() method of ResourceBundle.CacheKey and Bundles.CacheKey

Reviewed-by: prappo, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/12328

From mchung at openjdk.org  Mon Jun 26 19:59:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 19:59:14 GMT
Subject: Integrated: 8310242: Clarify the name parameter to Class::forName
In-Reply-To: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
References: <Nk-arbjfjAT_Qz5OA2p2tMljvJnPd9zG40xtUDDuKRA=.f04dd5f3-1606-4861-929e-6c9d5efeefa8@github.com>
Message-ID: <GtxK5nmNXaGcSf1Op6MnAckFDXT9108xyMTwgNl75Bg=.724d1f3d-5153-4f9a-b833-99181851cf63@github.com>

On Fri, 16 Jun 2023 19:58:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR clarifies the spec of the 3-arg Class::forName  regarding the format of the name for an array type which is of the form: one or more of "[" + binary name of the element type + ";'.

This pull request has now been integrated.

Changeset: 7db2f087
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b
Stats:     139 lines in 2 files changed: 107 ins; 1 del; 31 mod

8310242: Clarify the name parameter to Class::forName

Reviewed-by: rriggs, liach, alanb, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/14528

From mchung at openjdk.org  Mon Jun 26 20:08:07 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 20:08:07 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v3]
In-Reply-To: <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
Message-ID: <uyQgpZLmWbNXkO4brurRdRvadvGG7Zv4_Ix7rGEfKb4=.ad214a5c-a85b-4047-a465-7f9522b95e92@github.com>

On Mon, 26 Jun 2023 13:51:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify equals by replacing if with and operators

Looks okay to me.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 899:

> 897:             return equals(mt);
> 898:         }
> 899:         if (x instanceof ConcurrentWeakInternSet.WeakEntry<?> e && e.get() instanceof MethodType mt) {

Nit: break this long line into 2.

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java line 189:

> 187:                                                         that.getActualTypeArguments());
> 188:                 for (Type t : actualTypeArguments) {
> 189:                     System.out.printf("\t\t%s%s%n", t, t.getClass());

Surprised that these debugging statements are unnoticed for so many years.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14642#pullrequestreview-1499147829
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242592457
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242595216

From mchung at openjdk.org  Mon Jun 26 20:24:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 20:24:04 GMT
Subject: RFR: 8310838: Correct range notations in MethodTypeDesc
 specification
In-Reply-To: <EZOORJXKd32cXdad38BN6oW5LD9sG3HeJaXHQ1VedQA=.b9e27ab0-754c-4dc4-9d4e-f0d9951472b7@github.com>
References: <EZOORJXKd32cXdad38BN6oW5LD9sG3HeJaXHQ1VedQA=.b9e27ab0-754c-4dc4-9d4e-f0d9951472b7@github.com>
Message-ID: <A4Gpfr5AE9uVIQXc44b26M9JPvwb1ZCvJovwtQ3mamw=.304098a7-2ab9-4ed1-96aa-bc139e5ec65e@github.com>

On Sat, 24 Jun 2023 01:07:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/MethodTypeDesc.html
> 
> These 3 typos are discovered while browsing the online documentation. It probably doesn't need a CSR for it doesn't change the specification at all.

This is just formatting fix.  No CSR needed.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14635#pullrequestreview-1499359946

From rriggs at openjdk.org  Mon Jun 26 20:25:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 20:25:11 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation
In-Reply-To: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
Message-ID: <-rMjlpGNY0j2mxqWzWKU1xZMyZk7n_V8HPn1XZexgUo=.10dd7927-8243-42f5-bad6-0572c9de089c@github.com>

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
> The code is refactored in `compareInstant` to do the comparison of `LocalDateTime` exactly once, if it is needed.
> 
> This case is covered by existing tests in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

Closing because this 'fix' a bigger issue than it fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14618#issuecomment-1608191784

From rriggs at openjdk.org  Mon Jun 26 20:25:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 20:25:13 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation
In-Reply-To: <yzul_J4ddrLszSE-5Y8w8r_ywwi_lhQLc-Ret2M0RJo=.fc81a5be-f9ea-43df-bb9c-0b0587f39a1f@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
 <yzul_J4ddrLszSE-5Y8w8r_ywwi_lhQLc-Ret2M0RJo=.fc81a5be-f9ea-43df-bb9c-0b0587f39a1f@github.com>
Message-ID: <PXP6LXdYf7IhCctPrEAXtLdyzlkskW6O2YDfXNnuM_8=.4f624b45-9706-44e6-ac84-708c3e16ded4@github.com>

On Mon, 26 Jun 2023 18:28:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
>> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
>> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
>> The code is refactored in `compareInstant` to do the comparison of `LocalDateTime` exactly once, if it is needed.
>> 
>> This case is covered by existing tests in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
>
> src/java.base/share/classes/java/time/OffsetDateTime.java line 173:
> 
>> 171:      * to distinguish them. This step is needed to make the ordering
>> 172:      * consistent with {@code equals()}.
>> 173:      *
> 
> This method is also called from the public `timeLineOrder()` method. Could this change cause a different order?

Your are right; I missed that subtlety. With that in mind I don't think the performance impact is sufficient to duplicate more code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14618#discussion_r1242723719

From rriggs at openjdk.org  Mon Jun 26 20:25:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 26 Jun 2023 20:25:14 GMT
Subject: Withdrawn: 8310241: OffsetDateTime compareTo redundant computation
In-Reply-To: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
Message-ID: <i5-6PWKltdCDCAVftSRtO-99pyxNw7ficPjEwQuh7Sc=.5dd05ac2-6cd1-44d9-b427-052fb62fc8c4@github.com>

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
> The code is refactored in `compareInstant` to do the comparison of `LocalDateTime` exactly once, if it is needed.
> 
> This case is covered by existing tests in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14618

From darcy at openjdk.org  Mon Jun 26 20:26:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 26 Jun 2023 20:26:06 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v3]
In-Reply-To: <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
Message-ID: <vii8QwLS8iwWxTJbFHvIrSyqR0UieNsmPbzthWarYuw=.d09777c1-1063-40a3-9f21-76737cbb6261@github.com>

On Mon, 26 Jun 2023 13:51:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify equals by replacing if with and operators

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14642#pullrequestreview-1499363946

From mchung at openjdk.org  Mon Jun 26 20:33:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 20:33:01 GMT
Subject: [jdk21] RFR: 8310242: Clarify the name parameter to Class::forName
Message-ID: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>

Hi all,

This pull request contains a backport of commit [7db2f087](https://github.com/openjdk/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Mandy Chung on 26 Jun 2023 and was reviewed by Roger Riggs, Chen Liang, Alan Bateman and David Holmes.

Thanks!

-------------

Commit messages:
 - Backport 7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b

Changes: https://git.openjdk.org/jdk21/pull/65/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=65&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310242
  Stats: 139 lines in 2 files changed: 107 ins; 1 del; 31 mod
  Patch: https://git.openjdk.org/jdk21/pull/65.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/65/head:pull/65

PR: https://git.openjdk.org/jdk21/pull/65

From cstein at openjdk.org  Mon Jun 26 20:33:03 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 26 Jun 2023 20:33:03 GMT
Subject: [jdk21] Integrated: 8309670: java -help output for --module-path / -p
 is incomplete
In-Reply-To: <-okyrcCmSJNm1rmsjkaypjSIpewpNJOOmUWx7GScD6c=.ca60bbd8-2e28-47ff-be83-b90f6bb2e496@github.com>
References: <-okyrcCmSJNm1rmsjkaypjSIpewpNJOOmUWx7GScD6c=.ca60bbd8-2e28-47ff-be83-b90f6bb2e496@github.com>
Message-ID: <7jKKFyz5T7uMuYcbRwDcqpC3jq9UkekoTnKWpvCeSek=.fccb0f67-2596-4482-9d9a-53b250574cf0@github.com>

On Fri, 23 Jun 2023 11:32:04 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [4bf78162](https://github.com/openjdk/jdk/commit/4bf78162c52564645af79b8324b69d89102dc024) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Christian Stein on 23 Jun 2023 and was reviewed by Mandy Chung and Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: cdb8c707
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/cdb8c707275d8dd14caaa2ba1951e2f8932b96c6
Stats:     18 lines in 2 files changed: 7 ins; 0 del; 11 mod

8309670: java -help output for --module-path / -p is incomplete

Reviewed-by: jjg
Backport-of: 4bf78162c52564645af79b8324b69d89102dc024

-------------

PR: https://git.openjdk.org/jdk21/pull/57

From aturbanov at openjdk.org  Mon Jun 26 20:58:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Jun 2023 20:58:06 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v3]
In-Reply-To: <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
Message-ID: <ML1V-f9QwnyaJANYSYFFGFIfkVrcs5-v8eyOS5FAB-c=.0c7b0797-9eab-4e34-bd18-dce8943438f9@github.com>

On Mon, 26 Jun 2023 13:51:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify equals by replacing if with and operators

src/java.base/share/classes/java/lang/invoke/MemberName.java line 995:

> 993:                 return result;
> 994:             ReflectiveOperationException ex = result.makeAccessException();
> 995:             if (ex instanceof IllegalAccessException iae)  throw iae;

Suggestion:

            if (ex instanceof IllegalAccessException iae) throw iae;

src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java line 189:

> 187:     static Error uncaughtException(Throwable ex) {
> 188:         if (ex instanceof Error error)  throw error;
> 189:         if (ex instanceof RuntimeException re)  throw re;

Suggestion:

        if (ex instanceof Error error) throw error;
        if (ex instanceof RuntimeException re) throw re;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242756653
PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242757121

From jvernee at openjdk.org  Mon Jun 26 21:24:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 26 Jun 2023 21:24:21 GMT
Subject: RFR: 8310914: Remove 2 malformed java/foreign ProblemList entries
Message-ID: <W4FJ2bF5UFs5e9HQ_N8Y7DY1PyKE4-Yj5-66UqVMjt8=.332cc00e-2a81-4074-a1b9-f47871769991@github.com>

Remove 2 malformed problem list entries. These entries are considered malformed according to [1] since they are missing a bug number. 

The `java/foreign/callarranger/TestAarch64CallArranger.java` test was removed, and the `java/foreign/TestLargeSegmentCopy.java` disables x86 in the jtreg test header using `@requires sun.arch.data.model == "64"`, so neither of these entries are needed.

Testing: `jdk_foreign` test suite (which contains these tests)

[1]: https://openjdk.org/jtreg/faq.html#what-is-a-problemlist.txt-file

-------------

Commit messages:
 - remove unneeded problem list entries

Changes: https://git.openjdk.org/jdk/pull/14664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310914
  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14664/head:pull/14664

PR: https://git.openjdk.org/jdk/pull/14664

From mchung at openjdk.org  Mon Jun 26 21:30:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 21:30:12 GMT
Subject: Integrated: JDK-8310922: java/lang/Class/forName/ForNameNames.java
 fails after being added by JDK-8310242
Message-ID: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>

A trivial fix to correct the expected result to be `Inner[].class`.   I missed the rerun of the test to verify the last-minute edit to the test by JDK-8310242.

-------------

Commit messages:
 - JDK-8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242

Changes: https://git.openjdk.org/jdk/pull/14667/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14667&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310922
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14667/head:pull/14667

PR: https://git.openjdk.org/jdk/pull/14667

From dholmes at openjdk.org  Mon Jun 26 21:30:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 21:30:12 GMT
Subject: Integrated: JDK-8310922: java/lang/Class/forName/ForNameNames.java
 fails after being added by JDK-8310242
In-Reply-To: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
References: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
Message-ID: <VnzHjryhvGyH4l_1t_cD3sln7IhgtJKuQUNZh_QVYUk=.d2e8fa50-1546-42a6-81d4-9a27481a2b0e@github.com>

On Mon, 26 Jun 2023 21:21:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix to correct the expected result to be `Inner[].class`.   I missed the rerun of the test to verify the last-minute edit to the test by JDK-8310242.

Looks good.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14667#pullrequestreview-1499454882

From mchung at openjdk.org  Mon Jun 26 21:30:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 21:30:14 GMT
Subject: Integrated: JDK-8310922: java/lang/Class/forName/ForNameNames.java
 fails after being added by JDK-8310242
In-Reply-To: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
References: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
Message-ID: <D3zVekiCDVopVUotvCFVnDCTMxT7VI0jM3X4J3olyyg=.be471a08-6d08-4fe4-aa0d-b2c857979a2a@github.com>

On Mon, 26 Jun 2023 21:21:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix to correct the expected result to be `Inner[].class`.   I missed the rerun of the test to verify the last-minute edit to the test by JDK-8310242.

thanks for the prompt review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14667#issuecomment-1608284057

From mchung at openjdk.org  Mon Jun 26 21:30:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 21:30:15 GMT
Subject: Integrated: JDK-8310922: java/lang/Class/forName/ForNameNames.java
 fails after being added by JDK-8310242
In-Reply-To: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
References: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
Message-ID: <UQpKp22ZZ8E5yxLV17stNlx2BjTsIDfxE7oRjpvfWCU=.73eb1288-f0f0-4694-8f12-021c92720564@github.com>

On Mon, 26 Jun 2023 21:21:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix to correct the expected result to be `Inner[].class`.   I missed the rerun of the test to verify the last-minute edit to the test by JDK-8310242.

This pull request has now been integrated.

Changeset: 7c6a28fd
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c6a28fd0c49e33fe8ffc87c2bbfa5bf7d1551a3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/14667

From dcubed at openjdk.org  Mon Jun 26 21:30:13 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 26 Jun 2023 21:30:13 GMT
Subject: Integrated: JDK-8310922: java/lang/Class/forName/ForNameNames.java
 fails after being added by JDK-8310242
In-Reply-To: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
References: <uwHTJROjgVU6lPJTIT-X5b31e6cDXOEf5Q9UvPFt-u8=.bbae88cc-52d7-4bfb-8cef-f159f8691ee9@github.com>
Message-ID: <_2agSn6WdYk_kAHuzVrVRug-Nvq20EjhwQTQ0Hh9umY=.da0ca27f-4093-4ab2-895a-ab62cb5b06ca@github.com>

On Mon, 26 Jun 2023 21:21:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> A trivial fix to correct the expected result to be `Inner[].class`.   I missed the rerun of the test to verify the last-minute edit to the test by JDK-8310242.

Thumbs up. This is a trivial fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14667#issuecomment-1608283430

From mchung at openjdk.org  Mon Jun 26 21:42:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 21:42:03 GMT
Subject: RFR: JDK-8310814: Clarify the targetName parameter of
 Lookup::findClass
Message-ID: <4vRzMGX2j9h8rKnHa0tPrU8CKgJxD8gkETl56W5mW28=.91aae64d-1041-4e1c-99bd-97d7574be3b1@github.com>

This PR updates the spec of `Lookup::findClass` to reflect the current behavior that requires a binary name or a string representing an array class in the form as returned by `Class::getName`.    

`test/jdk/java/lang/invoke/accessClassAndFindClass/TestFindClass.java` already covers the test cases of a nested class and an array class.

-------------

Commit messages:
 - JDK-8310833: Clarify the targetName parameter of Lookup::findClass
 - JDK-8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242

Changes: https://git.openjdk.org/jdk/pull/14668/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14668&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310814
  Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14668/head:pull/14668

PR: https://git.openjdk.org/jdk/pull/14668

From liach at openjdk.org  Mon Jun 26 22:01:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:01:12 GMT
Subject: [jdk21] RFR: 8310242: Clarify the name parameter to Class::forName
In-Reply-To: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
References: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
Message-ID: <YnRb7LJ8moOmWcCSQ7sFq_eoLSvV-xjdYiYzHJvoZHQ=.eacd328e-46ed-41d4-853e-b688a88d650e@github.com>

On Mon, 26 Jun 2023 20:25:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7db2f087](https://github.com/openjdk/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 26 Jun 2023 and was reviewed by Roger Riggs, Chen Liang, Alan Bateman and David Holmes.
> 
> Thanks!

test/jdk/java/lang/Class/forName/ForNameNames.java line 46:

> 44:                 Arguments.of("[Ljava.lang.String;", String[].class),
> 45:                 Arguments.of("ForNameNames$Inner", Inner.class),
> 46:                 Arguments.of("[LForNameNames$Inner;", Inner.class),

JDK-8310922 needs to be backported too.

-------------

PR Review Comment: https://git.openjdk.org/jdk21/pull/65#discussion_r1242860599

From liach at openjdk.org  Mon Jun 26 22:02:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:02:28 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v4]
In-Reply-To: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
Message-ID: <qTN73LOdbAae-SIlS4OlzQ2qyulChqOp3ax5N2P-FXw=.3732956e-fb3c-4278-8a47-091b392cdd57@github.com>

> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.

Chen Liang has updated the pull request incrementally with two additional commits since the last revision:

 - Wrap line that is too long
 - Use single space for single-line if statements
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14642/files
  - new: https://git.openjdk.org/jdk/pull/14642/files/7879c150..9ea36a54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14642&range=02-03

  Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14642/head:pull/14642

PR: https://git.openjdk.org/jdk/pull/14642

From liach at openjdk.org  Mon Jun 26 22:02:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:02:29 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v3]
In-Reply-To: <ML1V-f9QwnyaJANYSYFFGFIfkVrcs5-v8eyOS5FAB-c=.0c7b0797-9eab-4e34-bd18-dce8943438f9@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
 <ML1V-f9QwnyaJANYSYFFGFIfkVrcs5-v8eyOS5FAB-c=.0c7b0797-9eab-4e34-bd18-dce8943438f9@github.com>
Message-ID: <HwiS-eAAjeX9lNU26bEQPo7AsdKrvCVDHtDEGXdzmpk=.fb81795f-00d2-45c3-b702-205af61ea1b9@github.com>

On Mon, 26 Jun 2023 20:54:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify equals by replacing if with and operators
>
> src/java.base/share/classes/java/lang/invoke/MemberName.java line 995:
> 
>> 993:                 return result;
>> 994:             ReflectiveOperationException ex = result.makeAccessException();
>> 995:             if (ex instanceof IllegalAccessException iae)  throw iae;
> 
> Suggestion:
> 
>             if (ex instanceof IllegalAccessException iae) throw iae;

Don't know why, but sometimes JDK devs leaves 2 spaces for certain breaks (like Joe Darcy tends to leave 2 for sentence breaks in Javadocs). Can anyone explain why? In MemberName in particular, I see a mix of 2 and 1 spaces for single-line if statements, so I will take your suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242852444

From liach at openjdk.org  Mon Jun 26 22:02:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:02:29 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v3]
In-Reply-To: <uyQgpZLmWbNXkO4brurRdRvadvGG7Zv4_Ix7rGEfKb4=.ad214a5c-a85b-4047-a465-7f9522b95e92@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <WaWoYrQjC6tmEt3eZABq6m88gYbn_B7kTunnZNoVEBA=.c573144a-a7a6-4944-9a47-e1be6c3df555@github.com>
 <uyQgpZLmWbNXkO4brurRdRvadvGG7Zv4_Ix7rGEfKb4=.ad214a5c-a85b-4047-a465-7f9522b95e92@github.com>
Message-ID: <AwJ6tEFRmNLP5LpRFLxO_VLPO5bZztPb5jAX-F_6CO0=.a3eb607e-0c4f-468e-a591-591fdf4538aa@github.com>

On Mon, 26 Jun 2023 18:28:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify equals by replacing if with and operators
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 899:
> 
>> 897:             return equals(mt);
>> 898:         }
>> 899:         if (x instanceof ConcurrentWeakInternSet.WeakEntry<?> e && e.get() instanceof MethodType mt) {
> 
> Nit: break this long line into 2.

Done. Thanks for the review and suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14642#discussion_r1242859467

From liach at openjdk.org  Mon Jun 26 22:10:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:10:10 GMT
Subject: Integrated: 8310838: Correct range notations in MethodTypeDesc
 specification
In-Reply-To: <EZOORJXKd32cXdad38BN6oW5LD9sG3HeJaXHQ1VedQA=.b9e27ab0-754c-4dc4-9d4e-f0d9951472b7@github.com>
References: <EZOORJXKd32cXdad38BN6oW5LD9sG3HeJaXHQ1VedQA=.b9e27ab0-754c-4dc4-9d4e-f0d9951472b7@github.com>
Message-ID: <3-sqDe0TWlExwIrAti8A-_R0HI-E63EkhtmUI58_llg=.b19fa63d-99d1-4aaf-bb7c-5ba7829dd990@github.com>

On Sat, 24 Jun 2023 01:07:48 GMT, Chen Liang <liach at openjdk.org> wrote:

> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/constant/MethodTypeDesc.html
> 
> These 3 typos are discovered while browsing the online documentation. It probably doesn't need a CSR for it doesn't change the specification at all.

This pull request has now been integrated.

Changeset: a197ee79
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a197ee797b3580d9f85636522587d3f6418dff6a
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8310838: Correct range notations in MethodTypeDesc specification

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14635

From mchung at openjdk.org  Mon Jun 26 22:16:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 22:16:03 GMT
Subject: [jdk21] RFR: 8310242: Clarify the name parameter to Class::forName
In-Reply-To: <YnRb7LJ8moOmWcCSQ7sFq_eoLSvV-xjdYiYzHJvoZHQ=.eacd328e-46ed-41d4-853e-b688a88d650e@github.com>
References: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
 <YnRb7LJ8moOmWcCSQ7sFq_eoLSvV-xjdYiYzHJvoZHQ=.eacd328e-46ed-41d4-853e-b688a88d650e@github.com>
Message-ID: <KO3hjijynMqcXal3cFy9BGJq4UzHNZmWEB87hUDo8ik=.e60a43bf-36ed-4637-91d0-2bb3ff9b2519@github.com>

On Mon, 26 Jun 2023 21:58:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [7db2f087](https://github.com/openjdk/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Mandy Chung on 26 Jun 2023 and was reviewed by Roger Riggs, Chen Liang, Alan Bateman and David Holmes.
>> 
>> Thanks!
>
> test/jdk/java/lang/Class/forName/ForNameNames.java line 46:
> 
>> 44:                 Arguments.of("[Ljava.lang.String;", String[].class),
>> 45:                 Arguments.of("ForNameNames$Inner", Inner.class),
>> 46:                 Arguments.of("[LForNameNames$Inner;", Inner.class),
> 
> JDK-8310922 needs to be backported too.

Yup... working on it.

-------------

PR Review Comment: https://git.openjdk.org/jdk21/pull/65#discussion_r1242869120

From liach at openjdk.org  Mon Jun 26 22:23:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:23:28 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v8]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <NA15MBej485ep184APamzx-PZQDOrCK_pgyvxdjk6qU=.718519a6-78a5-4859-8015-f5f75206a8a7@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Reword of the distinct-class-same-descriptor note

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/be3e8cd3..96b142e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=06-07

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Mon Jun 26 22:23:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:23:30 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
 <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
Message-ID: <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>

On Mon, 26 Jun 2023 18:53:42 GMT, Mandy Chung <mchung 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 ten additional commits since the last revision:
>> 
>>  - Review and updates for 8310242
>>  - Merge branch 'master' into fix/descstring-spec
>>  - Update the note for getName
>>  - Convert the note in fromDescriptorString to apiNote
>>  - Address the other two review comments
>>  - Merge branch 'fix/descstring-spec' of https://github.com/liachmodded/jdk into fix/descstring-spec
>>  - Update src/java.base/share/classes/java/lang/Class.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Merge branch 'master' into fix/descstring-spec
>>  - 8309819: Fix specification about descriptor inverses in Class and MethodTypeDesc
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1229:
> 
>> 1227:      *
>> 1228:      * @apiNote
>> 1229:      * This is not a strict inverse of {@link #fromMethodDescriptorString
> 
> Re-reading this, I think this api note reads fine.   OTOH I find a little confusing how you rephrased it.  "A method type produced by changing a component class object to...".   I understand you tried to make it crystal clear two method types may have the identical descriptor strings even if its parameter type or return type are distinct Class objects.   
> 
> I think the original version is clear enough and less lengthy.

* Two distinct classes which share a common name but have different class loaders
     * produce identical component descriptors in descriptor strings.

Does this sound good? This also addresses alan's wording concerns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242871605

From jjg at openjdk.org  Mon Jun 26 22:27:09 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 26 Jun 2023 22:27:09 GMT
Subject: Integrated: JDK-8310909: java.io.InvalidObjectException has redundant
 `@since` tag
In-Reply-To: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
References: <RNBGmuWXbUJLvSUsHnOVLBNQNxLf_NVevp9Xxt2p9Rs=.23e2646c-2e99-4b5b-882c-2ae1015eae6a@github.com>
Message-ID: <LTMzH9a-CMsBbTRfWbg0xm8IsVlmsZWzo6azIQCfYkI=.ad033c4c-89ab-455d-8671-e828c54d616c@github.com>

On Mon, 26 Jun 2023 18:32:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial update to remove a redundant `@since` tag.

This pull request has now been integrated.

Changeset: 46add3f8
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46add3f8e3ea5d08130e0342390f998979c2a14e
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8310909: java.io.InvalidObjectException has redundant `@since` tag

Reviewed-by: lancea, naoto, bpb, darcy, iris

-------------

PR: https://git.openjdk.org/jdk/pull/14662

From mchung at openjdk.org  Mon Jun 26 22:33:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 22:33:10 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
 <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
 <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>
Message-ID: <syzLD5nzy1Bqin0Gkt98Bs73vse7anYQyfsU6uvhAA4=.a151d6c0-6614-46be-8b39-ea58cdf527e7@github.com>

On Mon, 26 Jun 2023 22:17:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 1229:
>> 
>>> 1227:      *
>>> 1228:      * @apiNote
>>> 1229:      * This is not a strict inverse of {@link #fromMethodDescriptorString
>> 
>> Re-reading this, I think this api note reads fine.   OTOH I find a little confusing how you rephrased it.  "A method type produced by changing a component class object to...".   I understand you tried to make it crystal clear two method types may have the identical descriptor strings even if its parameter type or return type are distinct Class objects.   
>> 
>> I think the original version is clear enough and less lengthy.
>
> * Two distinct classes which share a common name but have different class loaders
>      * produce identical component descriptors in descriptor strings.
> 
> Does this sound good? This also addresses alan's wording concerns.

Why can't just say "identical descriptor strings"?   It's unclear what "component descriptor" is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242877851

From liach at openjdk.org  Mon Jun 26 22:33:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:33:10 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <syzLD5nzy1Bqin0Gkt98Bs73vse7anYQyfsU6uvhAA4=.a151d6c0-6614-46be-8b39-ea58cdf527e7@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
 <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
 <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>
 <syzLD5nzy1Bqin0Gkt98Bs73vse7anYQyfsU6uvhAA4=.a151d6c0-6614-46be-8b39-ea58cdf527e7@github.com>
Message-ID: <EhQ2_aZuRS7VPxl37PXohAPnEuw0r9zB--htsea9N48=.b97c35d4-1ae4-446b-8baf-16248678350e@github.com>

On Mon, 26 Jun 2023 22:27:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> * Two distinct classes which share a common name but have different class loaders
>>      * produce identical component descriptors in descriptor strings.
>> 
>> Does this sound good? This also addresses alan's wording concerns.
>
> Why can't just say "identical descriptor strings"?   It's unclear what "component descriptor" is.

"component descriptor" tried to refer to both parameter types and return type descriptors. How about "produce identical class descriptors in method descriptors?"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242879013

From mchung at openjdk.org  Mon Jun 26 22:36:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 22:36:14 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <EhQ2_aZuRS7VPxl37PXohAPnEuw0r9zB--htsea9N48=.b97c35d4-1ae4-446b-8baf-16248678350e@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
 <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
 <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>
 <syzLD5nzy1Bqin0Gkt98Bs73vse7anYQyfsU6uvhAA4=.a151d6c0-6614-46be-8b39-ea58cdf527e7@github.com>
 <EhQ2_aZuRS7VPxl37PXohAPnEuw0r9zB--htsea9N48=.b97c35d4-1ae4-446b-8baf-16248678350e@github.com>
Message-ID: <1uuAw9wugPssRCZAZg_HjrFLIdFtl6YuXLkmDrIKHQo=.cf8cedb0-7163-4b51-a4e4-02f1a7a3fd29@github.com>

On Mon, 26 Jun 2023 22:30:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Why can't just say "identical descriptor strings"?   It's unclear what "component descriptor" is.
>
> "component descriptor" tried to refer to both parameter types and return type descriptors. How about "produce identical class descriptors in method descriptors?"

`MethodType::descriptorString` refers to method descriptor and `Class::descriptorString` refers to class descriptor.   I don't think it helps to say "produce identical class descriptors in method descriptors".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242882072

From liach at openjdk.org  Mon Jun 26 22:36:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:36:31 GMT
Subject: [jdk21] RFR: 8310838: Correct range notations in MethodTypeDesc
 specification
Message-ID: <IVN1Fh7512My1ogwGPz_oHzD9X8tb6C52VmVICYCsaw=.433f1bd4-7a3e-46e3-be7e-7489bd82c87d@github.com>

Hi all,

This pull request contains a backport of commit [a197ee79](https://github.com/openjdk/jdk/commit/a197ee797b3580d9f85636522587d3f6418dff6a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. This is a doc-only typo fix.

The commit being backported was authored by Chen Liang on 26 Jun 2023 and was reviewed by Mandy Chung.

Thanks!

-------------

Commit messages:
 - Backport a197ee797b3580d9f85636522587d3f6418dff6a

Changes: https://git.openjdk.org/jdk21/pull/66/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=66&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310838
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk21/pull/66.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/66/head:pull/66

PR: https://git.openjdk.org/jdk21/pull/66

From liach at openjdk.org  Mon Jun 26 22:39:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 22:39:09 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <1uuAw9wugPssRCZAZg_HjrFLIdFtl6YuXLkmDrIKHQo=.cf8cedb0-7163-4b51-a4e4-02f1a7a3fd29@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
 <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
 <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>
 <syzLD5nzy1Bqin0Gkt98Bs73vse7anYQyfsU6uvhAA4=.a151d6c0-6614-46be-8b39-ea58cdf527e7@github.com>
 <EhQ2_aZuRS7VPxl37PXohAPnEuw0r9zB--htsea9N48=.b97c35d4-1ae4-446b-8baf-16248678350e@github.com>
 <1uuAw9wugPssRCZAZg_HjrFLIdFtl6YuXLkmDrIKHQo=.cf8cedb0-7163-4b51-a4e4-02f1a7a3fd29@github.com>
Message-ID: <3Z3DYABGeTReZFPnoDf0eR5MSXsB0cDAT1XRcH2rohg=.02b2c1d0-f8d8-4023-8b98-82d427d00baa@github.com>

On Mon, 26 Jun 2023 22:33:35 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> "component descriptor" tried to refer to both parameter types and return type descriptors. How about "produce identical class descriptors in method descriptors?"
>
> `MethodType::descriptorString` refers to method descriptor and `Class::descriptorString` refers to class descriptor.   I don't think it helps to say "produce identical class descriptors in method descriptors".

I think we can put it simple:
"Two distinct classes which share a common name but have different class loaders cannot be distinguished in descriptor strings"
which stands for both class and method descriptors. How does this sound?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1242883757

From duke at openjdk.org  Mon Jun 26 22:46:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 26 Jun 2023 22:46:11 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <YOVNkMQXkZsETUX-b9tBIzEVoIYP7QhOq7d-9GX6mZY=.4be362a7-dcc5-4db9-ac76-5ad61f5671e9@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

should i revert to this version?
https://github.com/openjdk/jdk/pull/14578/files/17a9f16976488889907ec383ab76e2048dbc576b

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1608418246

From ascarpino at openjdk.org  Mon Jun 26 22:52:18 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Mon, 26 Jun 2023 22:52:18 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2]
In-Reply-To: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
Message-ID: <velqdRuSajS8ikM1rXwxMiZvQHuIJRZjYt9nq5v1Qo8=.ef4ed20e-97a9-43c4-a905-b28cb1bb5ac5@github.com>

> Hi,
> 
> I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.
> 
> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  update for review:  changed test, removed commented out code in module, fixed switch statement, added --limit-modules

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14457/files
  - new: https://git.openjdk.org/jdk/pull/14457/files/85870520..32b4cee1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14457&range=00-01

  Stats: 34 lines in 5 files changed: 13 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14457.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14457/head:pull/14457

PR: https://git.openjdk.org/jdk/pull/14457

From liach at openjdk.org  Mon Jun 26 23:01:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 Jun 2023 23:01:20 GMT
Subject: RFR: 8307575: Migrate the serialization constructor accessors to
 Method Handles [v3]
In-Reply-To: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
References: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
Message-ID: <aumHGNbWMv-bXUdnrdG11sKr_TgbvmopuwqQ_J6DHNs=.8e1ce7c2-af23-46d2-90ac-cc24504fb026@github.com>

> Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation.
> 
> Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects.
> 
> #1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation.

Chen Liang 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 explore/mh-serial-constructor
 - Remove invalid assertion (via sun.reflect.ReflectionFactory)
 - 8307575: Migrate the serialization constructor accessors to Method Handles

-------------

Changes: https://git.openjdk.org/jdk/pull/13853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13853&range=02
  Stats: 124 lines in 8 files changed: 52 ins; 40 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/13853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13853/head:pull/13853

PR: https://git.openjdk.org/jdk/pull/13853

From mchung at openjdk.org  Mon Jun 26 23:02:29 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 23:02:29 GMT
Subject: [jdk21] RFR: 8310242: Clarify the name parameter to Class::forName
 [v2]
In-Reply-To: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
References: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
Message-ID: <z1LYqgnhR-hFF4xxa_BKnwuPcrUhLRhXlIPV00Ji2mo=.2fe6c7e6-28f2-4acd-a46b-3e16aa655b8b@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [7db2f087](https://github.com/openjdk/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 26 Jun 2023 and was reviewed by Roger Riggs, Chen Liang, Alan Bateman and David Holmes.
> 
> Thanks!

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242

-------------

Changes:
  - all: https://git.openjdk.org/jdk21/pull/65/files
  - new: https://git.openjdk.org/jdk21/pull/65/files/a351795c..7bee67e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk21&pr=65&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk21&pr=65&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/65.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/65/head:pull/65

PR: https://git.openjdk.org/jdk21/pull/65

From mchung at openjdk.org  Mon Jun 26 23:13:19 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 26 Jun 2023 23:13:19 GMT
Subject: RFR: JDK-8310814: Clarify the targetName parameter of
 Lookup::findClass [v2]
In-Reply-To: <4vRzMGX2j9h8rKnHa0tPrU8CKgJxD8gkETl56W5mW28=.91aae64d-1041-4e1c-99bd-97d7574be3b1@github.com>
References: <4vRzMGX2j9h8rKnHa0tPrU8CKgJxD8gkETl56W5mW28=.91aae64d-1041-4e1c-99bd-97d7574be3b1@github.com>
Message-ID: <G4xMfIr9T7jCfDqWXjsQfD6Bo6fPuBE-pHpx9KKnh94=.323c6e31-1f7e-4a14-ae92-17c412aeeae2@github.com>

> This PR updates the spec of `Lookup::findClass` to reflect the current behavior that requires a binary name or a string representing an array class in the form as returned by `Class::getName`.    
> 
> `test/jdk/java/lang/invoke/accessClassAndFindClass/TestFindClass.java` already covers the test cases of a nested class and an array class.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8310833: Clarify the targetName parameter of Lookup::findClass

-------------

Changes: https://git.openjdk.org/jdk/pull/14668/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14668&range=01
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14668.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14668/head:pull/14668

PR: https://git.openjdk.org/jdk/pull/14668

From duke at openjdk.org  Mon Jun 26 23:51:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 26 Jun 2023 23:51:11 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <AEG6TE15i1GB6isicig_X1AOpFeGTi2LfYjEEPnuwWI=.d0162a7c-9aea-4ef4-af2b-73f78f379dc9@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

with JVMOpts '-XX:-CompactStrings', i tested on the MacBookPro M1 Max and found that the current version is faster than the baseline version.


Benchmark                Mode  Cnt      Score      Error   Units (PR current version 6b61a715) 
UUIDUtilsBenchmark.jdk  thrpt    5  89601.097 ? 1879.659  ops/ms

Benchmark                Mode  Cnt      Score     Error   Units (baseline)
UUIDUtilsBenchmark.jdk  thrpt    5  71783.920 ? 170.914  ops/ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1608475831

From dholmes at openjdk.org  Tue Jun 27 00:12:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 27 Jun 2023 00:12:03 GMT
Subject: [jdk21] RFR: 8310242: Clarify the name parameter to Class::forName
 [v2]
In-Reply-To: <z1LYqgnhR-hFF4xxa_BKnwuPcrUhLRhXlIPV00Ji2mo=.2fe6c7e6-28f2-4acd-a46b-3e16aa655b8b@github.com>
References: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
 <z1LYqgnhR-hFF4xxa_BKnwuPcrUhLRhXlIPV00Ji2mo=.2fe6c7e6-28f2-4acd-a46b-3e16aa655b8b@github.com>
Message-ID: <R41f1rzzvyC1PrMyOh8M43IyzrIJ5x5hhL6ldA6YV04=.347edede-ecde-47df-b16e-5b34f13baf5e@github.com>

On Mon, 26 Jun 2023 23:02:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [7db2f087](https://github.com/openjdk/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Mandy Chung on 26 Jun 2023 and was reviewed by Roger Riggs, Chen Liang, Alan Bateman and David Holmes.
>> 
>> Thanks!
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242

Looks good. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/65#pullrequestreview-1499727754

From mchung at openjdk.org  Tue Jun 27 02:03:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Jun 2023 02:03:15 GMT
Subject: [jdk21] Integrated: 8310242: Clarify the name parameter to
 Class::forName
In-Reply-To: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
References: <FaZpC9rfe91ajYknaa2fStCaN6x1ohzX_syGewltUo8=.257ecfa0-cfba-4916-9e48-4648c8886ded@github.com>
Message-ID: <eaSv2ax8QbArilFxokHzBTLTUJ9HYF75-TQLW8-QDlc=.90aedeba-f975-431d-b95b-aedba313ea62@github.com>

On Mon, 26 Jun 2023 20:25:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7db2f087](https://github.com/openjdk/jdk/commit/7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Mandy Chung on 26 Jun 2023 and was reviewed by Roger Riggs, Chen Liang, Alan Bateman and David Holmes.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6a4552c9
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6a4552c9a86dd925d267e1de238f545b5606624a
Stats:     139 lines in 2 files changed: 107 ins; 1 del; 31 mod

8310242: Clarify the name parameter to Class::forName
8310922: java/lang/Class/forName/ForNameNames.java fails after being added by JDK-8310242

Reviewed-by: dholmes
Backport-of: 7db2f08756b0aa1d79cdd2356ed42aa5ab8bc58b

-------------

PR: https://git.openjdk.org/jdk21/pull/65

From duke at openjdk.org  Tue Jun 27 02:08:23 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 02:08:23 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <4OyQWuoFUYXYXaXAqHy3g8h1--noOIyrvuKwPyWMiPc=.816de382-06b5-46d8-bf1a-50892975b496@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

the last implementation (commit id 6b61a715) is the best performant whether CompactStrings is true or false.

when CompactStrings is false, the improvement brought by using ByteArray is greater than the overhead of StringLatin1.inflate. the benchmark result above also confirms this.

because the implemented code is in UUID.toString, there is no need to intrude into the code of java/lang/Long.java, which is clearer and easier to maintain.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1608595082

From naoto at openjdk.org  Tue Jun 27 03:39:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 03:39:30 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash [v2]
In-Reply-To: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
Message-ID: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>

> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting a review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14620/files
  - new: https://git.openjdk.org/jdk/pull/14620/files/f105d13a..76182881

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14620&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14620&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14620/head:pull/14620

PR: https://git.openjdk.org/jdk/pull/14620

From liach at openjdk.org  Tue Jun 27 03:43:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 03:43:47 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v12]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <tYpCtmpp52I-P3J_rzxLikHq8tGdA7iU9bwz2B2CnyY=.b5feb3df-384c-451a-9a6c-6ebe37de457e@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> Benchmark                                            Mode  Cnt   Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Fix bugs
 - Merge branch 'master' into lazy-static-varhandle
 - Move initialization barrier to getMethodHandle(Uncached)
 - Merge branch 'master' into lazy-static-varhandle
 - Remove meaningless target calls and clear outdated cache as needed
 - Split ensureInitialized
 - Merge branch 'master' into lazy-static-varhandle
 - Significantly improve Lazy VH initial call performance
 - Rename asDirect to target
 - Merge branch 'master' into lazy-static-varhandle
 - ... and 15 more: https://git.openjdk.org/jdk/compare/87e6fab2...0ac094b8

-------------

Changes: https://git.openjdk.org/jdk/pull/13821/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=11
  Stats: 789 lines in 11 files changed: 613 ins; 16 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From darcy at openjdk.org  Tue Jun 27 03:52:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 03:52:03 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <4GjeSZT6JGVJhAW1-RR6FUqjg5-nN9SCFrbzDzWCfu4=.2b3867c4-3b6a-4c1b-b59b-496ee485e23d@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1499892443

From liach at openjdk.org  Tue Jun 27 04:58:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 04:58:04 GMT
Subject: RFR: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect [v4]
In-Reply-To: <qTN73LOdbAae-SIlS4OlzQ2qyulChqOp3ax5N2P-FXw=.3732956e-fb3c-4278-8a47-091b392cdd57@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
 <qTN73LOdbAae-SIlS4OlzQ2qyulChqOp3ax5N2P-FXw=.3732956e-fb3c-4278-8a47-091b392cdd57@github.com>
Message-ID: <ZX891_-jOOypY9CTAwLWXuh2ZMsyXbpWkm18aOEk5QE=.03895b91-4c6c-4076-8838-fcf76c72b79b@github.com>

On Mon, 26 Jun 2023 22:02:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.
>
> Chen Liang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Wrap line that is too long
>  - Use single space for single-line if statements
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Tests pass, integrating. Thank you for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14642#issuecomment-1608795933

From iris at openjdk.org  Tue Jun 27 05:08:03 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 27 Jun 2023 05:08:03 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <pSc_Q0Eed2-juY2P_cmHhxwXnG5GSH-5xxX3LfZQ7gY=.45464b92-ca84-402b-8b5d-7efabf2b9761@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1499946634

From liach at openjdk.org  Tue Jun 27 05:08:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 05:08:26 GMT
Subject: RFR: 8308899: Introduce Classfile context and improve Classfile
 options [v26]
In-Reply-To: <-cKMdI--Y3dO60Pyt4xnqkpal7yHUyTflvTi18f8uh0=.2100aac0-9d5e-42af-91c9-692558279f3b@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
 <-cKMdI--Y3dO60Pyt4xnqkpal7yHUyTflvTi18f8uh0=.2100aac0-9d5e-42af-91c9-692558279f3b@github.com>
Message-ID: <mn-gFz_kkL8AnACy1nLkW52I6XqwhfRhuyjqZs-q8lo=.92267d53-4012-4dc9-8230-dbcb0f836127@github.com>

On Mon, 26 Jun 2023 16:47:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Classfile API javadoc make patch"
>   
>   This reverts commit dad094d1686e4e16ccd379c091db258bec0087c5.

Congrats, now I can update many of my patches that depend on this API update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1608804156

From asotona at openjdk.org  Tue Jun 27 05:08:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 27 Jun 2023 05:08:29 GMT
Subject: Integrated: 8308899: Introduce Classfile context and improve Classfile
 options
In-Reply-To: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
References: <FQ37WWRat0n1wB0ml2rRZG2AAL8cZVwtf_3Ma-ZTusg=.a35f9880-ff9b-421e-827e-bb419158be86@github.com>
Message-ID: <6oAP6R1nWRyObRhl6iR25H7pnaynqLN3zA6FrSGHSjk=.ec72c9fd-be2c-46cb-a130-b24da9971e43@github.com>

On Fri, 26 May 2023 14:56:57 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile context object and multi-state options have been discussed at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
> This patch implements the proposed changes in Classfile API and fixes all affected code across JDK sources and tests.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 990e3a70
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/990e3a700dce3441bd9506ca571c1790e57849a9
Stats:     1863 lines in 113 files changed: 669 ins; 257 del; 937 mod

8308899: Introduce Classfile context and improve Classfile options
8306650: Improve control of stack maps generation in Classfile API
8308646: Typo in ConstantValueAttribute

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14180

From jpai at openjdk.org  Tue Jun 27 06:25:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jun 2023 06:25:03 GMT
Subject: RFR: 8310914: Remove 2 malformed java/foreign ProblemList entries
In-Reply-To: <W4FJ2bF5UFs5e9HQ_N8Y7DY1PyKE4-Yj5-66UqVMjt8=.332cc00e-2a81-4074-a1b9-f47871769991@github.com>
References: <W4FJ2bF5UFs5e9HQ_N8Y7DY1PyKE4-Yj5-66UqVMjt8=.332cc00e-2a81-4074-a1b9-f47871769991@github.com>
Message-ID: <CLsdTJEBH9ocsASz8Je1tpD05mnBd8ofCtBMUdc5R0w=.5b6814f6-2fe0-4154-bd28-1bf2620226b4@github.com>

On Mon, 26 Jun 2023 19:33:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Remove 2 malformed problem list entries. These entries are considered malformed according to [1] since they are missing a bug number. 
> 
> The `java/foreign/callarranger/TestAarch64CallArranger.java` test was removed, and the `java/foreign/TestLargeSegmentCopy.java` disables x86 in the jtreg test header using `@requires sun.arch.data.model == "64"`, so neither of these entries are needed.
> 
> Testing: `jdk_foreign` test suite (which contains these tests)
> 
> [1]: https://openjdk.org/jtreg/faq.html#what-is-a-problemlist.txt-file

Marked as reviewed by jpai (Reviewer).

Hello Jorn,

> 
> The `java/foreign/callarranger/TestAarch64CallArranger.java` test was removed,

It looks like this test is still present in mainline https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/callarranger/TestLinuxAArch64CallArranger.java but like `java/foreign/TestLargeSegmentCopy.java` it too has a `@requires sun.arch.data.model == "64"`, so this proposed change to remove these entries from the problem listing looks OK to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14664#pullrequestreview-1500023684
PR Comment: https://git.openjdk.org/jdk/pull/14664#issuecomment-1608868413

From jpai at openjdk.org  Tue Jun 27 06:30:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jun 2023 06:30:23 GMT
Subject: RFR: 8296477: Foreign linker implementation update following JEP
 434 [v2]
In-Reply-To: <0zmCETHcp1YHJ7K6BvmpLz7fA9a9qlPdCCEDFFt1WPU=.1c1b9ef6-fa14-45ad-a71d-bf439498a691@github.com>
References: <CGd4JSefJvfEVkZEfORzthEIeV53kLk_UkZHAhJGrQ0=.7741b5f2-2227-4017-8164-d54fb9d30d10@github.com>
 <dMQ238rubrgCcyRv-456L2yibOvwrz1gWFPUOQTM5TQ=.31dcad26-a466-4806-ab72-33eb1c89a6ef@github.com>
 <i6cFFRmj8BY5ykF4ROioLuh1J0kFrKTRgyHf4fIFeSM=.aeeba4fe-3efa-4b3d-b31e-3f428b0c33f5@github.com>
 <adPNJWEXLNY6LPaqX2N0eeiYUQDyRlp4rfJBqZYWoNI=.5ee36196-7bb8-4e28-adde-3cdd09eab781@github.com>
 <-hS98wCfpghUkzWuyf0MzhpIpCIjOiDDitZ39kx4aeU=.c2dbc3eb-a649-489e-b0cb-eb14d7f55dbf@github.com>
 <0zmCETHcp1YHJ7K6BvmpLz7fA9a9qlPdCCEDFFt1WPU=.1c1b9ef6-fa14-45ad-a71d-bf439498a691@github.com>
Message-ID: <FDToo7IE2UHkEiRDQMiy5I_PSzffLit0_eBFV9WMaw8=.a2555faa-0f38-47ec-86dc-9b0ed36a2123@github.com>

On Mon, 26 Jun 2023 19:33:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hello Jorn,
>> 
>>> Adding them to the problem list doesn't seem to make the failures go away in GHA at least.
>> 
>> It appears that these 2 problem listed lines are malformed (it's missing a bug id in each of these lines https://openjdk.org/guide/#problemlisting-jtreg-tests) Maybe that's why those tests didn't get problem listed in the GHA runs?
>> 
>> I found a more detailed explanation of the syntax here https://openjdk.org/jtreg/faq.html#what-is-a-problemlist.txt-file
>
> Sorry, I didn't notice this comment. I think it didn't show up for me on GitHub since I had resolved the conversation already.
> 
> I've created: https://github.com/openjdk/jdk/pull/14664 to fix this.

Thank you for addressing this Jorn. I agree about the GitHub UI - in fact, I received a notification in GitHub today that this PR was updated with a comment and I had an extremely hard time to locate this specific comment. It's only when I went back to the JDK mailing list that I could get the exact link to this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/11019#discussion_r1243201428

From jpai at openjdk.org  Tue Jun 27 07:03:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 27 Jun 2023 07:03:03 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond
In-Reply-To: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
Message-ID: <IeHoCnfinrw66rgwCuSCKxQ5zYSX9lrRtS7PI2_svMM=.271797cf-35eb-4505-8e12-ce873e1a678a@github.com>

On Mon, 26 Jun 2023 17:31:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `/ by zero` exception with tick durations less than a millisecond.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14657#pullrequestreview-1500078350

From alanb at openjdk.org  Tue Jun 27 07:26:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 07:26:04 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond
In-Reply-To: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
Message-ID: <G_Ffcmy5x7IgHxMb-8v1YUDBJQ6D3f8qCdTGSSJI-iU=.9ef1448d-7133-4278-8b82-28aeec8cf80d@github.com>

On Mon, 26 Jun 2023 17:31:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `/ by zero` exception with tick durations less than a millisecond.

test/jdk/java/time/test/java/time/TestClock_Tick.java line 77:

> 75:  * Test tick clock.
> 76:  *
> 77:  * @bug 8310232

Did you mean the put the "@bug" here? If you did then I assume you'll need to add the original bug ID too as TestClock_Tick wasn't created for 8310232.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14657#discussion_r1243256353

From duke at openjdk.org  Tue Jun 27 07:45:34 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 07:45:34 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
Message-ID: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>

> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
> 
> Reasons:
> 
> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.

Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into latin1-no-repl
 - Merge branch 'openjdk:master' into latin1-no-repl
 - update javadoc
 - clean newStringNoRepl1
 - clean newStringNoRepl1
 - Rename jla to JLA
 - Create new method JavaLangAccess::newStringLatin1NoRepl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14655/files
  - new: https://git.openjdk.org/jdk/pull/14655/files/9958348b..512029d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14655&range=02-03

  Stats: 6443 lines in 195 files changed: 2377 ins; 2165 del; 1901 mod
  Patch: https://git.openjdk.org/jdk/pull/14655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14655/head:pull/14655

PR: https://git.openjdk.org/jdk/pull/14655

From duke at openjdk.org  Tue Jun 27 07:45:51 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 07:45:51 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v3]
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <tLbna9f_IinIgSSZV48EQKrjNebF4Bb2Gj7TAvv1hZM=.3ba86801-efc2-4e5b-b3ed-d9c0a2904c88@github.com>

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

Glavo has updated the pull request with a new target base 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 tr-locale
 - Merge branch 'openjdk:master' into tr-locale
 - list mode of jmod and jimage cannot be used normally in turkish locale

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12281/files
  - new: https://git.openjdk.org/jdk/pull/12281/files/ae8219b6..39102397

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12281&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12281&range=01-02

  Stats: 6443 lines in 195 files changed: 2377 ins; 2165 del; 1901 mod
  Patch: https://git.openjdk.org/jdk/pull/12281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12281/head:pull/12281

PR: https://git.openjdk.org/jdk/pull/12281

From duke at openjdk.org  Tue Jun 27 07:45:53 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 07:45:53 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v8]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <yEcZplJhOELbj7VVaftG5NI6edlnTHLiz02qpR6Cxx4=.b98ec0a8-4acd-44b2-bc13-28e2e142edcc@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request with a new target base 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 'openjdk:master' into unsafe
 - Merge branch 'openjdk:master' into unsafe
 - delete incorrect comments
 - delete extraneous whitespace
 - add javadoc
 - delete extraneous whitespace
 - fix test
 - update tests
 - use Preconditions.AIOOBE_FORMATTER
 - delete extraneous whitespace
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9e314a37...609170c0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/2b5a4b01..609170c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=06-07

  Stats: 6443 lines in 195 files changed: 2377 ins; 2165 del; 1901 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From duke at openjdk.org  Tue Jun 27 07:46:30 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 07:46:30 GMT
Subject: RFR: 8310837: Use ByteArrayLittleEndian in java.util.zip [v3]
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <yNkMDLe1g_1VwGnNouv6wYrQpo18IutYn1UTdEIqhNQ=.6dbab0e7-e4aa-4e7b-bba9-c631f17ad5fd@github.com>

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

Glavo has updated the pull request with a new target base 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 zip-utils
 - Merge branch 'openjdk:master' into zip-utils
 - use ByteArrayLittleEndian in ZipUtils

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14632/files
  - new: https://git.openjdk.org/jdk/pull/14632/files/6ba44e49..c14b9620

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14632&range=01-02

  Stats: 6443 lines in 195 files changed: 2377 ins; 2165 del; 1901 mod
  Patch: https://git.openjdk.org/jdk/pull/14632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14632/head:pull/14632

PR: https://git.openjdk.org/jdk/pull/14632

From mdoerr at openjdk.org  Tue Jun 27 07:50:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 27 Jun 2023 07:50:09 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v7]
In-Reply-To: <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>
Message-ID: <Qj4mwnR71hE09cWncF1Vxa0wYddH7wsVesEVZXPcrso=.20b15027-bcaa-4c74-a145-b90a8335167b@github.com>

On Mon, 26 Jun 2023 14:57:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by mdoerr (Reviewer).

Still good on PPC64.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1500166353
PR Comment: https://git.openjdk.org/jdk/pull/14063#issuecomment-1608971576

From thartmann at openjdk.org  Tue Jun 27 07:53:26 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 27 Jun 2023 07:53:26 GMT
Subject: [jdk21] RFR: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
Message-ID: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>

Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459). Applies cleanly.

Thanks,
Tobias

-------------

Commit messages:
 - 8310459: [BACKOUT] 8304450: [vectorapi] Refactor VectorShuffle implementation

Changes: https://git.openjdk.org/jdk21/pull/68/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=68&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310459
  Stats: 3895 lines in 64 files changed: 1169 ins; 1819 del; 907 mod
  Patch: https://git.openjdk.org/jdk21/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/68/head:pull/68

PR: https://git.openjdk.org/jdk21/pull/68

From alanb at openjdk.org  Tue Jun 27 07:57:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 07:57:06 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v3]
In-Reply-To: <tLbna9f_IinIgSSZV48EQKrjNebF4Bb2Gj7TAvv1hZM=.3ba86801-efc2-4e5b-b3ed-d9c0a2904c88@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <tLbna9f_IinIgSSZV48EQKrjNebF4Bb2Gj7TAvv1hZM=.3ba86801-efc2-4e5b-b3ed-d9c0a2904c88@github.com>
Message-ID: <2ypxk5wI16K0ypzTNu5WWOdNutcOhind1ab7Tl0rCo0=.25dba10e-3118-4340-85fb-e4205ca9e3ba@github.com>

On Tue, 27 Jun 2023 07:45:51 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> Glavo has updated the pull request with a new target base 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 tr-locale
>  - Merge branch 'openjdk:master' into tr-locale
>  - list mode of jmod and jimage cannot be used normally in turkish locale

Did you check the use of toUpperCase(Locale.ENGLISH) in JlinkTask.java and JImageTask.java to see if they are correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1608981430

From duke at openjdk.org  Tue Jun 27 08:04:04 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 08:04:04 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <RFH_sm-M9Szi2vMZ-w1jnSoPou3NFb8nAWEtt3AbRwk=.bb36db75-ade0-4bd8-a7d8-46502179c9c9@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>
 <eniFkv7itdCMUxDq9LYC-h4uDRlew67VWu3wiB4JzJQ=.efbfc32e-a54a-4d72-bdcc-b719e679fe71@github.com>
 <RFH_sm-M9Szi2vMZ-w1jnSoPou3NFb8nAWEtt3AbRwk=.bb36db75-ade0-4bd8-a7d8-46502179c9c9@github.com>
Message-ID: <I9eBqzYrxF4xv_jc8sEqkLMN3xpPvlgN5aIr9S6_8CA=.3d78706c-3cb2-4df9-ba47-1ccc3f276734@github.com>

On Wed, 7 Jun 2023 06:32:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Sounds fine to me and as other have agreed `Locale.ROOT` would be more appropriate. Would you be willing to update this PR to update the few other occurences in some classes (`JImageTask`, `JlinkTask` and `VersionPropsPlugin`) as noted by Mandy and Alan in their comments?

I think in most cases, there is no difference in the effect between `toUpperCase(Locale.ROOT)` and `toUpperCase(Locale.ENGLISH)`.

If you think it is appropriate to replace `Locale.ENGLISH` with `Locale.ROOT` in this PR, I can do so. I believe that compared to `Locale.ENGLISH`, the `Locale.ROOT is more suitable for use in more places.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1608995613

From aturbanov at openjdk.org  Tue Jun 27 08:41:26 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 27 Jun 2023 08:41:26 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted"
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <gK2Uygk3NRPWJegsvyLh1w2RxrNU5td-0Y51dQJitfs=.8aace378-9248-4e48-8b31-27573598020e@github.com>

On Sat, 3 Jun 2023 14:08:02 GMT, Doug Lea <dl at openjdk.org> wrote:

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2717:

> 2715:         this.config = asyncMode ? FIFO : 0;
> 2716:         this.keepAlive = Math.max(unit.toMillis(keepAliveTime), TIMEOUT_SLOP);
> 2717:         int corep = Math.clamp(corePoolSize, p, MAX_CAP);

it it expected that `int corePoolSize` is now unused?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2795:

> 2793:             int n = (qs == null) ? 0 : qs.length;
> 2794:             for (int l = n; l > 0; --l, ++r) {
> 2795:                 int j; WorkQueue q; Thread o; // cancel tasks; interrupt workers

`int j` is unused

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1243352906
PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1243349508

From amitkumar at openjdk.org  Tue Jun 27 09:24:06 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 27 Jun 2023 09:24:06 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v7]
In-Reply-To: <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <8qlNgNsnMNTu7E4E3D3aXTOghXiyRzt5NJSkjIXvt4Y=.b094a08d-ac4d-48e7-8ab2-d6b2d1835e7e@github.com>
Message-ID: <LI_w-tVLo6z3n4Iov9JbErseccVp-Lk-TFF9qAcirP0=.e892a505-ebba-4750-ae4a-732664fa5f59@github.com>

On Mon, 26 Jun 2023 14:57:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Looks good for s390.

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1500362213

From liach at openjdk.org  Tue Jun 27 10:13:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 10:13:29 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <fSralq6zAHMf74G435_lRX_cL8Fu6NDolrdUmy0uvmA=.657df289-da06-494f-ba10-59d25878a3e5@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

src/java.base/share/classes/java/util/UUID.java line 1:

> 1: /*

You should update the copyright year in the license header of UUID.java from 2022 to 2023.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243490923

From liach at openjdk.org  Tue Jun 27 10:26:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 10:26:17 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <NJUq7kBYrh1dLURJrUjptjER9brDLjt7h0E21m-r8gA=.c52bc4a3-0bb0-4c8b-b1ca-34592b6f7eb2@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

For your info, the reviews required are approving GitHub reviews.

This patch looks great in shape; currently, I think the startup impact of ByteArray. If `UUID.toString` is used in early startup, this patch will increase the startup time for VarHandle initialization. #14636 replaces VarHandle with direct unsafe usage, which significantly reduces startup cost.

A search online says that `-Xlog:class+init=info:file=trace.log` can be added to VM options to print class initialization order. I think we might use it to check the startup impact by seeing if certain classes are loaded earlier now. Disclaimer: I personally haven't tried this; please correct me immediately if there is a better way to measure the startup impact.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609221851

From lancea at openjdk.org  Tue Jun 27 10:28:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Jun 2023 10:28:07 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <iVcZPHPYFpGQ132mB0aohicr4EQ-4WrlundjdVdgPiQ=.65b6bca6-1378-4a31-bbd5-3ea7afa64a9f@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1500501347

From alanb at openjdk.org  Tue Jun 27 11:01:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 11:01:21 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <J2QKQ-ASkX36PDsociYHrqcgBRa3dHufo8WPFzYBOng=.94043e62-dc20-42ec-a2d7-0516a1797f40@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

I'm looking through [6b61a715], update 24.

Moving fastUUID out of Long is good.

UUID::toString can use StandardChars.ISO_8859_1, no need to use sun.nio.cs code here.

The list of imports in java.util.UUID is a bit messy now, can you clean this up.

It's confusing to have java.util.HexDigits and jdk.internal.util.HexDigits. It also creates an inconsistency with DecimalDigits and OctalDigits as the latter encapsulate their arrays. I assume you've done this to allow sharing of the 256 element array. I don't object to move the array to a supporting class but it needs to be renamed and the class description replaced as it is not a Digits implementation. Adding a private constructor would help make it clear that it should not be instantiated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609272188

From duke at openjdk.org  Tue Jun 27 11:27:18 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 11:27:18 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/6b61a715..9fe1d705

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=24-25

  Stats: 35 lines in 3 files changed: 4 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Tue Jun 27 11:30:30 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 11:30:30 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <fSralq6zAHMf74G435_lRX_cL8Fu6NDolrdUmy0uvmA=.657df289-da06-494f-ba10-59d25878a3e5@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <fSralq6zAHMf74G435_lRX_cL8Fu6NDolrdUmy0uvmA=.657df289-da06-494f-ba10-59d25878a3e5@github.com>
Message-ID: <pR-i_Q_DpF7jSPoLy4AIWIfHs4UThyGdlxp7Q-ghHFA=.31d1ad05-525e-462f-8778-272d6259457a@github.com>

On Tue, 27 Jun 2023 10:08:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
>
> src/java.base/share/classes/java/util/UUID.java line 1:
> 
>> 1: /*
> 
> You should update the copyright year in the license header of UUID.java from 2022 to 2023.

do I need to change the copyright information? I am not sure

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243582378

From duke at openjdk.org  Tue Jun 27 11:30:29 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 11:30:29 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
Message-ID: <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>

On Mon, 26 Jun 2023 09:57:31 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1

> I'm looking through [[6b61a71](https://github.com/openjdk/jdk/commit/6b61a715caeeb586d5480a3a70f90bd1811d1335)], update 24.
> 
> Moving fastUUID out of Long is good.
> 
> UUID::toString can use StandardCharsets. ISO_8859_1, no need to use sun.nio.cs code here.
> 
> The list of imports in java.util.UUID is a bit messy now, can you clean this up.
> 
> It's confusing to have java.util.HexDigits and jdk.internal.util.HexDigits. It also creates an inconsistency with DecimalDigits and OctalDigits as the latter encapsulate their arrays. I assume you've done this to allow sharing of the 256 element array. I don't object to move the array to a supporting class but it needs to be renamed and the class description replaced as it is not a Digits implementation. Adding a private constructor would help make it clear that it should not be instantiated.

very good suggestion, i have modified it according to your suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609310739

From duke at openjdk.org  Tue Jun 27 11:53:15 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 11:53:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <pR-i_Q_DpF7jSPoLy4AIWIfHs4UThyGdlxp7Q-ghHFA=.31d1ad05-525e-462f-8778-272d6259457a@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <fSralq6zAHMf74G435_lRX_cL8Fu6NDolrdUmy0uvmA=.657df289-da06-494f-ba10-59d25878a3e5@github.com>
 <pR-i_Q_DpF7jSPoLy4AIWIfHs4UThyGdlxp7Q-ghHFA=.31d1ad05-525e-462f-8778-272d6259457a@github.com>
Message-ID: <P_AKktQhOd-YQY6tnNaGo_sAoCfs9yobZufV8PMZouQ=.43cff8cd-1806-4cbd-9fb8-19fc88b79c09@github.com>

On Tue, 27 Jun 2023 11:27:18 GMT, ??? <duke at openjdk.org> wrote:

> do I need to change the copyright information? I am not sure

Yes, you should update the copyright information of each file you have modified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243607127

From liach at openjdk.org  Tue Jun 27 13:00:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 13:00:14 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <P_AKktQhOd-YQY6tnNaGo_sAoCfs9yobZufV8PMZouQ=.43cff8cd-1806-4cbd-9fb8-19fc88b79c09@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <fSralq6zAHMf74G435_lRX_cL8Fu6NDolrdUmy0uvmA=.657df289-da06-494f-ba10-59d25878a3e5@github.com>
 <pR-i_Q_DpF7jSPoLy4AIWIfHs4UThyGdlxp7Q-ghHFA=.31d1ad05-525e-462f-8778-272d6259457a@github.com>
 <P_AKktQhOd-YQY6tnNaGo_sAoCfs9yobZufV8PMZouQ=.43cff8cd-1806-4cbd-9fb8-19fc88b79c09@github.com>
Message-ID: <7Oo-k57dfNbyiSmasPG8vXolX4_nFX2-BYiALFjbly8=.81b1c526-b673-4cf2-b37b-1230eb163157@github.com>

On Tue, 27 Jun 2023 11:50:40 GMT, Glavo <duke at openjdk.org> wrote:

>> do I need to change the copyright information? I am not sure
>
>> do I need to change the copyright information? I am not sure
> 
> Yes, you should update the copyright information of each file you have modified.

The years in the header are in the form of "Copyright creationYear, lastModifiedYear, xxx". All other files already have their last modified year as 2023; only this one doesn't.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243692902

From liach at openjdk.org  Tue Jun 27 13:00:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 13:00:18 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
Message-ID: <kfiXwlWkizK7tef698fljm8NZD-WaE-S0p-lSpl7FAc=.85dadd39-ee9a-4742-889e-3887c890375c@github.com>

On Tue, 27 Jun 2023 11:27:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.

src/java.base/share/classes/java/util/UUID.java line 479:

> 477:                 ((long) hex256[((int) (msb >> 56)) & 0xff] << 48)
> 478:                         | ((long) hex256[((int) (msb >> 48)) & 0xff] << 32)
> 479:                         | ((long) hex256[((int) (msb >> 40)) & 0xff] << 16)

The long cast seems redundant here.

src/java.base/share/classes/jdk/internal/util/Hex256.java line 34:

> 32:  */
> 33: public final class Hex256 {
> 34:     private Hex256(){

Suggestion:

    private Hex256() {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243683233
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243688988

From dfuchs at openjdk.org  Tue Jun 27 13:13:25 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jun 2023 13:13:25 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
Message-ID: <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>

On Tue, 27 Jun 2023 11:27:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.

src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:

> 36: 
> 37:     @Stable
> 38:     public static final short[] DIGITS;

It's a bit smelly to have a public static field of type array.
Static analysers are likely to flag this.
It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243711721

From asotona at openjdk.org  Tue Jun 27 13:32:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 27 Jun 2023 13:32:47 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v5]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <BKbdk10xXBhnlMr4NrXPeOhY6yxkvhl3p_lEUcSHdTQ=.1071c09a-6654-47fa-bf64-205d3b1e9667@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use 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 220 commits:

 - fixed JavapTask
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - ... and 210 more: https://git.openjdk.org/jdk/compare/05e9c41e...d5a65c49

-------------

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=04
  Stats: 3638 lines in 22 files changed: 835 ins; 1716 del; 1087 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From rriggs at openjdk.org  Tue Jun 27 13:33:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 13:33:06 GMT
Subject: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash [v2]
In-Reply-To: <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
 <C0RCshxfH_h9-6ASJMiIQAsgIR1gBkQ66z6jw_1SNio=.2b2b7395-5920-4d57-8e9d-f0f6a3bff340@github.com>
Message-ID: <RPrdirzz4k3VrjyvCJfXTUM7TORD7_BsP9p7AjLjvjQ=.8e8bb8a7-f94c-4212-9310-69e7a0efc684@github.com>

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting a review comment

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14620#pullrequestreview-1500879927

From jvernee at openjdk.org  Tue Jun 27 13:35:05 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 27 Jun 2023 13:35:05 GMT
Subject: RFR: 8310914: Remove 2 malformed java/foreign ProblemList entries
In-Reply-To: <CLsdTJEBH9ocsASz8Je1tpD05mnBd8ofCtBMUdc5R0w=.5b6814f6-2fe0-4154-bd28-1bf2620226b4@github.com>
References: <W4FJ2bF5UFs5e9HQ_N8Y7DY1PyKE4-Yj5-66UqVMjt8=.332cc00e-2a81-4074-a1b9-f47871769991@github.com>
 <CLsdTJEBH9ocsASz8Je1tpD05mnBd8ofCtBMUdc5R0w=.5b6814f6-2fe0-4154-bd28-1bf2620226b4@github.com>
Message-ID: <n8E36fKsnpOAU3YkZpwouNlbX-3hCy7TS1RjhFTFysM=.f470134d-367a-4e8b-be84-a085bce6e22f@github.com>

On Tue, 27 Jun 2023 06:22:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > The `java/foreign/callarranger/TestAarch64CallArranger.java` test was removed,
> 
> It looks like this test is still present in mainline https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/callarranger/TestLinuxAArch64CallArranger.java

Note that that's a different test. The original was split into multiple different files, one per platform (hence "removed").

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14664#issuecomment-1609514584

From duke at openjdk.org  Tue Jun 27 13:36:14 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 13:36:14 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
Message-ID: <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>

On Tue, 27 Jun 2023 13:10:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> It's a bit smelly to have a public static field of type array. Static analysers are likely to flag this. It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.

I don't think this is a problem. If users can access JDK internal packages, it can do many things. For example, through `JavaLangAccess::getEnumConstantsShared`, an array shared within JDK can be obtained.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243750135

From liach at openjdk.org  Tue Jun 27 13:41:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 13:41:18 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
Message-ID: <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>

On Tue, 27 Jun 2023 13:33:09 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:
>> 
>>> 36: 
>>> 37:     @Stable
>>> 38:     public static final short[] DIGITS;
>> 
>> It's a bit smelly to have a public static field of type array.
>> Static analysers are likely to flag this.
>> It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.
>
>> It's a bit smelly to have a public static field of type array. Static analysers are likely to flag this. It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.
> 
> I don't think this is a problem. If users can access JDK internal packages, it can do many things. For example, through `JavaLangAccess::getEnumConstantsShared`, an array shared within JDK can be obtained.
> 
> Now that we trust the permission control of JPMS, such a requirement seems somewhat rigid.

This array takes some time to prepare. We don't want each class to copy a large array when we can just prepare it once and use it everywhere within the JDK implementation. This array is, under no circumstances, leaked to users so it's safe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243758911

From liach at openjdk.org  Tue Jun 27 13:44:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 13:44:29 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v13]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <oMzC8ple1OLzw9diwn5eMEH7bsvK-JWwAwUgLNBXlcc=.3177efc2-f1cc-402e-ba04-c8a69a83ec7a@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> Benchmark                                            Mode  Cnt   Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Split the concepts of asDirect and target

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/0ac094b8..99960727

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=11-12

  Stats: 214 lines in 8 files changed: 25 ins; 56 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From mbaesken at openjdk.org  Tue Jun 27 13:45:27 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 27 Jun 2023 13:45:27 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v4]
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  small adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14562/files
  - new: https://git.openjdk.org/jdk/pull/14562/files/619b3578..09eb93c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=02-03

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mbaesken at openjdk.org  Tue Jun 27 13:45:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 27 Jun 2023 13:45:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <30dMjVyi4aRjn9GA1WW4kRM9-fvnBKykEuEHk58ZosI=.70b4a1f4-f7b5-45ea-afd1-3bdbd2f0fe9a@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Hi Chris,  I renamed the method and adjusted the comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1609529567

From liach at openjdk.org  Tue Jun 27 13:57:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 13:57:31 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt  Score   Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30  0.817 ? 0.012  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30  0.805 ? 0.007  ns/op
> 
> 
> Benchmark                                            Mode  Cnt     Score     Error  Units
> Benchmark                                            Mode  Cnt   Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10  36.890 ?  2.891  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10  18.340 ?  1.537  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10  50.000 ?  5.590  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  90.550 ? 10.142  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10  36.610 ?  2.685  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10  18.200 ?  1.811  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  71.680 ? 11.097  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  72.090 ?  4.494  us/op

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Rollback VHG changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/99960727..8cbb2083

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From dfuchs at openjdk.org  Tue Jun 27 14:06:16 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jun 2023 14:06:16 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
Message-ID: <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>

On Tue, 27 Jun 2023 13:38:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> It's a bit smelly to have a public static field of type array. Static analysers are likely to flag this. It would be better to make the field private and have a public static method that returns DIGITS.clone() - then each class that needs it (and if I'm not mistaken there are only two) could encapsulate its own private copy.
>> 
>> I don't think this is a problem. If users can access JDK internal packages, they can do many things. For example, through `JavaLangAccess::getEnumConstantsShared`, an array shared within JDK can be obtained.
>> 
>> Now that we trust the permission control of JPMS, such a requirement seems somewhat rigid.
>
> This array takes some time to prepare. We don't want each class to copy a large array when we can just prepare it once and use it everywhere within the JDK implementation. This array is, under no circumstances, leaked to users so it's safe.

What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243804755

From liach at openjdk.org  Tue Jun 27 14:07:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 14:07:11 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v11]
In-Reply-To: <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
 <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>
Message-ID: <-oFiI-eopP4sQdHcWiu8moVn6sVSD-q_S43dDcRHTD4=.ec3c3659-ef1a-49bd-897e-0ee2ff3d8768@github.com>

On Fri, 9 Jun 2023 18:59:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove meaningless target calls and clear outdated cache as needed
>
> Something was bothering me about the current complexity with method handles and the potential interactions with indirect var handles. Its hard to reason about all the interactions so i needed to take a deeper dive, which i really should have done earlier on. Apologies if we are circling around this many times.
> 
> Since we are now leaning on `LazyInitializingVarHandle::target` to initialize I think we can just do this:
> 
>     private void initialize() {
>         UNSAFE.ensureClassInitialized(refc);
>         this.initialized = true;
>     }
> 
>     @Override
>     public MethodHandle toMethodHandle(AccessMode accessMode) {
>         if (initialized) {
>             return target.toMethodHandle(accessMode);
>         } else {
>             if (isAccessModeSupported(accessMode)) {
>                 MethodHandle mh = target.getMethodHandle(accessMode.ordinal());
>                 // Ensure target on this VH is called to initialize the class
>                 return mh.bindTo(this);
>             }
>             else {
>                 // Ensure an UnsupportedOperationException is thrown
>                 return MethodHandles.varHandleInvoker(accessMode, accessModeType(accessMode)).
>                         bindTo(this);
>             }
>         }
>     }
> 
> 
> However, construction of an indirect VH will result in initialization:
> 
>     private IndirectVarHandle(VarHandle target, Class<?> value, Class<?>[] coordinates,
>                       BiFunction<AccessMode, MethodHandle, MethodHandle> handleFactory, VarForm form, boolean exact) {
>         super(form, exact);
>         this.handleFactory = handleFactory;
>         this.target = target;
>         this.directTarget = target.target();
>         this.value = value;
>         this.coordinates = coordinates;
>     }
> 
> 
> Since this is not performance sensitive code we could check if target is an instance of `LazyInitializingVarHandle` then conditionally get it's target if initialized e.g.,
> 
>    this.directTarget = target instanceof LazyInitializingVarHandle lazyTarget ? lazyTarget.lazyTarget() : target.target();
> 
> ?

@PaulSandoz I think this patch as of now is what I want:
1. Lazy VH works both when obtained directly or delegated by an Indirect VH
2. In the most common usage scenario (direct calls on VH), the lazy VH has a good initial performance and a similar long-term performance compared to the eager VH
3. The invasive changes to existing structures are minimized.

For the performance concerns of `getMethodHandle` and `toMethodHandle` (mainly creation and initial invocation), I find that the VH invocation semantics itself has some problems: for example, it's quite pointless to pass a VH-specific direct VH to a VH-specific `getMethodHandle`. My focus on this patch will be to ensure the correctness of MH-related content, but caring about their performance is out of scope for me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1609577849

From duke at openjdk.org  Tue Jun 27 14:10:15 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 14:10:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
Message-ID: <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>

On Tue, 27 Jun 2023 14:02:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?

The point is that it doesn't make any sense, so I don't feel like we should pay anything for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243812535

From alanb at openjdk.org  Tue Jun 27 14:17:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 14:17:16 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
 <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
Message-ID: <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>

On Tue, 27 Jun 2023 14:07:43 GMT, Glavo <duke at openjdk.org> wrote:

> > What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?
> 
> The point is that it doesn't make any sense, so I don't feel like we should pay anything for it.

Daniel makes a good point. Sadly, jdk.internal.util is exported to other modules so it does need to be looked at from an integrity perspective.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243819226

From liach at openjdk.org  Tue Jun 27 14:17:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 14:17:17 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
 <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
 <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>
Message-ID: <oUCm849mz0deVEuwgBNlgB-EVM5cxQVXb0huuRMjylk=.4e9717b4-65ce-40ed-8234-8ae5cb8e8928@github.com>

On Tue, 27 Jun 2023 14:11:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?

I really wish we have frozen arrays, which are safely sharable like records. The closest we have right now is a final array with `@Stable`, which indicates array elements are lazy (any non-default value read can be treated as a constant by JIT); since this array is explicitly `@Stable final`, we can share it within the JDK like any other immutable objects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243822811

From liach at openjdk.org  Tue Jun 27 14:20:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 14:20:20 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.

Chen Liang 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 branch 'master' into fix/cd-usage
 - Merge branch 'master' into fix/cd-usage
 - Fix build
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

-------------

Changes: https://git.openjdk.org/jdk/pull/14640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=03
  Stats: 241 lines in 6 files changed: 61 ins; 94 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

PR: https://git.openjdk.org/jdk/pull/14640

From rriggs at openjdk.org  Tue Jun 27 14:22:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 14:22:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
Message-ID: <5G9wEB5x53xB5H2LGyyONLkfVxVA1MPfsoSJx_29t4A=.d102b2b4-aef4-4284-8050-d819c23352b8@github.com>

On Tue, 27 Jun 2023 11:27:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.

in general, do not rush to integrate, given the number and variety of comments and commenters, it is good practice to wait 24 hours after the last comment to see that comments have stabilized. 
Given the global scope of OpenJDK, reviewers are in most/every timezone.
And formally, every PR must have the required number of approvals from official Reviewers.
We're not there yet.

src/java.base/share/classes/jdk/internal/util/Hex256.java line 31:

> 29: 
> 30: /**
> 31:  * Provides a hexadecimal cache array of values from 0 to 255

A bit more information about the contents and use would be useful for future developers and perhaps an example of the use so they don't have to go find where it is used and decipher the code.
Each element contains the ascii encoded hex characters for the index. It may be obvious which character is the low nibble for the low byte but it might be good to say so.

src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:

> 36: 
> 37:     @Stable
> 38:     public static final short[] DIGITS;

If UUID shows up in startup class loading this array would be a candidate for loading by CDS, as mentioned in earlier review comments. Please create a separate issue to evaluate and add the code to load the array using CDS.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609604257
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243790783
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243817685

From liach at openjdk.org  Tue Jun 27 14:27:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 14:27:16 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <oUCm849mz0deVEuwgBNlgB-EVM5cxQVXb0huuRMjylk=.4e9717b4-65ce-40ed-8234-8ae5cb8e8928@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
 <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
 <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>
 <oUCm849mz0deVEuwgBNlgB-EVM5cxQVXb0huuRMjylk=.4e9717b4-65ce-40ed-8234-8ae5cb8e8928@github.com>
Message-ID: <_DfZ5tA9FKaNC2eW0hZCZZ-Tb_Mn8AQOLy69wXpLwUI=.dbcdfde1-263d-4cdb-83fe-5cec7fdcc2e1@github.com>

On Tue, 27 Jun 2023 14:13:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> > What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?
>>> 
>>> The point is that it doesn't make any sense, so I don't feel like we should pay anything for it.
>> 
>> Daniel makes a good point. Sadly, jdk.internal.util is exported to other modules so it does need to be looked at from an integrity perspective.
>
>> What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?
> 
> I really wish we have frozen arrays, which are safely sharable like records. The closest we have right now is a final array with `@Stable`, which indicates array elements are lazy (any non-default value read can be treated as a constant by JIT); since this array is explicitly `@Stable final`, we can share it within the JDK like any other immutable objects.

On second thought, we should be able to create a getter like

@ForceInline
static short hex256(int byteValue) {
    return HEX256[byteValue];
}

and switch usages to that getter instead. This is a better approach than cloning the array and makes the array safe from modification by modules that get jdk.internal.util exports.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243840048

From duke at openjdk.org  Tue Jun 27 14:35:15 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 14:35:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <_DfZ5tA9FKaNC2eW0hZCZZ-Tb_Mn8AQOLy69wXpLwUI=.dbcdfde1-263d-4cdb-83fe-5cec7fdcc2e1@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
 <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
 <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>
 <oUCm849mz0deVEuwgBNlgB-EVM5cxQVXb0huuRMjylk=.4e9717b4-65ce-40ed-8234-8ae5cb8e8928@github.com>
 <_DfZ5tA9FKaNC2eW0hZCZZ-Tb_Mn8AQOLy69wXpLwUI=.dbcdfde1-263d-4cdb-83fe-5cec7fdcc2e1@github.com>
Message-ID: <3pplgfhEpBo6LiXTwlFRbDS2oSb1ELbz9t7F-WsTJ28=.b3cf3a50-bc95-489f-aded-e0fcea41b279@github.com>

On Tue, 27 Jun 2023 14:23:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> What I suggest is to prepare the array only once (in the static block as it is now), but have each class that use it encapsulate is own copy - obtained from clone(). Surely 256 shorts is not so large that we can't have two arrays?
>> 
>> I really wish we have frozen arrays, which are safely sharable like records. The closest we have right now is a final array with `@Stable`, which indicates array elements are lazy (any non-default value read can be treated as a constant by JIT); since this array is explicitly `@Stable final`, we can share it within the JDK like any other immutable objects.
>
> On second thought, we should be able to create a getter like
> 
> @ForceInline
> static short hex256(int byteValue) {
>     return HEX256[byteValue];
> }
> 
> and switch usages to that getter instead. This is a better approach than cloning the array and makes the array safe from modification by modules that get jdk.internal.util exports.

> Sadly, jdk.internal.util is exported to other modules so it does need to be looked at from an integrity perspective.

This is indeed a problem to consider.

Maybe we can move this array back into `HexDigits`. Then we create a new package `jdk.internal.digits` and move `Digits`, `DecimalDigits`, `HexDigits`, `OctalDigits` all into it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1243854585

From ryan at iernst.net  Tue Jun 27 14:37:35 2023
From: ryan at iernst.net (Ryan Ernst)
Date: Tue, 27 Jun 2023 07:37:35 -0700
Subject: List extending Collection/SequencedCollection
Message-ID: <CA+DiXd7WgO2fuNJ=OAwUVutjBhk_1uN38uZ77=6-hNW6jCgyTg@mail.gmail.com>

Hi core-libs-dev,

I know various threads have existed over the past few months on
SequencedCollection and its implications on compatibility. I wanted to
raise this semi-related issue we noticed recently after beginning
testing against Java 21.

Elasticsearch began testing against Java 21, and noticed a series of
failures in Painless (our builtin scripting language, which
dynamically compiles to bytecode). Most tests that used List failed to
compile, with several unknown methods (eg add). Painless builds a
hierarchy of classes it knows about for method resolution. This
hierarchy didn't know anything about SequencedCollection since we
currently compile against Java 17. Now, this was ultimately a bug in
Painless, because we knew there could be cases where we encounter
unknown classes in the hierarchy (eg a class which is not blessed to
be visible in the language). However, I think the reason we found that
bug (List extending from SequencedCollection) might still cause issues
for some.

While debugging the issue, something that struck me as interesting in
the SequencedCollection hierarchy is the difference between List and
SortedSet. Both of these classes were made to be compatible with
sequenced classes by adding the new classes as super interfaces,
SequencedCollection and SequencedSet, respectively. However, while
SortedSet was *added* as a super interface, List had its super
interface Collection *replaced* by SequencedCollection.

I don't know enough about the rampdown process to know if this is
still fixable in Java 21. It is probably an extreme edge case that
doesn't matter, since eg instanceof Collection will still work in
existing code. But for consistency, it would seem better to maintain
Collection as a direct super interface of List. Is there any reason
such a change doesn't fit with the collections architecture going
forward?

From liach at openjdk.org  Tue Jun 27 14:40:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 14:40:25 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v9]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <5nB8tCek3sR4GQJjp_S9ZPH7sD83N1c7MQALpEznAG8=.3ad130dd-9c31-4d6e-9c9e-24c5dfefccbb@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  produce identical component descriptors in descriptor strings -> cannot be distinguished in descriptor strings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/96b142e0..3bea7506

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From duke at openjdk.org  Tue Jun 27 14:58:43 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 14:58:43 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v27]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <VpK9hNyi2upQ6c1SwcqW9ujRnpEfT7hzzPQfZeg4n-s=.72115ca3-c571-4c81-9b40-a798c9984a2a@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/util/Hex256.java
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/9fe1d705..fe9efa6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=25-26

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From coffeys at openjdk.org  Tue Jun 27 15:06:45 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 27 Jun 2023 15:06:45 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
Message-ID: <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>

> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration

Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Avoid sharing INDENT variables
 - Merge branch 'master' into 8281658-showsettings-security
 - Don't allow bad subcommand values for security component
 - restore more informative help message
 - Split long properties for ; also
 - Pass PrintStream to security helper
 - Refactor out security code to helper class
 - Print aliases. Order Provider type/service output.
 - Incorporate review comments from Roger and tweak some code
 - Merge branch 'master' into 8281658-showsettings-security
 - ... and 5 more: https://git.openjdk.org/jdk/compare/698e2b5c...7e6f5090

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14394/files
  - new: https://git.openjdk.org/jdk/pull/14394/files/77c9f5e2..7e6f5090

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14394&range=06-07

  Stats: 31805 lines in 1150 files changed: 12787 ins; 12829 del; 6189 mod
  Patch: https://git.openjdk.org/jdk/pull/14394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14394/head:pull/14394

PR: https://git.openjdk.org/jdk/pull/14394

From duke at openjdk.org  Tue Jun 27 15:20:34 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 15:20:34 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v3]
In-Reply-To: <tLbna9f_IinIgSSZV48EQKrjNebF4Bb2Gj7TAvv1hZM=.3ba86801-efc2-4e5b-b3ed-d9c0a2904c88@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <tLbna9f_IinIgSSZV48EQKrjNebF4Bb2Gj7TAvv1hZM=.3ba86801-efc2-4e5b-b3ed-d9c0a2904c88@github.com>
Message-ID: <bYpm646fuUjkG6FTLM7lo9Zecmfcn4swIupJaFpb9Lg=.85af34a7-d9d6-45e4-92ae-d35be53a0ff6@github.com>

On Tue, 27 Jun 2023 07:45:51 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> Glavo has updated the pull request with a new target base 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 tr-locale
>  - Merge branch 'openjdk:master' into tr-locale
>  - list mode of jmod and jimage cannot be used normally in turkish locale

I have updated `JImageTask`, `JlinkTask`, and `VersionPropsPlugin`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1609718114

From duke at openjdk.org  Tue Jun 27 15:20:33 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 15:20:33 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v4]
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  update JImageTask, JlinkTask and VersionPropsPlugin

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12281/files
  - new: https://git.openjdk.org/jdk/pull/12281/files/39102397..3eb4407b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12281&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12281&range=02-03

  Stats: 5 lines in 3 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12281/head:pull/12281

PR: https://git.openjdk.org/jdk/pull/12281

From bpb at openjdk.org  Tue Jun 27 15:31:14 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Jun 2023 15:31:14 GMT
Subject: Integrated: 8222329: Readable read(CharBuffer) does not specify that 0
 is returned when there is no remaining space in buffer
In-Reply-To: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
References: <r1Dc6NE3jQabwUfaDl1U_5-YrdiN_1Exn6IMOMNNLbQ=.4c461dc0-bc19-458b-8696-41b161496325@github.com>
Message-ID: <VNWi74p7U5oMrb6xWiwA29ovI52efGhks227QDiGHm0=.93ef9d00-98dd-42c5-9896-b28111971107@github.com>

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the behavior of `java.lang.Readable` when the specified `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.

This pull request has now been integrated.

Changeset: 58bb6555
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58bb6555e783e4627f57c3c8281183c474d581c9
Stats:     23 lines in 3 files changed: 11 ins; 0 del; 12 mod

8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer

Reviewed-by: rriggs, lancea, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14616

From alanb at openjdk.org  Tue Jun 27 15:46:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 15:46:07 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException should
 be clearer
Message-ID: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>

Docs only update to add a missing `@throws StructureViolationException` and make it clearer when the exception is thrown. In the future we might re-visit this so that the description is in one place rather than in each method.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14679/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310892
  Stats: 60 lines in 1 file changed: 12 ins; 6 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14679/head:pull/14679

PR: https://git.openjdk.org/jdk/pull/14679

From prappo at openjdk.org  Tue Jun 27 15:50:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 27 Jun 2023 15:50:12 GMT
Subject: Integrated: 8310890: Normalize identifier names
In-Reply-To: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
References: <HJJXYoCVBUrgybt15S_GtD8WHeO3GGjZYfOqhH6nXaQ=.abdb7d71-1648-4515-8739-f18e7f255f73@github.com>
Message-ID: <uoHYcMykyT9Mv0pCEqNuWEANMTDSeW50sVORz_5K5Bk=.e94c8df7-fd55-44c8-9bdb-50995f7786fa@github.com>

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup PR to normalize names of identifiers which are Java variables/fields or tokens in text files. Those names either contain a pronoun that is very rarely used in code, or seem like they contain such a pronoun, which, in fact, they don't. Either way, the goal is to improve readability and clarity.
> 
> Also, this PR fixes a few related typos.

This pull request has now been integrated.

Changeset: f6133edb
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6133edb08dd7a7d764638c5b1cdd5c3e56ed64e
Stats:     184 lines in 10 files changed: 0 ins; 0 del; 184 mod

8310890: Normalize identifier names

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14653

From duke at openjdk.org  Tue Jun 27 16:14:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 16:14:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v28]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <YVU-0YJxXF54ci70mR83bO8MdXrBZEyEzW7htYABGA0=.7dcfa01a-0c33-4e31-b4e1-a2309722876b@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  change copyright years, and rename jdk.internal.util.Hex256 to jdk.internal.digits.Hex256, and add comments.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/fe9efa6b..b81f12d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=26-27

  Stats: 154 lines in 4 files changed: 98 ins; 53 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From liach at openjdk.org  Tue Jun 27 16:14:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 16:14:20 GMT
Subject: Integrated: 8310849: Pattern matching for instanceof and arrayType
 cleanup in j.l.invoke and j.l.reflect
In-Reply-To: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
References: <mxqZHg51gEBznWwcH9qDw3wNy941r6YF86mfh7s2NZk=.d0b3e6a0-5293-4d73-a6ee-2eb588d13e94@github.com>
Message-ID: <075NkdQaLFH0fHSAPE-d2eHPMHMQztKAHyRsD5x_cLI=.02f1e1ca-56d3-4b1a-bcc1-1ab98a256e63@github.com>

On Sun, 25 Jun 2023 09:18:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch touches java.lang.reflect and java.lang.invoke packages. It replaces instanceof + cast with pattern matching and updates  Array.newInstance().getClass() patterns with arrayType() for obtaining array types of a class.

This pull request has now been integrated.

Changeset: 2bd4136b
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bd4136bdb74599e358a22c83ffc685a2c0db4d2
Stats:     292 lines in 34 files changed: 0 ins; 81 del; 211 mod

8310849: Pattern matching for instanceof and arrayType cleanup in j.l.invoke and j.l.reflect

Reviewed-by: mchung, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/14642

From naoto at openjdk.org  Tue Jun 27 16:16:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 16:16:09 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond
In-Reply-To: <G_Ffcmy5x7IgHxMb-8v1YUDBJQ6D3f8qCdTGSSJI-iU=.9ef1448d-7133-4278-8b82-28aeec8cf80d@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
 <G_Ffcmy5x7IgHxMb-8v1YUDBJQ6D3f8qCdTGSSJI-iU=.9ef1448d-7133-4278-8b82-28aeec8cf80d@github.com>
Message-ID: <ZyeJpHQq3JZ86huTxINB6_NjpDSRT32MsIPJP0MMFe8=.51e3a023-b967-4b36-8c80-5f7f09935186@github.com>

On Tue, 27 Jun 2023 07:23:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> test/jdk/java/time/test/java/time/TestClock_Tick.java line 77:
> 
>> 75:  * Test tick clock.
>> 76:  *
>> 77:  * @bug 8310232
> 
> Did you mean the put the "@bug" here? If you did then I assume you'll need to add the original bug ID too as TestClock_Tick wasn't created for 8310232.

I meant to put the bug id here, but you are right that it would confuse readers as if it is the bug that created this regression test. Will remove it and leave the bug id only for the added test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14657#discussion_r1244011818

From naoto at openjdk.org  Tue Jun 27 16:16:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 16:16:21 GMT
Subject: Integrated: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash
In-Reply-To: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
References: <r3UNC7am9koUdJH2tC_Hrzdwzs8h2AgqrQhva_jJxho=.506d9149-fbdf-41b6-9a9c-42fc55674f19@github.com>
Message-ID: <1DFD5JYAwbovHYyJKqOcLdWArPdyS12YNPdWsl0T44Y=.99b0a09c-38eb-40ef-9750-f7bf2388288c@github.com>

On Thu, 22 Jun 2023 20:36:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There are other locations than `ISO_LOCAL_DATE` that have the same description. Those are corrected too.

This pull request has now been integrated.

Changeset: ec45bd64
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

Reviewed-by: rriggs, darcy, iris, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/14620

From duke at openjdk.org  Tue Jun 27 16:18:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 16:18:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <5G9wEB5x53xB5H2LGyyONLkfVxVA1MPfsoSJx_29t4A=.d102b2b4-aef4-4284-8050-d819c23352b8@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5G9wEB5x53xB5H2LGyyONLkfVxVA1MPfsoSJx_29t4A=.d102b2b4-aef4-4284-8050-d819c23352b8@github.com>
Message-ID: <i64UqUl3df8Hoqv3eV0dij4wjKIHNu0wtuIzh04I6yk=.2bc4127c-e51f-435b-9051-5901dc8de606@github.com>

On Tue, 27 Jun 2023 13:54:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.
>
> src/java.base/share/classes/jdk/internal/util/Hex256.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * Provides a hexadecimal cache array of values from 0 to 255
> 
> A bit more information about the contents and use would be useful for future developers and perhaps an example of the use so they don't have to go find where it is used and decipher the code.
> Each element contains the ascii encoded hex characters for the index. It may be obvious which character is the low nibble for the low byte but it might be good to say so.

comments have been added, including usage examples.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1244014708

From duke at openjdk.org  Tue Jun 27 16:18:21 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 16:18:21 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <3pplgfhEpBo6LiXTwlFRbDS2oSb1ELbz9t7F-WsTJ28=.b3cf3a50-bc95-489f-aded-e0fcea41b279@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
 <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
 <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>
 <oUCm849mz0deVEuwgBNlgB-EVM5cxQVXb0huuRMjylk=.4e9717b4-65ce-40ed-8234-8ae5cb8e8928@github.com>
 <_DfZ5tA9FKaNC2eW0hZCZZ-Tb_Mn8AQOLy69wXpLwUI=.dbcdfde1-263d-4cdb-83fe-5cec7fdcc2e1@github.com>
 <3pplgfhEpBo6LiXTwlFRbDS2oSb1ELbz9t7
 F-WsTJ28=.b3cf3a50-bc95-489f-aded-e0fcea41b279@github.com>
Message-ID: <9TP7iwF3auFo6ejyysEJmbflMTtKH83QudQppaRB-BE=.fea5cdc9-0770-45be-959b-4749c279517e@github.com>

On Tue, 27 Jun 2023 14:32:14 GMT, Glavo <duke at openjdk.org> wrote:

>> On second thought, we should be able to create a getter like
>> 
>> @ForceInline
>> static short hex256(int byteValue) {
>>     return HEX256[byteValue];
>> }
>> 
>> and switch usages to that getter instead. This is a better approach than cloning the array and makes the array safe from modification by modules that get jdk.internal.util exports.
>
>> Sadly, jdk.internal.util is exported to other modules so it does need to be looked at from an integrity perspective.
> 
> This is indeed a problem to consider.
> 
> Maybe we can move this array back into `HexDigits`. Then we create a new package `jdk.internal.digits` and move `Digits`, `DecimalDigits`, `HexDigits`, `OctalDigits` all into it.

Hex256 has been moved to jdk.internal.digits, jdk.internal.digits is not exported.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1244011030

From jlaskey at openjdk.org  Tue Jun 27 16:18:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 27 Jun 2023 16:18:30 GMT
Subject: RFR: JDK-8310975 java.util.FormatItemModifier should not be protected
Message-ID: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>

The nested class is incorrectly marked as protected.

-------------

Commit messages:
 - Remove protected from FormatItemModifier

Changes: https://git.openjdk.org/jdk/pull/14681/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14681&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310975
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14681/head:pull/14681

PR: https://git.openjdk.org/jdk/pull/14681

From kvn at openjdk.org  Tue Jun 27 16:19:12 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 27 Jun 2023 16:19:12 GMT
Subject: [jdk21] RFR: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
In-Reply-To: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>
References: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>
Message-ID: <lVhqnglhX37zC_KFKn9WCUIc84lEljv6hY0FQW-kSzg=.0db6042d-d034-4294-9fe5-d3aec794ae20@github.com>

On Tue, 27 Jun 2023 07:46:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459). Applies cleanly.
> 
> Thanks,
> Tobias

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/68#pullrequestreview-1501379033

From alanb at openjdk.org  Tue Jun 27 16:22:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 16:22:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>
Message-ID: <FFAoNloDPnqL5XQocUcicOwmdqbppit6aWWsCDzM0w8=.43b2cff5-33d5-4f16-a789-b475d4284c81@github.com>

On Tue, 27 Jun 2023 11:25:32 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
>
>> I'm looking through [[6b61a71](https://github.com/openjdk/jdk/commit/6b61a715caeeb586d5480a3a70f90bd1811d1335)], update 24.
>> 
>> Moving fastUUID out of Long is good.
>> 
>> UUID::toString can use StandardCharsets. ISO_8859_1, no need to use sun.nio.cs code here.
>> 
>> The list of imports in java.util.UUID is a bit messy now, can you clean this up.
>> 
>> It's confusing to have java.util.HexDigits and jdk.internal.util.HexDigits. It also creates an inconsistency with DecimalDigits and OctalDigits as the latter encapsulate their arrays. I assume you've done this to allow sharing of the 256 element array. I don't object to move the array to a supporting class but it needs to be renamed and the class description replaced as it is not a Digits implementation. Adding a private constructor would help make it clear that it should not be instantiated.
> 
> very good suggestion, i have modified it according to your suggestion.

@wenshao - adding a jdk.internal.digits package for this tiny class is overkill. For this PR, the simplest thing is to revert the changes to HexDigit, remove jdk.internal.digits.Hex256 and just put a small holder class in UUID for use by UUID.toString. That would be my preference to avoid splitting up HexDigits and creating inconsistencies in code used for string templates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609843786

From alanb at openjdk.org  Tue Jun 27 16:26:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 16:26:19 GMT
Subject: RFR: JDK-8310975 java.util.FormatItemModifier should not be
 protected
In-Reply-To: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
References: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
Message-ID: <17TIAngGnua2KRB8mbnOh8daywXmlLsP98X7Yk_80mI=.7a9ee663-8498-4290-bb3c-6de4d76f6d6f@github.com>

On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501387697

From darcy at openjdk.org  Tue Jun 27 16:26:19 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 16:26:19 GMT
Subject: RFR: JDK-8310975 java.util.FormatItemModifier should not be
 protected
In-Reply-To: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
References: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
Message-ID: <vk2DPH4cyVwSmOoJvNndJvZje4PGeFcfDsusdEOBYQs=.f6c796ff-0fe9-4caa-a7ce-6df9dd950796@github.com>

On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501391798

From iris at openjdk.org  Tue Jun 27 16:31:08 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 27 Jun 2023 16:31:08 GMT
Subject: RFR: JDK-8310975 java.util.FormatItemModifier should not be
 protected
In-Reply-To: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
References: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
Message-ID: <JYYAu974HDiaTqJfXWb4z9Dlb1o4OErJzXKPXjxL03Y=.0b914c7d-34fe-4d2d-bc86-5b8ada3e38c2@github.com>

On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501400084

From duke at openjdk.org  Tue Jun 27 16:31:22 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 16:31:22 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>
Message-ID: <-Rnjq4GquO8Hc1SSB20K8KDB0tvUL05-5w6tnFL_TcM=.303c15b0-8bd2-4b2d-84f4-d16cf27864d6@github.com>

On Tue, 27 Jun 2023 11:25:32 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
>
>> I'm looking through [[6b61a71](https://github.com/openjdk/jdk/commit/6b61a715caeeb586d5480a3a70f90bd1811d1335)], update 24.
>> 
>> Moving fastUUID out of Long is good.
>> 
>> UUID::toString can use StandardCharsets. ISO_8859_1, no need to use sun.nio.cs code here.
>> 
>> The list of imports in java.util.UUID is a bit messy now, can you clean this up.
>> 
>> It's confusing to have java.util.HexDigits and jdk.internal.util.HexDigits. It also creates an inconsistency with DecimalDigits and OctalDigits as the latter encapsulate their arrays. I assume you've done this to allow sharing of the 256 element array. I don't object to move the array to a supporting class but it needs to be renamed and the class description replaced as it is not a Digits implementation. Adding a private constructor would help make it clear that it should not be instantiated.
> 
> very good suggestion, i have modified it according to your suggestion.

> @wenshao - adding a jdk.internal.digits package for this tiny class is overkill. For this PR, the simplest thing is to revert the changes to HexDigit, remove jdk.internal.digits.Hex256 and just put a small holder class in UUID for use by UUID.toString. That would be my preference to avoid splitting up HexDigits and creating inconsistencies in code used for string templates.

Wenshao hopes to use this array for other optimizations in `java.lang` in the future.

But as for this PR, I suggest wenshao not to do so much. I suggest moving `DIGITS` back to `HexDigits` first to make the modifications in this PR smaller. Reducing modifications helps with faster review.

When you need to optimize the classes in `java.lang`, we will continue to discuss how to share these arrays more safely and efficiently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609857054

From liach at openjdk.org  Tue Jun 27 16:33:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 16:33:11 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's faster than old implementation in general.
> 
> 
> Benchmark                                                          Mode  Cnt      Score      Error  Units
> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallLambda             avgt   15  17624.673 ? 24...

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - SecurityManager fixed, minimize changes
 - Merge branch 'master' into explore/mhp-iface
 - Some changes per Mandy's review. SecurityManager test fails in this patch
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - stage, needs to fix is mh proxy instance check
 - Merge branch 'master' into explore/mhp-iface
 - Remove assertion, no longer true with teleport definition in MHP
 - Fix tabs, and tests about modules and constructor access
 - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

-------------

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=17
  Stats: 1315 lines in 16 files changed: 1072 ins; 150 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

PR: https://git.openjdk.org/jdk/pull/13197

From naoto at openjdk.org  Tue Jun 27 16:34:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 16:34:40 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond [v2]
In-Reply-To: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
Message-ID: <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>

> Fixing the `/ by zero` exception with tick durations less than a millisecond.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8310232-TickClock-ArithExp
 - Removed bugid from the test class description
 - refactor return statement
 - 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14657/files
  - new: https://git.openjdk.org/jdk/pull/14657/files/050fb378..d1a984d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14657&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14657&range=00-01

  Stats: 9256 lines in 348 files changed: 3584 ins; 2949 del; 2723 mod
  Patch: https://git.openjdk.org/jdk/pull/14657.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14657/head:pull/14657

PR: https://git.openjdk.org/jdk/pull/14657

From alanb at openjdk.org  Tue Jun 27 16:38:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 16:38:16 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <-Rnjq4GquO8Hc1SSB20K8KDB0tvUL05-5w6tnFL_TcM=.303c15b0-8bd2-4b2d-84f4-d16cf27864d6@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>
 <-Rnjq4GquO8Hc1SSB20K8KDB0tvUL05-5w6tnFL_TcM=.303c15b0-8bd2-4b2d-84f4-d16cf27864d6@github.com>
Message-ID: <G3lEcvrqzUG0RTuQJuIzzp8ZI0Rg29y5oMsKbF_pn6s=.20892e3b-6ca2-48ea-8f8a-a05e3fc50ef2@github.com>

On Tue, 27 Jun 2023 16:28:44 GMT, Glavo <duke at openjdk.org> wrote:

> Wenshao hopes to use this array for other optimizations in `java.lang` in the future.
> 
> But as for this PR, I suggest wenshao not to do so much. I suggest moving `DIGITS` back to `HexDigits` first to make the modifications in this PR smaller. Reducing modifications helps with faster review.
> 
> When you need to optimize the classes in `java.lang`, we will continue to discuss how to share these arrays more safely and efficiently.

Let's keep this PR as simple as possible. Right now, it's up to 100 comments and 27 iterations, it's annoying to be sending new contributor Wenshao in different directions. Future work that would allow safer sharing of arrays is future work, let's keep this PR as simple as possible. Not all applications use UUID.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609869958

From darcy at openjdk.org  Tue Jun 27 16:44:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 16:44:04 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v2]
In-Reply-To: <lbGiQk65XamUn9n6mahqZjX8xOr9SEYToui614nk9cc=.9a82cc6d-71c2-47f3-b366-cf5cb920eca4@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <mgZMdBlFtQvIvrFalyZFo5atR6csPkSBSb9cgV3KjCU=.31f07e49-7b0a-40c3-b5a4-a9680c79b605@github.com>
 <-eJOismaPqvwI-Y427qNV0bCmfscDRkUPzrLsPoTUko=.71d3ee26-3a9e-4fe9-a08d-88d5429bb3e4@github.com>
 <l5lh3ilK4H-aCE1j8aeQvWkRLiy7EpeAWYhoPbO64-k=.eacbe3a6-468f-428f-b77b-ab455ae9ed85@github.com>
 <lbGiQk65XamUn9n6mahqZjX8xOr9SEYToui614nk9cc=.9a82cc6d-71c2-47f3-b366-cf5cb920eca4@github.com>
Message-ID: <f8IrRD4l3jtXQt_bgCFgmzjrT_c_xnCX-SZQVfttsOg=.4a26f58c-c79f-4301-8cf0-212683e94c89@github.com>

On Tue, 20 Jun 2023 20:54:43 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> > A positive number is any number that is greater than 0. **Unlike positive integers**, which include 0
> 
> math.net seems pretty alone in this. I find the notion bizarre. There seems to be an overwhelming majority of sources that consider 0 to be neither negative nor positive.

Yes, all the math conventions I'm aware of is that integer zero is neither positive nor negative. For example, the signum method returns 0 for 0, -1 for negative values, and 1 for positive values.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1609877890

From liach at openjdk.org  Tue Jun 27 17:05:20 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 17:05:20 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
Message-ID: <QcJuo0rZItKS-U_7jE_b6BC8Xktm8D4Rad3IJTzesbM=.3e3b41cc-6106-475d-8f7c-eb7c95426d0d@github.com>

On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

I have updated this patch again, this time updated to latest Classfile API and removed irrelevant changes.

1. The previous SecurityManager failure was because of ClassLoaders$AppClassLoader's security manager package access check. Even if we can patch the package access check there, we cannot rule out that another interface's class loader reject loading jdk.internal classes specifically exported to our dynamic module. Thus, I moved the check method to be part of the class template, and chose the ClassValue approach instead of using a marker interface.
2. Given this observation, exporting jdk.internal packages to modules with user class loaders may be problematic; we might need our custom class loaders if we do export jdk.internal content to a class that can see user classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1609908127

From viktor.klang at oracle.com  Tue Jun 27 17:10:42 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 27 Jun 2023 17:10:42 +0000
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
Message-ID: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi core-libs-dev,

Over the past 6+ months I've been thinking about, and tinkering with, how we'd be able to expose a user-facing API for extensible intermediate java.util.stream.Stream operations?a feature envisioned all the way back when Streams were created.

I'm now at a point where I have a viable design and implementation, and so I'm turning to you for your feedback: on the direction taken; the API concepts; and, in particular, is there anything which I have overlooked/missed?

(If you, like myself, prefer reading pre-rendered markdown, click here<https://cr.openjdk.org/~vklang/Gatherers.html>)




# Gathering the streams

## Introduction

Java 8 introduced the `java.util.stream` API, which represents a lazily
computed, potentially unbounded sequence of values (Streams was also the first
designed-for-lambdas API in the JDK). Streams supports the ability to process
the stream either sequentially or in parallel.

A `Stream` pipeline consists of a source (collection, array, generator, etc),
zero or more intermediate operations (`Stream` -> `Stream` transforms), and an
eager terminal operation which produces a value or a side-effect.

The Streams API come with a reasonably rich, but fixed set of built-in
operations (mapping, filtering, reduction, sorting, etc), as well as an
extensible terminal operation (`Stream::collect`) that enables the stream
contents to be flexibly summarized in a variety of forms.  The resulting API is
rich enough that users have had good experience with streams, but there are
repeated requests for "please add operation X to streams".

In this document, we explore a corresponding extensible _intermediate_
operation, called `Stream::gather`, which is able to address many of the
requests we've gotten for additional operations.

## "Missing" intermediate operations

Over the years, many new operations for streams have been proposed.  Each of
them may be useful in some situation, but many of them are too narrow to be
included in the core `Stream` API.  We'd like for people to be able to plug
these operations in via an extension point, as with `Stream::collect`.

Here are some examples of proposed intermediate operations that are not easily
expressible as intermediate operations on `Stream` today.

* **Folds**.  Folding is a generalization of reduction.  With reduction, the
  result type is the same as the element type, the combiner is associative, and
  the initial value is an identity for the combiner.   For a fold, these
  conditions are not required, though we give up parallelizability.

  Example: `foldLeft("", (str,elem) -> str + " " + elem.toString())` over the values
  `[1,2,3]` yields `["1 2 3"]`.

  See https://bugs.openjdk.org/browse/JDK-8133680 & https://bugs.openjdk.org/browse/JDK-8292845

* **Unfolds**.  This takes an aggregate and decomposes it into elements.  An
  `unfold` can reverse the operation of the above fold example using `Scanner`
  or `String::split`.

  Example: `unfold(e -> new Scanner(e), Scanner::hasNextInt, Scanner::nextInt)`
  `["1 2 3"]` yields `[1,2,3]`.

  See: https://bugs.openjdk.org/browse/JDK-8151408

* **Barriers**.  Usually all operations of a stream pipeline can run
  simultaneously as data is available.  In some cases, we may wish to have a
  barrier that requires that the entirety of one operation is completed before
  providing any elements to the next operation.

  Example: `someStream.a(...).barrier(someEffect)...` would require that all
  effects from `a` are completed before executing `someEffect` or producing any
  downstream values.

  See: https://bugs.openjdk.org/browse/JDK-8294246

* **Windowing**.  Given a stream, we may wish to construct a stream which
  groups the original elements, either in overlapping or disjoint groups.

  Example: `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
  Example: `slidingWindow(2)` over the values `[1,2,3]` yields `[[1,2],[2,3],[3,4]]`.

  See: https://stackoverflow.com/questions/34158634/how-to-transform-a-java-stream-into-a-sliding-window

* **Prefix scans**. Prefix scans are a stream of incremental reductions.
  Perhaps surprisingly, some prefix scans are parallelizable, and we are exploring adding support for that beyond `Arrays.parallelPrefix()`.

  Example: `scan((sum, next) -> sum + next)` over  values `[1,2,3,4]` yields `[1,3,6,10]`

  See: https://stackoverflow.com/questions/55265797/cumulative-sum-using-java-8-stream-api

* **Duplicated elements**.  The `distinct` operation will remove duplicates; sometimes we want only the elements that are duplicated.

  Example: `duplicates(Object::equals)` over values `[1,1,2,3,4]` yields `[1]`

  See: https://stackoverflow.com/questions/27677256/java-8-streams-to-find-the-duplicate-elements

* **Running duplicate elimination**.  Here, we want to eliminate adjacent repeated elements.

  Example: `collapseRuns(Object::equals)` over values `[1,1,2,3,3]` yields `[1,2,3]`

These are just a few of the stream operations people have wished for?
and while many operations are too specialized to include in the core library,
all are things we'd like for people to be able to express with streams.

## Extending streams

It was always desired for `java.util.stream.Stream` to have an extension point
for intermediate operations; when the library was first built, this wish-list
item was recorded: https://bugs.openjdk.org/browse/JDK-8132369.  There were many
reasons that this was not included in the initial version, the most important
being that it was not at all obvious what the right API was.

The set of intermediate operations on Streams carries the exact same trade-off
as [CISC](Complex Instruction Set Computing) vs [RISC](Reduced Instruction Set
Computing), namely: either you have to provide a rather sizeable set of
specialized operations, or you provide a small set of general operations.

For the **CISC**-strategy, the main drawback is that not all operations is
equally useful, and having a large set of operations to choose from creates a
barrier to effective usage by making the correct choice harder to identify.

For the **RISC**-strategy, the main drawback is that it puts more effort on the
user to encode more specialized operations over a set of generic operations,
making code harder to read, and harder to maintain, for the user.

However, one success story was `Collector`; this allowed us to extend _terminal_
operations with a good balance of expressiveness, reuse, and API footprint.  We
would like to do the same for intermediate operations -- and we can draw some
inspiration from `Collector` to get there.

## Requirements

Breaking down operations into intermediate and terminal is a useful distinction, however,
in reality there are many more characteristics we could use to describe operations,
and relatively few operations use exactly the same subset of characteristics.
The following is a curated set of characteristics of stream operations;
if we want to enable generic, user-defineable, intermediate operations on streams,
we probably have to provide for them all.

| Ordinal | Feature                  | What this means in practice                                 | Example operation(s)                |
|---------|--------------------------|-------------------------------------------------------------|-------------------------------------|
|    1    | Intermediate operation   | Add custom new operations to Stream pipelines               | *map*, *filter*                     |
|    2    | Incremental operation    | Evaluate the Stream pipeline depth-first                    | *map*, *filter*                     |
|    3    | Stateful operation       | Remember information between processing elements            | *limit*, *foldLeft*                 |
|    4    | N:M inputs-to-outputs    | Encode a wide array of operations                           | *limit*, *flatMap*                  |
|    5    | Prefix consumption       | An operation should consume only as much as needed          | *limit*, *takeWhile*                |
|    6    | Beginning-of-stream hook | Ability to have initialization logic                        | *foldLeft*, *grouped*               |
|    7    | End-of-stream hook       | Flush elements downstream                                   | *sorted*, *grouped*                 |
|    8    | Opt-in parallelizability | Speed up CPU-bound processing for parallelizable operations | *reduce*, *map*                     |

Now when we have a better idea of what we need to achieve, let's have a look at
what our options are.

## Comparing existing operations

Let's look at the operations we already have, to see if they would fit the bill
as a generic extension point for intermediate `Stream`-operations.

These are, in order, `Stream.map()`, `Stream.flatMap(?)` (`Stream.mapMulti(?)`
is analogous), and `Collector` & `Stream.collect(?)`?and in the table below we
see how they line up against our requirements.

| Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector |
|---------|--------------------------|---------------------------|---------------------------|-----------------|
|    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    |
|    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    |
|    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             |
|    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         |
|    5    | Prefix consumption       | No                        | No                        | No              |
|    6    | Beginning-of-stream hook | No                        | No                        | Yes             |
|    7    | End-of-stream hook       | No                        | No                        | Yes             |
|    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   |

Looking at the options above, none of them are going to, as-is, fit the bill as
an extension point for generic intermediate `Stream` operations, but one of them
has more promise than the others: `Collector`.  Obvious needed upgrades are
supporting short-circuiting and incremental generation of output; let's see what
that looks like in practice.

## Collector 2.0

Let's start with a clone of `Collector<T,A,R>` called `Gatherer<T,A,R>`:

```java
/** @param <T> the element type
 *  @param <A> the (mutable) intermediate accumulation type
 *  @param <R> the (probably immutable) final accumulation type
 */
interface Gatherer<T,A,R> {
    Supplier<A> supplier();
    BiConsumer<A, T> accumulator();
    BinaryOperator<A> combiner();
    Function<A, R> finisher();
}
```

Now, we need to make it output 0...M elements instead of strictly 1.  In order
to do that, we need a way to programmatically output elements from the
`accumulator` to make it incremental (and has the added benefit that it would be
able to run depth-first).  Adding an additional argument, a downstream handle,
to `accumulator` and `finisher` allows us to push elements downstream both for
each input, and at the end of stream. As there exists no suitable pre-existing
interface, we'll define a new interface named `Integrator` and rename `accumulator`
to the more fitting `integrator`.
Our `finisher` will also not have a useful return value, so we'll make it `void`:

```java
/** @param <T> the element type
 *  @param <A> the (mutable) intermediate accumulation type
 *  @param <R> the (probably immutable) final accumulation type
 */
interface Gatherer<T,A,R> {
    interface Integrator<A,T,R> {
        void integrate(A state, T element, Consumer<? super R> downstream);
    }
    Supplier<A> supplier();
    Integrator<A, T, R> integrator();
    BinaryOperator<A> combiner();
    BiConsumer<A, Consumer<? super> R> finisher();
}
```

Next, we need to tackle short-circuiting and add an upstream signal from each
invocation of the `integrator` so we can detect when the integration does not
want any more elements. We do this by returning a boolean from `integrate`:

```java
/** @param <T> the element type
 *  @param <A> the (mutable) intermediate accumulation type
 *  @param <R> the (probably immutable) final accumulation type
 */
interface Gatherer<T,A,R> {
    interface Integrator<A,T,R> {
        boolean integrate(A state, T element, Consumer<? super R> downstream);
    }
    Supplier<A> supplier();
    Integrator<A, T, R> integrator();
    BinaryOperator<A> combiner();
    BiConsumer<A, Consumer<? super> R> finisher();
}
```

Transitively supporting short-circuiting, i.e. that a downstream handle does
not want to receive any more elements, requires us to make the same change as
we did for `integrate`?return a `boolean` instead of `void`, and since the
only built-in candidate would be `Predicate`, which is not supposed to have
side-effects, let's introduce our own type `Sink`:

```java
/** @param <T> the element type
 *  @param <A> the (mutable) intermediate accumulation type
 *  @param <R> the (probably immutable) final accumulation type
 */
interface Gatherer<T,A,R> {
    interface Sink<R> {
        boolean flush(R element);
    }
    interface Integrator<A,T,R> {
        boolean integrate(A state, T element, Sink<? super R> downstream);
    }
    Supplier<A> supplier();
    Integrator<A, T, R> integrator();
    BinaryOperator<A> combiner();
    BiConsumer<A, Sink<? super R>> finisher();
}
```

Finally, we need to address parallelism.  To opt-in to parallelism we can make
the combiner optional -- we call it only for parallel executions, and if it is
not present, execution is constrained to sequential.

To demonstrate how all of the above fits together, we implement `fixedWindow(N)`
where `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.

```java
    /**
     * Gathers elements into fixed-size windows. The last window can contain fewer elements.
     * @param windowSize the size of the windows
     * @return a new gatherer which gathers elements into fixed-size windows
     * @param <T> the type of elements this Gatherer gathers
     */
    public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
        if (windowSize < 1)
            throw new IllegalArgumentException("'windowSize' must be greater than zero");
        else {
            Supplier<ArrayList<T>> supplier =
                () ->  new ArrayList<T>(windowSize);

            Integrator<ArrayList<T>, T, List<T>> integrator =
                (openWindow, element, downstream) -> {
                    if (openWindow.add(element) && openWindow.size() >= windowSize) {
                        var closedWindow = List.copyOf(openWindow);
                        openWindow.clear();
                        return downstream.flush(closedWindow);
                    } else
                        return true;
                };

            // This combiner signals that we opt-out of parallelisation
            BinaryOperator<ArrayList<T>> combiner =
                Gatherer.unsupportedCombiner();

            BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher =
                (openWindow, downstream) -> {
                    if(!openWindow.isEmpty()) {
                        downstream.flush(List.copyOf(openWindow));
                        openWindow.clear();
                    }
                };

            return Gatherer.of(supplier, integrator, combiner, finisher);
        }
    }
```

Or by implementing the `Gatherer` interface directly like so:

```java
    /**
     * Gathers elements into fixed-size windows. The last window can contain fewer elements.
     * @param windowSize the size of the windows
     * @return a new gatherer which gathers elements into fixed-size windows
     * @param <T> the type of elements this Gatherer gathers
     */
    public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
        if (windowSize < 1)
            throw new IllegalArgumentException("'windowSize' must be greater than zero");

        class FixedWindowGatherer implements Gatherer<T,ArrayList<T>,List<T>> {
            @Override
            public Supplier<ArrayList<T>> initializer() {
                return () -> new ArrayList<>(windowSize);
            }

            @Override
            public Integrator<ArrayList<T>, T, List<T>> integrator() {
                return (openWindow, element, downstream) -> {
                    if (openWindow.add(element) && openWindow.size() >= windowSize) {
                        var closedWindow = List.copyOf(openWindow);
                        openWindow.clear();
                        return downstream.flush(closedWindow);
                    } else
                        return true;
                };
            }

            @Override
            public BinaryOperator<ArrayList<T>> combiner() {
                return Gatherer.unsupportedCombiner();
            }

            @Override
            public BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher() {
                return (openWindow, downstream) -> {
                    if(!openWindow.isEmpty()) {
                        downstream.flush(List.copyOf(openWindow));
                        openWindow.clear();
                    }
                };
            }
        }
        return new FixedWindowGatherer();
    }
```

Compared to Collector, it would look like the following:

| Ordinal | Feature                  | `Collector<T,A,R>`                | `Gatherer<T,A,R>`                     |
|---------|--------------------------|-----------------------------------|---------------------------------------|
|    1    | Beginning-of-stream hook | `A supply()`                      | `A supply()`                          |
|    2    | Per element              | `void accept(A, T)`               | `boolean integrate(A, T, Sink<R>)`    |
|    3    | End-of-stream hook       | `R apply(A)`                      | `void accept(A, Sink<R>)`             |
|    4    | Parallelizability        | `A apply(A, A)`                   | `A apply(A, A)`                       |

To integrate it with `java.util.stream.Stream` we add the following method to
it: `Stream<R> gather(Gatherer<T,?,R> gatherer)`

Now we can use our `fixedWindow` Gatherer:

```java
jshell> Stream.iterate(0, i -> i + 1).limit(10).gather(fixedWindow(2)).toList();
$1 ==> [[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]]
```

Gatherer now provides all features:

| Ordinal | Feature                  | Using Gatherer          | Explanation                                                                            |
|---------|--------------------------|-------------------------|----------------------------------------------------------------------------------------|
|    1    | Intermediate operation   | Yes                     | A Gatherer's output is the following operation's input                                 |
|    2    | Incremental operation    | Yes                     | A Gatherer can produce elements in response to consuming elements                      |
|    3    | Stateful operation       | Yes                     | A Gatherer supplies its own state, which can be Void/null if stateless                 |
|    4    | N:M inputs-to-outputs    | Yes                     | A Gatherer can consume and produce any number of elements                              |
|    5    | Prefix consumption       | Yes                     | A Gatherer can signal that it is done by returning `false` from its `integrate`-method |
|    6    | Beginning-of-stream hook | Yes                     | A Gatherer can run logic when creating its initial state                               |
|    7    | End-of-stream hook       | Yes                     | A Gatherer's `finisher` is invoked at the end of input                                 |
|    8    | Opt-in parallelizability | Yes                     | A Gatherer's `combiner` is optional                                                    |

## Summary

None of the current candidates for a user-extensible API for generic
intermediate stream operations fit the set of requirements, but `Collector`
can form an excellent basis for a new construct, called `Gatherer`,
which after a limited set of modifications checks all the boxes:

| Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector | Using Gatherer |
|---------|--------------------------|---------------------------|---------------------------|-----------------|----------------|
|    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    | Yes            |
|    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    | Yes            |
|    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             | Yes            |
|    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         | Yes            |
|    5    | Prefix consumption       | No                        | No                        | No              | Yes            |
|    6    | Beginning-of-stream hook | No                        | No                        | Yes             | Yes            |
|    7    | End-of-stream hook       | No                        | No                        | Yes             | Yes            |
|    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   | Yes            |

As it turned out, we were a short hop away from a generic, stand-alone,
reusable, parallelizable, API for intermediate operations all along!

## But wait ? there's more

While the aforementioned solution contains the bare-minimum to meet our requirements,
the following will provide some significant quality-of-life improvements.

### Compositionality

The astute reader may have noticed that by adding the `gather(Gatherer)`-method on `Stream`,
one can in-effect **compose** `Gatherer`s together:

```java
Gatherer<Integer,?,String> someGatherer = ?;
Gatherer<String,?,Long> someOtherGatherer = ?;
Stream<Long> stream = Stream.of(1).gather(someGatherer).gather(someOtherGatherer);
```

As it turns out, it is possible to define a `default Gatherer andThen(Gatherer)`-method on `Gatherer` which composes `Gatherer`s:

```java
Gatherer<Integer,?,String> someGatherer = ?;
Gatherer<String,?,Long> someOtherGatherer = ?;
Gatherer<Integer,?,Long> gatherer = someGatherer.andThen(someOtherGatherer);
```

This makes it possible to both de-couple operations from their use-sites,
as well as create more sophisticated `Gatherer`s from simple ones.

But that's not all?by introducing a `default Collector collect(Collector)`-method
it is also possible to compose a `Gatherer` with a `Collector`,
and the result is another `Collector`:

```java
Gatherer<Integer,?,String> someGatherer = ?;
Gatherer<String,?,Long> someOtherGatherer = ?;
Collector<Long,?,List<Long>> someGatherer.andThen(someOtherGatherer).collect(Collectors.toList());
```

All of this together, it is now possible to build `Stream`-processing:
"source-to-destination" using `Stream.gather(?).gather(?).gather(?)`;
"intermediaries-first" using `gatherer.andThen(?).andThen(?);` and,
"destination-to-source" using `gatherer.collect(otherGatherer.collect(?))`.

### Familiarity

Since `Gatherer` is an evolution of `Collector` there's a clear on-ramp
for any and all Java developers who are already familiar with `Collector`.

### Reusability

`Gatherer`s, by virtue of being stand-alone, reusable, intermediaries,
paired with compositionality and opt-in parallelization, allows for transformations
to be created once and maintained in a single place, no matter if it is going to be
used as a `Collector`, a `Gatherer`, or a `Stream`.

### Optimizability

`Collector` has the notion of `Characteristics`, a `Set` of flags which describes them.
This information can then be used by the underlying machinery which uses them
to optimize their evaluation. The same approach can be used for `Gatherer`s.

### Summary 2.0

Taking all of the above into consideration, we end up with a definition like the following:

```java
/** @param <T> the element type
 *  @param <A> the (mutable) intermediate accumulation type
 *  @param <R> the (probably immutable) final accumulation type
 */
interface Gatherer<T,A,R> {

    interface Sink<R> {
        boolean flush(R element);
    }

    interface Integrator<A,T,R> {
        boolean integrate(A state, T element, Sink<? super R> downstream);
    }

    enum Characteristics {
        GREEDY,          // Never short-circuits
        SIZE_PRESERVING, // Emits exactly once per input element
        STATELESS;       // No need to initialize or combine state
    }

    Supplier<A> supplier();
    Integrator<A, T, R> integrator();
    BinaryOperator<A> combiner();
    BiConsumer<A, Sink<? super R>> finisher();
    Set<Characteristics> characteristics();

    default <AA, RR> Gatherer<T,?,RR> andThen(Gatherer<R,AA,RR> that) {
        // Gatherers is analoguous to Collectors
        return Gatherers.Composite.of(this, that);
    }

    default <RR> Collector<T,?,RR> collect(Collector<R, ?, RR> collector) {
        // Gatherers is analoguous to Collectors
        return Gatherers.GathererCollector.of(this, collector);
    }
}
```

## Appetizers

The following examples showcase how `Gatherer` can be used to implement a diverse set
of pre-existing, and future, intermediate operations for `Stream`s.

### How to implement `map(mapper)`

```java
public final static <T,R> Gatherer<T, ?, R> map(Function<? super T, ? extends R> mapper) {
    return Gatherer.of(
        () -> (Void)null,
        (nothing, element, downstream) ->
            downstream.flush(mapper.apply(element)),
        (l,r) -> l,
        (nothing, downstream) -> {}
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(map(i -> i + 1)).toList()
$1 ==> [2, 3, 4, 5]
```

### How to implement `flatMap(mapper)`

```java
public final static <T,R> Gatherer<T, ?, R> flatMap(Function<? super T, ? extends Stream<R>> mapper) {
    return Gatherer.of(
        () -> (Void)null,
        (nothing, element, downstream) -> {
            try(Stream<? extends R> s = mapper.apply(element)) {
                return s == null || s.sequential().allMatch(downstream::flush);
            }
        },
        (l,r) -> l,
        (nothing, downstream) -> {}
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(flatMap(i -> Stream.of(i + 1))).toList()
$1 ==> [2, 3, 4, 5]
```

### How to implement `takeWhile(predicate)`

```java
public final static <T> Gatherer<T, ?, T> takeWhile(Predicate<? super T> predicate) {
    return Gatherer.of(
        () -> (Void)null,
        (nothing, element, downstream) ->
            predicate.test(element) && downstream.flush(element),
        (l, r) -> l,
        (nothing, downstream) -> {}
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(takeWhile(i -> i < 3)).toList()
$1 ==> [1, 2]
```

### How to implement `limit(N)`

```java
public static <M> Gatherer<M, ?, M> limit(long limit) {
    if (limit < 0)
        throw new IllegalArgumentException("'limit' has to be non-negative");

    class At { long n = 0; }
    return Gatherer.of(
            At::new,
            (at, element, downstream) ->
                at.n < limit && downstream.flush(element) && ++at.n < limit,
            Gatherer.unsupportedCombiner(),
            (at, downstream) -> {}
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(limit(2)).toList()
$1 ==> [1, 2]
```

### How to implement prefix `scanLeft`

```java
public static <T,R> Gatherer<T,?,R> scanLeft(R initial, BiFunction<R,T,R> scanner) {
    class State { R current = initial; }
    return Gatherer.of(
            State::new,
            (state, element, downstream) ->
                downstream.flush(state.current = scanner.apply(state.current, element)),
            Gatherer.unsupportedCombiner(),
            (state, downstream) -> {}
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(scanLeft("'", (acc, elem) -> acc + elem + "'")).toList()
$1 ==> ['1', '1'2', '1'2'3', '1'2'3'4']
```

### How to implement `fold(initial, folder)`

```java
public static <T> Gatherer<T,?,T> fold(T initial, BinaryOperator<T> folder) {
    class State { T current = initial; }
    return Gatherer.of(
        State::new,
        (state, element, downstream) -> {
            state.current = folder.apply(state.current, element);
            return true;
        },
        (l, r) -> {
            l.current = folder.apply(l.current, r.current);
            return l;
        },
        (state, downstream) -> downstream.flush(state.current)
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(fold(0, (acc, elem) -> acc + elem)).toList()
$1 ==> [10]
```

### How to implement `foldLeft(initial, folder)`

```java
public static <T,R> Gatherer<T,?,R> foldLeft(R initial, BiFunction<R,T,R> folder) {
    class State { R current = initial; }
    return Gatherer.of(
        State::new,
        (state, element, downstream) -> {
            state.current = folder.apply(state.current, element);
            return true;
        },
        Gatherer.unsupportedCombiner(),
        (state, downstream) -> downstream.flush(state.current)
    );
}
```

```java
jshell> Stream.of(1,2,3,4).gather(foldLeft(0L, (acc, elem) -> acc + elem)).toList()
$1 ==> [10]
```

### How to implement `deduplicateAdjacent()`

```java
public static <T> Gatherer<T,?,T> deduplicateAdjacent() {
    class State { T prev; boolean hasPrev; }
    return Gatherer.of(
        State::new,
        (state, element, downstream) -> {
            if (!state.hasPrev) {
                state.hasPrev = true;
                state.prev = element;
                return downstream.flush(element);
            } else if (!Objects.equals(state.prev, element)) {
                state.prev = element;
                return downstream.flush(element);
            } else {
                return true; // skip duplicate
            }
        },
        Gatherer.unsupportedCombiner(),
        (state, downstream) -> {}
    );
}
```

```java
jshell> Stream.of(1,2,2,3,2,4).gather(deduplicateAdjacent()).toList()
$1 ==> [1, 2, 3, 2, 4]
```

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230627/a7811988/attachment-0001.htm>

From naoto at openjdk.org  Tue Jun 27 17:15:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 17:15:10 GMT
Subject: [jdk21] RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE)
 separated with hyphen, not dash
Message-ID: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>

Hi all,

This pull request contains a backport of commit [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen.

Thanks!

-------------

Commit messages:
 - Backport ec45bd64d504d579aef54c924fb8ca75a944036f

Changes: https://git.openjdk.org/jdk21/pull/70/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=70&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310182
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk21/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/70/head:pull/70

PR: https://git.openjdk.org/jdk21/pull/70

From dfuchs at openjdk.org  Tue Jun 27 17:22:21 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 27 Jun 2023 17:22:21 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer
In-Reply-To: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
Message-ID: <OttL0-qq64Nf6LxXtpMQMdVvq0KVAld_BBK61TJJBR0=.5e1700a9-d27e-458d-92b8-62e2ef64351d@github.com>

On Tue, 27 Jun 2023 15:34:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Docs only update to add a missing `@throws StructureViolationException` and make it clearer when the exception is thrown. In the future we might re-visit this so that the description is in one place rather than in each method.

I like the new text, it reads well. There's a typo that has been copy pasted several times however.

src/java.base/share/classes/java/lang/ScopedValue.java line 403:

> 401:          * invoked directly or indirectly by the operation creates a {@link StructuredTaskScope}
> 402:          * but does not {@linkplain StructuredTaskScope#close() close} it, then it is detected
> 403:          * as a <em>structure violation</em> when the operation completes (normally or ith an

Suggestion:

         * as a <em>structure violation</em> when the operation completes (normally or with an

src/java.base/share/classes/java/lang/ScopedValue.java line 433:

> 431:          * invoked directly or indirectly by the operation creates a {@link StructuredTaskScope}
> 432:          * but does not {@linkplain StructuredTaskScope#close() close} it, then it is detected
> 433:          * as a <em>structure violation</em> when the operation completes (normally or ith an

Suggestion:

         * as a <em>structure violation</em> when the operation completes (normally or with an

src/java.base/share/classes/java/lang/ScopedValue.java line 497:

> 495:          * invoked directly or indirectly by the operation creates a {@link StructuredTaskScope}
> 496:          * but does not {@linkplain StructuredTaskScope#close() close} it, then it is detected
> 497:          * as a <em>structure violation</em> when the operation completes (normally or ith an

Suggestion:

         * as a <em>structure violation</em> when the operation completes (normally or with an

src/java.base/share/classes/java/lang/ScopedValue.java line 565:

> 563:      * invoked directly or indirectly by the operation creates a {@link StructuredTaskScope}
> 564:      * but does not {@linkplain StructuredTaskScope#close() close} it, then it is detected
> 565:      * as a <em>structure violation</em> when the operation completes (normally or ith an

Suggestion:

     * as a <em>structure violation</em> when the operation completes (normally or with an

src/java.base/share/classes/java/lang/ScopedValue.java line 601:

> 599:      * invoked directly or indirectly by the operation creates a {@link StructuredTaskScope}
> 600:      * but does not {@linkplain StructuredTaskScope#close() close} it, then it is detected
> 601:      * as a <em>structure violation</em> when the operation completes (normally or ith an

Suggestion:

     * as a <em>structure violation</em> when the operation completes (normally or with an

src/java.base/share/classes/java/lang/ScopedValue.java line 636:

> 634:      * invoked directly or indirectly by the operation creates a {@link StructuredTaskScope}
> 635:      * but does not {@linkplain StructuredTaskScope#close() close} it, then it is detected
> 636:      * as a <em>structure violation</em> when the operation completes (normally or ith an

Suggestion:

     * as a <em>structure violation</em> when the operation completes (normally or with an

-------------

PR Review: https://git.openjdk.org/jdk/pull/14679#pullrequestreview-1501483319
PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1244091134
PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1244092954
PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1244093522
PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1244094318
PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1244095201
PR Review Comment: https://git.openjdk.org/jdk/pull/14679#discussion_r1244095763

From lancea at openjdk.org  Tue Jun 27 17:24:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Jun 2023 17:24:06 GMT
Subject: RFR: JDK-8310975 java.util.FormatItemModifier should not be
 protected
In-Reply-To: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
References: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
Message-ID: <_8Bk9Pnn_XEPPxa2HSpidz-uM48G0l6oMi__RcR4R_4=.ffc6f7d9-378f-40ce-a9b5-f8730296e3e4@github.com>

On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501494580

From alanb at openjdk.org  Tue Jun 27 17:25:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 17:25:03 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer
In-Reply-To: <OttL0-qq64Nf6LxXtpMQMdVvq0KVAld_BBK61TJJBR0=.5e1700a9-d27e-458d-92b8-62e2ef64351d@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
 <OttL0-qq64Nf6LxXtpMQMdVvq0KVAld_BBK61TJJBR0=.5e1700a9-d27e-458d-92b8-62e2ef64351d@github.com>
Message-ID: <dDnr_TiDmaBYr1OofDw2hkbp7kXbl3MXJS4bsTMXLjw=.b059a32f-a0c6-482f-85b9-8fdd29d1147d@github.com>

On Tue, 27 Jun 2023 17:19:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I like the new text, it reads well. There's a typo that has been copy pasted several times however.

Thanks, I noticed this when looking at the generated javadoc but didn't commit the change to fix. I'll fix it now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14679#issuecomment-1609934807

From lancea at openjdk.org  Tue Jun 27 17:26:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Jun 2023 17:26:21 GMT
Subject: Integrated: 8310828: java.sql java.sql.rowset packages have no
 `@since` info
In-Reply-To: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
References: <dKYd3LciqITub7JJ5HLaIONqlMtWDwPPUZZKmKnZ0EQ=.fcf43ca9-8c86-483e-8004-634362949ec2@github.com>
Message-ID: <ysYThz_6l6duGiEM-BJJRqwevaiFzT0CEVBwx7Mk0tE=.87b0301f-3378-499b-b858-d5cb8ec2bd35@github.com>

On Mon, 26 Jun 2023 13:00:31 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial change which adds the `@since` javadoc tag to the various ` java.sql `and `java.sql.rowset` packages.
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: fb283dff
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb283dff04a6fe11c8a7d44498ddd2075234e4dd
Stats:     19 lines in 7 files changed: 7 ins; 4 del; 8 mod

8310828: java.sql java.sql.rowset packages have no `@since` info

Reviewed-by: naoto, iris, darcy, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/14652

From duke at openjdk.org  Tue Jun 27 17:30:35 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 17:30:35 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v29]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <E7J7a0jaBhMb-x3I6fFcP5iCidb5tK_Y6YRjyUFINIo=.831c7b55-56d8-492e-ad5d-1d8c17b3f800@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  revert to HexDigits.DIGITS, keep this PR as simple as possible.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/b81f12d1..4a4c64be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=27-28

  Stats: 182 lines in 3 files changed: 63 ins; 99 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Tue Jun 27 17:30:35 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 17:30:35 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]
In-Reply-To: <G3lEcvrqzUG0RTuQJuIzzp8ZI0Rg29y5oMsKbF_pn6s=.20892e3b-6ca2-48ea-8f8a-a05e3fc50ef2@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <eukR_kqpIeuZsmPrUguE39qjv3L74GnKTyLC_Wtouz0=.46d19cb0-e097-440e-bfdf-235039ec46a2@github.com>
 <lpCY_edpm5SZ8XcqEQZuYZhOaYTxPIwbaxKnQhXv61w=.2241c941-a8a8-4721-b5e4-13e13f256853@github.com>
 <-Rnjq4GquO8Hc1SSB20K8KDB0tvUL05-5w6tnFL_TcM=.303c15b0-8bd2-4b2d-84f4-d16cf27864d6@github.com>
 <G3lEcvrqzUG0RTuQJuIzzp8ZI0Rg29y5oMsKbF_pn6s=.20892e3b-6ca2-48ea-8f8a-a05e3fc50ef2@github.com>
Message-ID: <1IsDv2X8efpOeZ71Bu9oqHmk-1364V8AY6OBvlCivNY=.3f98196a-9523-4ed8-8a30-00a1e471fb86@github.com>

On Tue, 27 Jun 2023 16:35:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Wenshao hopes to use this array for other optimizations in `java.lang` in the future.
> > But as for this PR, I suggest wenshao not to do so much. I suggest moving `DIGITS` back to `HexDigits` first to make the modifications in this PR smaller. Reducing modifications helps with faster review.
> > When you need to optimize the classes in `java.lang`, we will continue to discuss how to share these arrays more safely and efficiently.
> 
> Let's keep this PR as simple as possible. Right now, it's up to 100 comments and 27 iterations, it's annoying to be sending new contributor Wenshao in different directions. Future work that would allow safer sharing of arrays is future work, let's keep this PR as simple as possible. Not all applications use UUID.

good suggestion, it has been changed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1609938471

From alanb at openjdk.org  Tue Jun 27 17:33:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Jun 2023 17:33:13 GMT
Subject: RFR: 8310892: ScopedValue throwing StructureViolationException
 should be clearer [v2]
In-Reply-To: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
References: <Gx7CEUhkRn3ykiF7PhJnfMjecw3mTrr3fXFEuOaJIoM=.3c6a7a3b-a445-45a0-9353-5434b6b7e853@github.com>
Message-ID: <CfwhC_HOJvVr1FVrFOt8t0-68oGS1BvNLvocVWD9syE=.14f27971-ac36-4f31-b7e6-6e0ea33c868b@github.com>

> Docs only update to add a missing `@throws StructureViolationException` and make it clearer when the exception is thrown. In the future we might re-visit this so that the description is in one place rather than in each method.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  s/ ith/with/

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14679/files
  - new: https://git.openjdk.org/jdk/pull/14679/files/ab2b91fb..08158fe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14679&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14679&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14679/head:pull/14679

PR: https://git.openjdk.org/jdk/pull/14679

From duke at openjdk.org  Tue Jun 27 17:44:23 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Tue, 27 Jun 2023 17:44:23 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v30]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <Iid5cCoa8j0VeEGbKsDIpoqnzYtCPD4-5ur5fWXsaMA=.e5af8cce-ce61-4e40-8c43-fbdeb5809ff0@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  remove unused import, and fix comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/4a4c64be..26f3a6a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=28-29

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From liach at openjdk.org  Tue Jun 27 17:44:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 17:44:25 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v29]
In-Reply-To: <E7J7a0jaBhMb-x3I6fFcP5iCidb5tK_Y6YRjyUFINIo=.831c7b55-56d8-492e-ad5d-1d8c17b3f800@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <E7J7a0jaBhMb-x3I6fFcP5iCidb5tK_Y6YRjyUFINIo=.831c7b55-56d8-492e-ad5d-1d8c17b3f800@github.com>
Message-ID: <nWpm13G1cmC3gk5g5kQQ0DawfoI-q9zrL0Di4zx8dWE=.6001af3f-d79a-47bd-aedf-7b8cb803ce48@github.com>

On Tue, 27 Jun 2023 17:30:35 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert to HexDigits.DIGITS, keep this PR as simple as possible.

src/java.base/share/classes/java/util/HexDigits.java line 33:

> 31: 
> 32: import static jdk.internal.digits.Hex256.hex256;
> 33: 

Suggestion:


This is now redundant and causes build failure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1244118063

From rriggs at openjdk.org  Tue Jun 27 17:47:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 17:47:10 GMT
Subject: [jdk21] RFR: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
In-Reply-To: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
References: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
Message-ID: <C6Nzks8AYjHxUu3DHFBuXhaXInFjC_TijGfyu24QVs0=.2d619f28-1dbc-455e-968f-b3227dbf9077@github.com>

On Tue, 27 Jun 2023 17:07:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen.
> 
> Thanks!

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/70#pullrequestreview-1501531725

From rriggs at openjdk.org  Tue Jun 27 17:50:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 17:50:09 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond [v2]
In-Reply-To: <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
 <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
Message-ID: <C4dH8EvQbgNWuZTxDBRKEvVvrRi2O2nLDYauj12Vzhk=.d61a3363-06cd-4483-b97c-92dd21e437e2@github.com>

On Tue, 27 Jun 2023 16:34:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8310232-TickClock-ArithExp
>  - Removed bugid from the test class description
>  - refactor return statement
>  - 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14657#pullrequestreview-1501535673

From iris at openjdk.org  Tue Jun 27 17:50:12 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 27 Jun 2023 17:50:12 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond [v2]
In-Reply-To: <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
 <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
Message-ID: <Rb_1nd7OWVr2xRbxyg6MWGm39MLHlaMt7-vOnGT8FBo=.8af92d8a-004c-404e-ad1c-aa07c5c2447f@github.com>

On Tue, 27 Jun 2023 16:34:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8310232-TickClock-ArithExp
>  - Removed bugid from the test class description
>  - refactor return statement
>  - 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14657#pullrequestreview-1501537487

From rriggs at openjdk.org  Tue Jun 27 17:52:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 17:52:16 GMT
Subject: Integrated: 8308452: Extend internal Architecture enum with byte order
 and address size
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <65YsqsuxTzKYGbnhKYN2Zm181Tn5c6RQCzTM0rjz2oo=.ea444c8c-842d-4b87-ad60-1127ade9622e@github.com>

On Fri, 19 May 2023 19:19:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

This pull request has now been integrated.

Changeset: d6dd0dc3
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6dd0dc3e06d42f108fe80920e1102d47a5aa583
Stats:     191 lines in 5 files changed: 121 ins; 46 del; 24 mod

8308452: Extend internal Architecture enum with byte order and address size

Reviewed-by: mdoerr, jpai, mchung, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/14063

From rgiulietti at openjdk.org  Tue Jun 27 17:55:07 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 27 Jun 2023 17:55:07 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v3]
In-Reply-To: <YBcaptP9c3hy3LU_sEcojXFwMsR6rlur041f4Jbr-IQ=.5f06bb59-32c3-4151-9ab3-49fdbe03bafd@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <YBcaptP9c3hy3LU_sEcojXFwMsR6rlur041f4Jbr-IQ=.5f06bb59-32c3-4151-9ab3-49fdbe03bafd@github.com>
Message-ID: <7aRbdfE9EaSEOhdB_gRzmap7EwuCg59wRLZ_EwqF1w4=.2be41683-6acc-4e69-bdbc-1ac90f0551c0@github.com>

On Wed, 21 Jun 2023 16:29:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify return values of date time classes

Most modern authors in math topics use positive to mean > 0, negative to mean < 0, and 0 is neither.

In some contexts, like in the IEEE 754 standard for floating-point numbers, there are both distinguishable positive and a negative binary zeros. There's no "unsigned" or "agnostic" zero there.

The natural numbers include 0 in foundational topics like set theory (where 0 is _defined_ as the empty set), and exclude it in others.

BTW, [math.net](https://www.math.net/positive-numbers) contradicts itself later on the same page. In the "Is 0 positive or negative?" section it states "Positive numbers are defined as any number that is greater than zero".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1609970331

From rriggs at openjdk.org  Tue Jun 27 18:01:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 18:01:07 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
Message-ID: <PzhyzrFLSTPH_UHODIsBZnLghkwlgz-dDEpqKN0n-BQ=.7cd226ca-e406-4309-b6de-bd0608890811@github.com>

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo <duke at openjdk.org> wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

I don't think this is a productive change. 
It takes a local inconvenience try/catch and spreads the impact over multiple files and packages as well as bulking up JLA.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1609977623

From naoto at openjdk.org  Tue Jun 27 18:10:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 18:10:05 GMT
Subject: [jdk21] Integrated: 8310182: DateTimeFormatter date formats
 (ISO_LOCAL_DATE) separated with hyphen, not dash
In-Reply-To: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
References: <37PkhcPAxxggpFF5nIuQdrSailiB7Kl2cRKJqNfQsoY=.f9d71967-f0aa-481c-80b0-a78b53dd04b6@github.com>
Message-ID: <7uJJ466Na_MqizqkWWwUvxJSDKdDUEQXKLgPe9tiEmY=.10a177dd-5bc8-441b-a89b-b8d4494ce203@github.com>

On Tue, 27 Jun 2023 17:07:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen.
> 
> Thanks!

This pull request has now been integrated.

Changeset: df26258d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/df26258d80ece4a836f873660adbf1f69a3b684b
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

Reviewed-by: rriggs
Backport-of: ec45bd64d504d579aef54c924fb8ca75a944036f

-------------

PR: https://git.openjdk.org/jdk21/pull/70

From duke at openjdk.org  Tue Jun 27 18:13:03 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 18:13:03 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <PzhyzrFLSTPH_UHODIsBZnLghkwlgz-dDEpqKN0n-BQ=.7cd226ca-e406-4309-b6de-bd0608890811@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
 <PzhyzrFLSTPH_UHODIsBZnLghkwlgz-dDEpqKN0n-BQ=.7cd226ca-e406-4309-b6de-bd0608890811@github.com>
Message-ID: <PdBYPRVubsA8qIQCY08uy9Vi5fm6hS1dMbmjdIMvPMo=.8eb73e7a-b506-4d69-af48-3f6e4925f04d@github.com>

On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It takes a local inconvenience try/catch and spreads the impact over multiple files and packages as well as bulking up JLA.

I don't quite understand what you mean.

The main goal of this PR is to get rid of those annoying try-catch, but it looks like you misunderstood this PR?

My English is poor, please forgive me if I misunderstood this sentence of yours.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1609997263

From liach at openjdk.org  Tue Jun 27 18:13:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 18:13:03 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <PzhyzrFLSTPH_UHODIsBZnLghkwlgz-dDEpqKN0n-BQ=.7cd226ca-e406-4309-b6de-bd0608890811@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
 <PzhyzrFLSTPH_UHODIsBZnLghkwlgz-dDEpqKN0n-BQ=.7cd226ca-e406-4309-b6de-bd0608890811@github.com>
Message-ID: <VcfnVCXjsvhjSpmdkIDhDAtX1rSX0FE91pqO97AHc1A=.405dd53a-c537-4260-aae4-aae840cde7ef@github.com>

On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I don't think this is a productive change. It takes a local inconvenience try/catch and spreads the impact over multiple files and packages as well as bulking up JLA.

By this rationale, newStringUTF8NoRepl should be removed as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1609997762

From mchung at openjdk.org  Tue Jun 27 18:16:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Jun 2023 18:16:05 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v4]
In-Reply-To: <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>
Message-ID: <17hhGoEdIrIWgJHVLc2OOOk5Cb7VP8NLGVyJ7XS8bKU=.cc2042dd-172c-4f1c-8c93-1fac096bc0c3@github.com>

On Tue, 27 Jun 2023 15:20:33 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageTask, JlinkTask and VersionPropsPlugin

LGTM

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12281#pullrequestreview-1501583746

From mchung at openjdk.org  Tue Jun 27 18:21:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Jun 2023 18:21:12 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v6]
In-Reply-To: <3Z3DYABGeTReZFPnoDf0eR5MSXsB0cDAT1XRcH2rohg=.02b2c1d0-f8d8-4023-8b98-82d427d00baa@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <Ah0QMlSl066UTJchNfiI6ysoe3fydac5WVoO-5FH0lM=.2ae13260-dcc3-4d58-8bcd-fe14f0c910f4@github.com>
 <IvEdvgRhu023lbcbdGLQHq_F67lDTIEcC4ZMbg_FPfI=.976bafe1-1b40-443f-9318-25e11e0c9fa9@github.com>
 <qZWy3TGlm4R10qE2Wrypppx_0z9OJTo0AaMuClP851g=.c567d0e4-0516-44b9-bde5-c8340af7e911@github.com>
 <syzLD5nzy1Bqin0Gkt98Bs73vse7anYQyfsU6uvhAA4=.a151d6c0-6614-46be-8b39-ea58cdf527e7@github.com>
 <EhQ2_aZuRS7VPxl37PXohAPnEuw0r9zB--htsea9N48=.b97c35d4-1ae4-446b-8baf-16248678350e@github.com>
 <1uuAw9wugPssRCZAZg_HjrFLIdFtl6YuXLkmDrIKHQo=.cf8cedb0-7163-4b51-a4e4-02f1a7a3fd29@github.com>
 <3Z3DYABGeTReZFPnoDf0eR5MSXsB0cDAT1XRcH2rohg=.02b2c1d0-f8d8-4023-8b98-82d427d00baa@github.com>
Message-ID: <CWrEmKI3edtoTnOXoxMalEoTLkiJJl03PLkce3nYEnc=.fc540511-5e34-4219-867b-e11213a8ed63@github.com>

On Mon, 26 Jun 2023 22:36:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `MethodType::descriptorString` refers to method descriptor and `Class::descriptorString` refers to class descriptor.   I don't think it helps to say "produce identical class descriptors in method descriptors".
>
> I think we can put it simple:
> "Two distinct classes which share a common name but have different class loaders cannot be distinguished in descriptor strings"
> which stands for both class and method descriptors. How does this sound?

What about "Two distinct {@code MethodType} objects can have an identical descriptor string as distinct classes can have the same name but different class loaders."?

This api note basically says that from a given descriptor string, `fromMethodDescriptorString` may produce a different `MethodType` with a different class loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14411#discussion_r1244169695

From naoto at openjdk.org  Tue Jun 27 18:24:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 18:24:05 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale [v4]
In-Reply-To: <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>
Message-ID: <pl5VXZSOyK45PAtN-yitbj6OA5Ld0DqqzDVXn6hrKM4=.e41e8599-bbe8-4f5c-877f-5e43b2e791f4@github.com>

On Tue, 27 Jun 2023 15:20:33 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageTask, JlinkTask and VersionPropsPlugin

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12281#pullrequestreview-1501594147

From tprinzing at openjdk.org  Tue Jun 27 18:32:05 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 27 Jun 2023 18:32:05 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com>
Message-ID: <Oo5AYrlXuEwsLMkgfJbQFu9H7g9_1-ng1CfncdLAHeg=.e763b44c-a1b8-4fef-acda-828f24004726@github.com>

On Thu, 22 Jun 2023 10:21:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
> 
>> 406:     @Override
>> 407:     public int read(ByteBuffer buf) throws IOException {
>> 408:         if (!SocketReadEvent.enabled()) {
> 
> The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR.

I've created https://bugs.openjdk.org/browse/JDK-8310978 to drive the future PR to support the missing code paths

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1244182424

From tprinzing at openjdk.org  Tue Jun 27 18:45:04 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 27 Jun 2023 18:45:04 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <EAJkf3t-7yNk3CRvC2oRsjW5dJ1-ZX-hODYy2ShdQHE=.51608e32-7dff-4c92-aaf3-5d25c62943a5@github.com>
 <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>
Message-ID: <tQd7zTrrRWOGeM6bl2Km_WJwSepkhSAx69444ZaMKBY=.5b449771-6a0d-4754-92da-d1c109b6eb41@github.com>

On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> In cases where the implRead/implWrite call throws an exception, shouldn't the event contain that exception, or at least exception message? If it doesn't should it be emitted at all, or should another event be emitted instead?

Added issue https://bugs.openjdk.org/browse/JDK-8310979 to add a field to SocketReadEvent and SocketWriteEvent in a separate PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1610037645

From jlaskey at openjdk.org  Tue Jun 27 18:48:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 27 Jun 2023 18:48:16 GMT
Subject: Integrated: JDK-8310975 java.util.FormatItemModifier should not be
 protected
In-Reply-To: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
References: <5vMkEydBSkwwNBOb0KV6muRESjybxRSYiXWjlW8QmrA=.c58b2193-fa8a-419e-a7f7-7ebb02b808a1@github.com>
Message-ID: <yf8igXSMEtNvRtSHFvLxMuFVNSjHqGUcb2-mEmdBiVc=.a989f603-d852-45b6-966e-f6236bd2f327@github.com>

On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

This pull request has now been integrated.

Changeset: 315242b7
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/315242b7417a4774765f139b841b385dc7c94c50
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310975: java.util.FormatItemModifier should not be protected

Reviewed-by: alanb, darcy, iris, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/14681

From jlaskey at openjdk.org  Tue Jun 27 19:04:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 27 Jun 2023 19:04:24 GMT
Subject: [jdk21] RFR: 8310975: java.util.FormatItemModifier should not be
 protected
Message-ID: <9OiynqbNLuFCwNO8r3AgcT9HwjdUC-CRgvJXhCNN0Uw=.7713a7b7-5a79-46c0-bb2e-5c7bc16d9cdb@github.com>

The nested class is incorrectly marked as protected.

-------------

Commit messages:
 - Backport 315242b7417a4774765f139b841b385dc7c94c50

Changes: https://git.openjdk.org/jdk21/pull/72/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=72&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310975
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/72/head:pull/72

PR: https://git.openjdk.org/jdk21/pull/72

From darcy at openjdk.org  Tue Jun 27 19:10:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 19:10:02 GMT
Subject: [jdk21] RFR: 8310975: java.util.FormatItemModifier should not be
 protected
In-Reply-To: <9OiynqbNLuFCwNO8r3AgcT9HwjdUC-CRgvJXhCNN0Uw=.7713a7b7-5a79-46c0-bb2e-5c7bc16d9cdb@github.com>
References: <9OiynqbNLuFCwNO8r3AgcT9HwjdUC-CRgvJXhCNN0Uw=.7713a7b7-5a79-46c0-bb2e-5c7bc16d9cdb@github.com>
Message-ID: <k5SXvdr6BC9J8zYqPuGzkSLZVkN0mHgXvLrUpk4w-bg=.e0162d3c-1ef0-4bce-ac97-75bb705f284f@github.com>

On Tue, 27 Jun 2023 18:56:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/72#pullrequestreview-1501665796

From darcy at openjdk.org  Tue Jun 27 19:14:06 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 19:14:06 GMT
Subject: RFR: JDK-8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
Message-ID: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>

Typo fix. I didn't see any other instances of similar typos in the class.

-------------

Commit messages:
 - JDK-8310830: typo in the parameter name in @throws of ClassDesc::ofDescriptor

Changes: https://git.openjdk.org/jdk/pull/14683/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14683&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310830
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14683/head:pull/14683

PR: https://git.openjdk.org/jdk/pull/14683

From jlaskey at openjdk.org  Tue Jun 27 19:15:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 27 Jun 2023 19:15:07 GMT
Subject: [jdk21] Integrated: 8310975: java.util.FormatItemModifier should not
 be protected
In-Reply-To: <9OiynqbNLuFCwNO8r3AgcT9HwjdUC-CRgvJXhCNN0Uw=.7713a7b7-5a79-46c0-bb2e-5c7bc16d9cdb@github.com>
References: <9OiynqbNLuFCwNO8r3AgcT9HwjdUC-CRgvJXhCNN0Uw=.7713a7b7-5a79-46c0-bb2e-5c7bc16d9cdb@github.com>
Message-ID: <sqAYeCOx2vvgaUrVvvdF2_Lbexj0mP5m61-UWoFvjA0=.db04d63d-708f-4ef1-aa7d-d5f39273b916@github.com>

On Tue, 27 Jun 2023 18:56:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The nested class is incorrectly marked as protected.

This pull request has now been integrated.

Changeset: 033060b2
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/033060b22bfb740d25f465f0495bd9b4bea25764
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310975: java.util.FormatItemModifier should not be protected

Reviewed-by: darcy
Backport-of: 315242b7417a4774765f139b841b385dc7c94c50

-------------

PR: https://git.openjdk.org/jdk21/pull/72

From cjplummer at openjdk.org  Tue Jun 27 19:19:05 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 27 Jun 2023 19:19:05 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v4]
In-Reply-To: <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
Message-ID: <BMeqMTX0eNi2J8xMdXah2MAgL_IyWhggqueqb7DlZEU=.ee015530-c9ee-4d42-84c9-177ccba6ce82@github.com>

On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1501681509

From bpb at openjdk.org  Tue Jun 27 19:25:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Jun 2023 19:25:04 GMT
Subject: RFR: JDK-8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
In-Reply-To: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
References: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
Message-ID: <wBQf9H8Rr8fUz-vXK3Ub_tes06C3fVouOrudX7CzWXc=.d416ff9c-cc0e-4b63-a911-3215bf5a8dd8@github.com>

On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix. I didn't see any other instances of similar typos in the class.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501692413

From rriggs at openjdk.org  Tue Jun 27 19:25:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 19:25:05 GMT
Subject: RFR: JDK-8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
In-Reply-To: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
References: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
Message-ID: <_NtlMWctLOhzicV_vcFNAOOi9F1_YvcdXT6mIdD-kAA=.46443d5f-9b25-4420-8fba-5a6af41ccd20@github.com>

On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix. I didn't see any other instances of similar typos in the class.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501695302

From mchung at openjdk.org  Tue Jun 27 19:34:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Jun 2023 19:34:11 GMT
Subject: RFR: JDK-8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
In-Reply-To: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
References: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
Message-ID: <ubQIeAuowUE-MI4oDuxHdE5QOI6xYoQq6qBRb0veXPc=.05ebf5ed-5fe8-4d6c-be17-09f99660a4b1@github.com>

On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix. I didn't see any other instances of similar typos in the class.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501705496

From darcy at openjdk.org  Tue Jun 27 19:34:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 19:34:13 GMT
Subject: Integrated: JDK-8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
In-Reply-To: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
References: <jDJETEoYS7llzEt1y7SR-XlHsbs1gcHn5iaNgXjnbgI=.4b8c64d1-651c-4789-9ebe-c6b2494f4b96@github.com>
Message-ID: <0viHyaFa6WqL_8xmy2rRXezCobexnD-Qfo_R2iF93iA=.7f328353-e21c-496a-8ba3-42244e79454d@github.com>

On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix. I didn't see any other instances of similar typos in the class.

This pull request has now been integrated.

Changeset: 4bce38c6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4bce38c6d7792596879a6e1081140b698b899471
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310830: typo in the parameter name in @throws of ClassDesc::ofDescriptor

Reviewed-by: bpb, rriggs, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14683

From darcy at openjdk.org  Tue Jun 27 19:49:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 19:49:21 GMT
Subject: [jdk21] RFR: 8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
Message-ID: <7kVofqxKpoYtRmXqZZlANAcwx5uFJ6ayWWW3aWvKo2U=.1ff656ad-6314-44ad-971f-991192b1fb7f@github.com>

Doc-only typo fix.

-------------

Commit messages:
 - Backport 4bce38c6d7792596879a6e1081140b698b899471

Changes: https://git.openjdk.org/jdk21/pull/73/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=73&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310830
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/73.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/73/head:pull/73

PR: https://git.openjdk.org/jdk21/pull/73

From mchung at openjdk.org  Tue Jun 27 19:57:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Jun 2023 19:57:05 GMT
Subject: [jdk21] RFR: 8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
In-Reply-To: <7kVofqxKpoYtRmXqZZlANAcwx5uFJ6ayWWW3aWvKo2U=.1ff656ad-6314-44ad-971f-991192b1fb7f@github.com>
References: <7kVofqxKpoYtRmXqZZlANAcwx5uFJ6ayWWW3aWvKo2U=.1ff656ad-6314-44ad-971f-991192b1fb7f@github.com>
Message-ID: <ErLsVbkmApch85KFqNIfF9mqfggbID9e4joXgUMOuVw=.9c714cf1-836d-419f-997e-b525fdcd74c4@github.com>

On Tue, 27 Jun 2023 19:42:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Doc-only typo fix.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/73#pullrequestreview-1501744901

From darcy at openjdk.org  Tue Jun 27 20:00:15 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 20:00:15 GMT
Subject: [jdk21] Integrated: 8310830: typo in the parameter name in @throws of
 ClassDesc::ofDescriptor
In-Reply-To: <7kVofqxKpoYtRmXqZZlANAcwx5uFJ6ayWWW3aWvKo2U=.1ff656ad-6314-44ad-971f-991192b1fb7f@github.com>
References: <7kVofqxKpoYtRmXqZZlANAcwx5uFJ6ayWWW3aWvKo2U=.1ff656ad-6314-44ad-971f-991192b1fb7f@github.com>
Message-ID: <k-UZTZZDF8BSUJinbnPbpHDbThUlAYvLAwaq0ZaHRkA=.992f30bc-cb02-4392-b51b-a0e111914555@github.com>

On Tue, 27 Jun 2023 19:42:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Doc-only typo fix.

This pull request has now been integrated.

Changeset: 3248daee
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/3248daee85268a6a20903f95292d03e869064c96
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310830: typo in the parameter name in @throws of ClassDesc::ofDescriptor

Reviewed-by: mchung
Backport-of: 4bce38c6d7792596879a6e1081140b698b899471

-------------

PR: https://git.openjdk.org/jdk21/pull/73

From rriggs at openjdk.org  Tue Jun 27 20:01:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 20:01:12 GMT
Subject: RFR: 8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452
 failed with Method isARM()
Message-ID: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>

Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm.

-------------

Commit messages:
 - Add bugid
 - 8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452 failed with "Method isARM()..."

Changes: https://git.openjdk.org/jdk/pull/14685/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14685&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310982
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14685/head:pull/14685

PR: https://git.openjdk.org/jdk/pull/14685

From darcy at openjdk.org  Tue Jun 27 20:02:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 27 Jun 2023 20:02:05 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v3]
In-Reply-To: <YBcaptP9c3hy3LU_sEcojXFwMsR6rlur041f4Jbr-IQ=.5f06bb59-32c3-4151-9ab3-49fdbe03bafd@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
 <YBcaptP9c3hy3LU_sEcojXFwMsR6rlur041f4Jbr-IQ=.5f06bb59-32c3-4151-9ab3-49fdbe03bafd@github.com>
Message-ID: <eR_XW_QsNLMf8O16JCWT6s58I8-kp19P2RmqFj99MtY=.0cf1a6f9-6e17-4a3c-8255-5983a12a0f09@github.com>

On Wed, 21 Jun 2023 16:29:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
>> Add javadoc @see tags to isBefore and isAfter methods
>> 
>> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
>> The term "positive" is ambiguous, zero is considered positive and indicates equality.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify return values of date time classes

> 

Adding a bit more context, floating-point arithmetic is an approximation to real arithmetic. Real arithmetic has a single zero value. The signed zeros of IEEE 754 floating-point are a computational artifact.

More specifically, IEEE 754 floating-point is an approximation to the real numbers extended with infinite values. There are two ways to extend the reals with infinity: affine (signed infinities) and projective (one unsigned infinity). Early drafts of the IEEE 754 standard supported both affine and project infinity, as did the original 8087 floating-point which predated IEEE 754. The final IEEE 754 only supports signed infinities and because there are two infinities, there are two distinguished (but numerically equal) zero values.

The floating-point signum methods in the Java math library return a same-signed zero for a zero input; +1.0 is *not* returned for +0.0 and -1.0 is *not* returned for -0.0. While a zero value has a sign bit in its representation, neither zero value is "positive" or "negative" in the mathematical sense of the term.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14479#issuecomment-1610132362

From naoto at openjdk.org  Tue Jun 27 20:11:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Jun 2023 20:11:03 GMT
Subject: RFR: 8310982: jdk/internal/util/ArchTest.java fails after
 JDK-8308452 failed with Method isARM()
In-Reply-To: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
References: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
Message-ID: <ziaZwJPDx-8rQyCSjoT8M_ygxeFEdh5PifTdMMCdroo=.78a9028c-35c7-4204-9f44-7ec39fde7ed9@github.com>

On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501758826

From mchung at openjdk.org  Tue Jun 27 20:11:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 27 Jun 2023 20:11:04 GMT
Subject: RFR: 8310982: jdk/internal/util/ArchTest.java fails after
 JDK-8308452 failed with Method isARM()
In-Reply-To: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
References: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
Message-ID: <rs08l70ngAdKgoJBUwNpyEoogVYmbyTrH4ECbwNkB6o=.2642a879-367d-4689-a8ec-cfaabd7c35c0@github.com>

On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm.

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501762542

From bpb at openjdk.org  Tue Jun 27 20:11:05 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Jun 2023 20:11:05 GMT
Subject: RFR: 8310982: jdk/internal/util/ArchTest.java fails after
 JDK-8308452 failed with Method isARM()
In-Reply-To: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
References: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
Message-ID: <t_HjQ1OFJg0AySmFeDKSzQFetjEPWdPq2CLUSgfxABs=.f6a0009d-6629-4990-919e-59e12b924d11@github.com>

On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501763673

From lancea at openjdk.org  Tue Jun 27 20:11:06 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 27 Jun 2023 20:11:06 GMT
Subject: RFR: 8310982: jdk/internal/util/ArchTest.java fails after
 JDK-8308452 failed with Method isARM()
In-Reply-To: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
References: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
Message-ID: <5R-HHMEC1vplhGgIZXu2mxV2itiLOHoeJ4zurrJeeV0=.df9bd7f3-8398-4953-8476-d9147b372e81@github.com>

On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501766576

From duke at openjdk.org  Tue Jun 27 20:29:36 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 20:29:36 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v9]
In-Reply-To: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
Message-ID: <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>

> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
> 
> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
> 
> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.

Glavo has updated the pull request incrementally with one additional commit since the last revision:

  add 8310843 to @bug

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14636/files
  - new: https://git.openjdk.org/jdk/pull/14636/files/609170c0..7cfef770

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14636&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14636/head:pull/14636

PR: https://git.openjdk.org/jdk/pull/14636

From jvernee at openjdk.org  Tue Jun 27 20:46:13 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 27 Jun 2023 20:46:13 GMT
Subject: Integrated: 8310914: Remove 2 malformed java/foreign ProblemList
 entries
In-Reply-To: <W4FJ2bF5UFs5e9HQ_N8Y7DY1PyKE4-Yj5-66UqVMjt8=.332cc00e-2a81-4074-a1b9-f47871769991@github.com>
References: <W4FJ2bF5UFs5e9HQ_N8Y7DY1PyKE4-Yj5-66UqVMjt8=.332cc00e-2a81-4074-a1b9-f47871769991@github.com>
Message-ID: <z9a9xGcx51yQRoQChzo501SU0aj8i3XFo2sNkFi4YuQ=.8a7a05a6-3dd7-4465-928d-50730bfa0031@github.com>

On Mon, 26 Jun 2023 19:33:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Remove 2 malformed problem list entries. These entries are considered malformed according to [1] since they are missing a bug number. 
> 
> The `java/foreign/callarranger/TestAarch64CallArranger.java` test was removed, and the `java/foreign/TestLargeSegmentCopy.java` disables x86 in the jtreg test header using `@requires sun.arch.data.model == "64"`, so neither of these entries are needed.
> 
> Testing: `jdk_foreign` test suite (which contains these tests)
> 
> [1]: https://openjdk.org/jtreg/faq.html#what-is-a-problemlist.txt-file

This pull request has now been integrated.

Changeset: f07e396b
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f07e396bda4567fd35677704b9aa974426266363
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8310914: Remove 2 malformed java/foreign ProblemList entries

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14664

From psandoz at openjdk.org  Tue Jun 27 20:46:09 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 27 Jun 2023 20:46:09 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v11]
In-Reply-To: <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <cpzIzNZwrpRul5dYSfbiHTIe4TmHobR3c-_OJ_QxIBQ=.51c7cb98-96dc-4850-a366-6512988fbd9a@github.com>
 <JV95Ie7exgYkMv7J-qcLHEuf5DU4Ylw9Z-qnilx3Zx4=.64b3e50f-9bf6-40f3-8866-91e967943e2f@github.com>
Message-ID: <m3lo5F5vUSmQWUuraxyi-zApSfDMCa-JDDDwacLOMf4=.c492abd0-5632-4926-bd53-978c78ef1545@github.com>

On Fri, 9 Jun 2023 18:59:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove meaningless target calls and clear outdated cache as needed
>
> Something was bothering me about the current complexity with method handles and the potential interactions with indirect var handles. Its hard to reason about all the interactions so i needed to take a deeper dive, which i really should have done earlier on. Apologies if we are circling around this many times.
> 
> Since we are now leaning on `LazyInitializingVarHandle::target` to initialize I think we can just do this:
> 
>     private void initialize() {
>         UNSAFE.ensureClassInitialized(refc);
>         this.initialized = true;
>     }
> 
>     @Override
>     public MethodHandle toMethodHandle(AccessMode accessMode) {
>         if (initialized) {
>             return target.toMethodHandle(accessMode);
>         } else {
>             if (isAccessModeSupported(accessMode)) {
>                 MethodHandle mh = target.getMethodHandle(accessMode.ordinal());
>                 // Ensure target on this VH is called to initialize the class
>                 return mh.bindTo(this);
>             }
>             else {
>                 // Ensure an UnsupportedOperationException is thrown
>                 return MethodHandles.varHandleInvoker(accessMode, accessModeType(accessMode)).
>                         bindTo(this);
>             }
>         }
>     }
> 
> 
> However, construction of an indirect VH will result in initialization:
> 
>     private IndirectVarHandle(VarHandle target, Class<?> value, Class<?>[] coordinates,
>                       BiFunction<AccessMode, MethodHandle, MethodHandle> handleFactory, VarForm form, boolean exact) {
>         super(form, exact);
>         this.handleFactory = handleFactory;
>         this.target = target;
>         this.directTarget = target.target();
>         this.value = value;
>         this.coordinates = coordinates;
>     }
> 
> 
> Since this is not performance sensitive code we could check if target is an instance of `LazyInitializingVarHandle` then conditionally get it's target if initialized e.g.,
> 
>    this.directTarget = target instanceof LazyInitializingVarHandle lazyTarget ? lazyTarget.lazyTarget() : target.target();
> 
> ?

> @PaulSandoz I have thought about VarHandle a bit more. Why does getMethodHandle accept the direct target of a VarHandle when getMethodHandle itself is already specific to each VarHandle instance?

IIRC its to avoid creating an extra bound MH when used with the guards.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1610184380

From psandoz at openjdk.org  Tue Jun 27 20:51:06 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 27 Jun 2023 20:51:06 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
Message-ID: <joZ-MyP7UOSsNvk-1WCGR8HCR3uq6VfIOgAnlVEOSo8=.70681b00-abf5-4121-8599-88f8bd145f60@github.com>

On Tue, 27 Jun 2023 13:57:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
>> 
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
>> 
>> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
>> 
>> 
>> Benchmark                                            Mode  Cnt    Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback VHG changes

Latest update looks very good, i like how it has got simpler and therefore easier to understand. I agree with a focus on the correctness for the MHs, as it is quite hard to reason about all this. The initializing MHs should optimize, it just takes more work to do so.

I shall provide some minor comments inline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1610190790

From rriggs at openjdk.org  Tue Jun 27 20:58:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 20:58:37 GMT
Subject: Integrated: 8310982: jdk/internal/util/ArchTest.java fails after
 JDK-8308452 failed with Method isARM()
In-Reply-To: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
References: <GeqD3fmEx32ukF-OQ7lzfEmnEosxYvAKZPXXWbbwz74=.ea0e0007-c859-4502-a09c-fed3d6e95121@github.com>
Message-ID: <XMiusWKeumnFJv_Hk6op4xnWWvqpvIFViDyVq9wWpuk=.8b9e7d24-9435-41e3-843d-20f1b29043e8@github.com>

On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm.

This pull request has now been integrated.

Changeset: 7f094353
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f094353673f5047643a2d7b512d0de8c665f215
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452 failed with Method isARM()

Reviewed-by: naoto, mchung, bpb, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/14685

From jvernee at openjdk.org  Tue Jun 27 20:58:41 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 27 Jun 2023 20:58:41 GMT
Subject: [jdk21] RFR: 8310914: Remove 2 malformed java/foreign ProblemList
 entries
Message-ID: <wRCAQXGQ4Bjo_PfOUcLN8IiGs86oUqsQLoKJ55h11L4=.0d1bcb84-c893-41c1-b94a-b260755e46b6@github.com>

Hi all,

This pull request contains a backport of commit [f07e396b](https://github.com/openjdk/jdk/commit/f07e396bda4567fd35677704b9aa974426266363) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jorn Vernee on 27 Jun 2023 and was reviewed by Jaikiran Pai.

Thanks!

-------------

Commit messages:
 - Backport f07e396bda4567fd35677704b9aa974426266363

Changes: https://git.openjdk.org/jdk21/pull/75/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=75&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310914
  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/75.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/75/head:pull/75

PR: https://git.openjdk.org/jdk21/pull/75

From rriggs at openjdk.org  Tue Jun 27 21:06:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 Jun 2023 21:06:06 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
Message-ID: <H-zKdkowaf2mgMcqfRpmKUuOP8824xUZFScfHBzgva8=.f396af43-19ca-4edc-a667-51022c6d9356@github.com>

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo <duke at openjdk.org> wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

The goal of removing the try/catch from HexFormat can be solved locally by creating a private method in HexFormat that swallows the exception. There is no need to add a method to Java Lang Access or change 3 other files.
The method `newStringUTF8NoRepl` is different, it can/does throw runtime exceptions but there is no need for try/catch in that case, no change is needed there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610209289

From tprinzing at openjdk.org  Tue Jun 27 21:06:54 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 27 Jun 2023 21:06:54 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v2]
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <qYLLzG__bvQGTAsFB9n4XRy76aZZqF0xHdLmIiiCjAE=.f0f239ed-4c9a-4eb6-9df1-85b9c82ca6ee@github.com>

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  Avoid exceptions getting address/timeout for jfr event. Remove unused
  EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
  whitespace.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14342/files
  - new: https://git.openjdk.org/jdk/pull/14342/files/5faeb300..518adf8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=00-01

  Stats: 21 lines in 3 files changed: 10 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

PR: https://git.openjdk.org/jdk/pull/14342

From psandoz at openjdk.org  Tue Jun 27 21:18:12 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 27 Jun 2023 21:18:12 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
Message-ID: <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>

On Tue, 27 Jun 2023 13:57:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
>> 
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
>> 
>> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
>> 
>> 
>> Benchmark                                            Mode  Cnt    Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback VHG changes

src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 63:

> 61:     }
> 62: 
> 63:     @ForceInline

Suggestion:

    @Override
    @ForceInline

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2210:

> 2208: 
> 2209:     /**
> 2210:      * Computes a method handle that can be passed the {@linkplain #target() direct}

Suggestion:

     * Computes a method handle that can be passed the {@linkplain #asDirect() direct}

?

test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 85:

> 83: 
> 84:     @Test
> 85:     public void testInitializationOnVarHandleUse() {

I think we will need to expand this to also test operating on a MH to a VH, an indirect VH, and on a MH to indirect VH. We could do this separately.

test/micro/org/openjdk/bench/java/lang/invoke/LazyStaticColdStart.java line 92:

> 90:             });
> 91: 
> 92:             static {

Is this static block required?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244336226
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244362027
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244367651
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244367889

From duke at openjdk.org  Tue Jun 27 21:23:19 2023
From: duke at openjdk.org (duke)
Date: Tue, 27 Jun 2023 21:23:19 GMT
Subject: Withdrawn: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes
In-Reply-To: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
Message-ID: <ZAWwMth6yh7SolSFWHgUh3oWLQ9Bq5ZA9S7-1bAz-ws=.43b312e6-ef9f-4b2e-bf3f-07a5cf704330@github.com>

On Thu, 25 Aug 2022 14:32:06 GMT, Strahinja Stanojevic <duke at openjdk.org> wrote:

> This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`.
> Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process.
> We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value.
> We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html.  In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified.
> We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions.
> We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own.  
> We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/.
> 
> JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `Test...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10024

From tprinzing at openjdk.org  Tue Jun 27 21:52:08 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 27 Jun 2023 21:52:08 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - remove unused SOCKET_READ and SOCKET_WRITE configurations.
 - Merge branch 'master' into JDK-8308995
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
 - Avoid exceptions getting address/timeout for jfr event. Remove unused
   EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
   whitespace.
 - some changes from review.
   
   read0() to implRead()
   write0() to implWrite()
   trailing whitespace
 - fix copyright date
 - Added micro benchmark to measure socket event overhead.
 - Some changes from review.
   
   Append a 0 to method names being wrapped.  Use getHostString to avoid
   a reverse lookup when fetching the hostname of the remote address.
 - remove unnecessary cast
 - 8308995: Update Network IO JFR events to be static mirror events

-------------

Changes: https://git.openjdk.org/jdk/pull/14342/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=02
  Stats: 908 lines in 13 files changed: 533 ins; 369 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

PR: https://git.openjdk.org/jdk/pull/14342

From duke at openjdk.org  Tue Jun 27 22:43:05 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 27 Jun 2023 22:43:05 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <H-zKdkowaf2mgMcqfRpmKUuOP8824xUZFScfHBzgva8=.f396af43-19ca-4edc-a667-51022c6d9356@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
 <H-zKdkowaf2mgMcqfRpmKUuOP8824xUZFScfHBzgva8=.f396af43-19ca-4edc-a667-51022c6d9356@github.com>
Message-ID: <yCC8AC3-1PO48nF7_oHO42u1X6CZ29OKKUUYTvmN7oE=.f8253dca-467d-4073-b9e9-552f5f7d50ce@github.com>

On Tue, 27 Jun 2023 21:03:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The goal of removing the try/catch from HexFormat can be solved locally by creating a private method in HexFormat that swallows the exception. There is no need to add a method to Java Lang Access or change 3 other files. The method `newStringUTF8NoRepl` is different, it can/does throw runtime exceptions but there is no need for try/catch in that case, no change is needed there.

The different functions of `newStringNoRepl` from public APIs are: 1) It will try not to copy the byte array as much as possible; 2) It will throw an exception when there are  malformed or unmappable byte sequence.

Currently, `newStringNoRepl` has two use cases: 1) `HexFormat`; 2) `Files.readString`. If #14578 is merged, it will have a third use case.

If we review these use cases, we will realize that `newStringNoRepl` did not make any use cases happy:

* For `HexFormat` and [#14578](https://github.com/openjdk/jdk/pull/14578), `newStringNoRepl` is used to access `String(byte[],byte)` outside of `java.lang`.
  In this usage, `newStringNoRepl` is inconvenient to use. Users not only need to pass the charset, but also need to catch `CharacterCodingException`, even though it is actually impossible to occur.
  The purpose of this PR is to provide a better way of doing this.
* For `Files.readString`: Although `newStringNoRepl` was originally created for `Files.readString`, `Files.readString` has changed.
  Currently `Files.readString` is implemented as follows:
  
  https://github.com/openjdk/jdk/blob/7f094353673f5047643a2d7b512d0de8c665f215/src/java.base/share/classes/java/nio/file/Files.java#L3342-L3350

Obviously, for security reasons, additional check `path.getClass().getModule() != Object.class.getModule()` has been added here.

This makes `newStringNoRepl` awkward here. When reading a file containing non-ASCII characters from a non-default filesystem, an unnecessary copy of the byte array occurs here.

---

Since this method is so lame, I'm planning to do some retrofits:

1. Create a new method `newStringLatin1NoRepl`, use it to access `String(byte[],byte)` outside of `java.lang`;
2. Delete `newStringUTF8NoRepl` and add a new parameter `boolean noShare` to `newStringNoRepl`.

The new signature for `newStringNoRepl` looks like this:


String newStringNoRepl(byte[] bytes, Charset cs, boolean noShare) throws CharacterCodingException;


`newStringUTF8NoRepl(bytes)` can be replaced with `newStringNoRepl(bytes, UTF_8, true)`.

`Files.readString` can be optimized to:


return JLA.newStringNoRepl(readAllBytes(path), cs, path.getClass().getModule() != Object.class.getModule());


This is my idea. Can you take a look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610315852

From jlu at openjdk.org  Tue Jun 27 23:04:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 Jun 2023 23:04:17 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit
Message-ID: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>

Please review this PR which refactors the majority of Currency tests to use JUnit. (The leftover will be done in a separate PR).

The largest change is in `CurrencyTest.java`. To maintain the grouping of similar tests, JUnit nested classes were used.

I also believe that `Bug4512215.java` should probably be merged into `CurrencyTest.java` (since they both test getCurrencyCode() and getDefaultFractionDigits().

-------------

Commit messages:
 - Remove trailing WS in Bug4512215.java
 - Rename Bug6807534.java as CurrencyNameProviderTest.java
 - Refactor CurrencyTest.java
 - Clarify CheckDataVersion.java
 - Refactor Bug8154295.java
 - Refactor Bug6807534.java
 - Refactor Bug4512215.java

Changes: https://git.openjdk.org/jdk/pull/14682/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310923
  Stats: 613 lines in 6 files changed: 261 ins; 184 del; 168 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

PR: https://git.openjdk.org/jdk/pull/14682

From liach at openjdk.org  Tue Jun 27 23:39:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 23:39:17 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v15]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <RSIVRvKfpPfg863R4t0ugHUZFMNs1_TA5lm7wnsBsvc=.6073207c-5db1-49ec-8321-1ab55036f9ef@github.com>

> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
> 
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
> 
> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
> 
> 
> Benchmark                                            Mode  Cnt    Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/8cbb2083..469a583f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=13-14

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From liach at openjdk.org  Tue Jun 27 23:39:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 27 Jun 2023 23:39:21 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
 <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>
Message-ID: <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>

On Tue, 27 Jun 2023 21:14:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rollback VHG changes
>
> test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 85:
> 
>> 83: 
>> 84:     @Test
>> 85:     public void testInitializationOnVarHandleUse() {
> 
> I think we will need to expand this to also test operating on a MH to a VH, an indirect VH, and on a MH to indirect VH. We could do this separately.

The MH on VH case is worth considering; the indirect VH cases are already covered by `-Djava.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT=true`.

> test/micro/org/openjdk/bench/java/lang/invoke/LazyStaticColdStart.java line 92:
> 
>> 90:             });
>> 91: 
>> 92:             static {
> 
> Is this static block required?

I use this block to remove the overhead around MethodHandle and VarHandle infrastructure initialization (such as LF spinning) that is not related to any particular class; so that I measure only the impact of encountering a new class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244480647
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244480361

From liach at openjdk.org  Wed Jun 28 00:13:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 00:13:48 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v16]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <oOjEKD2kDfJoxWsHDExnkN-2PwDtODCTraNL9tZdYKM=.8db2d7de-360d-4251-8209-2677d2f1252e@github.com>

> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
> 
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
> 
> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
> 
> 
> Benchmark                                            Mode  Cnt    Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Add lazy init test for toMethodHandle

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/469a583f..8b8c672f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=14-15

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From liach at openjdk.org  Wed Jun 28 00:13:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 00:13:51 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
 <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>
 <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>
Message-ID: <3FuGPb8jn42Gl0W8hd0_69ZXlMadqVytc1_w71q0Kvg=.eb926215-3651-4c59-b1ae-20132ee3ae1d@github.com>

On Tue, 27 Jun 2023 23:33:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 85:
>> 
>>> 83: 
>>> 84:     @Test
>>> 85:     public void testInitializationOnVarHandleUse() {
>> 
>> I think we will need to expand this to also test operating on a MH to a VH, an indirect VH, and on a MH to indirect VH. We could do this separately.
>
> The MH on VH case is worth considering; the indirect VH cases are already covered by `-Djava.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT=true`.

Done; added a test case to test initialization on toMethodHandle use in latest push, passed locally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244504070

From mchung at openjdk.org  Wed Jun 28 00:18:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 00:18:12 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
Message-ID: <JK4r2naQFwKiPMtyhrPTX619ca9zXW3La6Hb9IKoa2s=.f01a5948-d711-43f6-b54e-89a182072471@github.com>

On Tue, 27 Jun 2023 13:57:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
>> 
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
>> 
>> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
>> 
>> 
>> Benchmark                                            Mode  Cnt    Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollback VHG changes

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 524:

> 522:     /**
> 523:      * Direct VH implementations call this method to
> 524:      * unwrap lazy initializing VarHandles.

Suggestion:

     * Returns the target VarHandle.   Subclasses may override this method to implement
     * additional logic for example lazily initializing the declaring class of a static field var handle.

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 533:

> 531:     /**
> 532:      * The VarHandle to be passed to {@link #getMethodHandle}, in Invokers
> 533:      * LambdaForms and VarHandleGuards.

Suggestion:

     * Returns the direct target VarHandle.   Indirect VarHandle subclasses should implement
     * this method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244410195
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1244420089

From mchung at openjdk.org  Wed Jun 28 00:18:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 00:18:09 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v16]
In-Reply-To: <oOjEKD2kDfJoxWsHDExnkN-2PwDtODCTraNL9tZdYKM=.8db2d7de-360d-4251-8209-2677d2f1252e@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <oOjEKD2kDfJoxWsHDExnkN-2PwDtODCTraNL9tZdYKM=.8db2d7de-360d-4251-8209-2677d2f1252e@github.com>
Message-ID: <F0VMOKKdErzcjXERriDL1P3hMV1kzdp3EDqX7kLzuyY=.114739b8-d714-4d29-bc87-55cbd749cc57@github.com>

On Wed, 28 Jun 2023 00:13:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
>> 
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
>> 
>> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
>> 
>> 
>> Benchmark                                            Mode  Cnt    Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add lazy init test for toMethodHandle

Good work!   I try to see how to improve the documentation to help readers to understand.  See if the suggestion helps.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13821#pullrequestreview-1501913896

From liach at openjdk.org  Wed Jun 28 00:18:25 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 00:18:25 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v10]
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <YhNEEf2bISO3rcwWYgdndyGdF71jWbh29ke0Shu4QMU=.61489b1f-8ec4-47c1-bd99-1c020f40b35e@github.com>

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html

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 15 additional commits since the last revision:

 - Merge branch 'master' into fix/descstring-spec
 - Update the distinct class note, thanks to mandy
 - Merge branch 'master' into fix/descstring-spec
 - produce identical component descriptors in descriptor strings -> cannot be distinguished in descriptor strings
 - Reword of the distinct-class-same-descriptor note
 - Missed recommendations from Alan
 - Review and updates for 8310242
 - Merge branch 'master' into fix/descstring-spec
 - Update the note for getName
 - Convert the note in fromDescriptorString to apiNote
 - ... and 5 more: https://git.openjdk.org/jdk/compare/4ca10ecb...ef7004e4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14411/files
  - new: https://git.openjdk.org/jdk/pull/14411/files/3bea7506..ef7004e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14411&range=08-09

  Stats: 10497 lines in 446 files changed: 4025 ins; 3413 del; 3059 mod
  Patch: https://git.openjdk.org/jdk/pull/14411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14411/head:pull/14411

PR: https://git.openjdk.org/jdk/pull/14411

From mchung at openjdk.org  Wed Jun 28 00:28:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 00:28:14 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v10]
In-Reply-To: <YhNEEf2bISO3rcwWYgdndyGdF71jWbh29ke0Shu4QMU=.61489b1f-8ec4-47c1-bd99-1c020f40b35e@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <YhNEEf2bISO3rcwWYgdndyGdF71jWbh29ke0Shu4QMU=.61489b1f-8ec4-47c1-bd99-1c020f40b35e@github.com>
Message-ID: <K3yCNLjXpeRUZ9LYHf-_4JcO9Gc15h5KVmHWeRqB17E=.4533837a-9c1a-4cdd-8b2a-c86328fde0ca@github.com>

On Wed, 28 Jun 2023 00:18:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/06/java.base/java/lang/invoke/MethodType.html
>
> 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into fix/descstring-spec
>  - Update the distinct class note, thanks to mandy
>  - Merge branch 'master' into fix/descstring-spec
>  - produce identical component descriptors in descriptor strings -> cannot be distinguished in descriptor strings
>  - Reword of the distinct-class-same-descriptor note
>  - Missed recommendations from Alan
>  - Review and updates for 8310242
>  - Merge branch 'master' into fix/descstring-spec
>  - Update the note for getName
>  - Convert the note in fromDescriptorString to apiNote
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/87c2be06...ef7004e4

This version looks good to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14411#pullrequestreview-1502037542

From liach at openjdk.org  Wed Jun 28 01:17:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 01:17:13 GMT
Subject: RFR: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString [v10]
In-Reply-To: <YhNEEf2bISO3rcwWYgdndyGdF71jWbh29ke0Shu4QMU=.61489b1f-8ec4-47c1-bd99-1c020f40b35e@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
 <YhNEEf2bISO3rcwWYgdndyGdF71jWbh29ke0Shu4QMU=.61489b1f-8ec4-47c1-bd99-1c020f40b35e@github.com>
Message-ID: <VNu0f1qJDjt6-yJ3uBIXeu5-HxzlUAd8jdPK19ZUa10=.0fb01b7b-16b1-4f10-8b56-e5af180f7cc7@github.com>

On Wed, 28 Jun 2023 00:18:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
>> 
>> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
>> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
>> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
>> 
>> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
>> 
>> The rendered specifications:
>> https://cr.openjdk.org/~liach/8309819/09/java.base/java/lang/Class.html
>> https://cr.openjdk.org/~liach/8309819/09/java.base/java/lang/invoke/MethodType.html
>
> 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into fix/descstring-spec
>  - Update the distinct class note, thanks to mandy
>  - Merge branch 'master' into fix/descstring-spec
>  - produce identical component descriptors in descriptor strings -> cannot be distinguished in descriptor strings
>  - Reword of the distinct-class-same-descriptor note
>  - Missed recommendations from Alan
>  - Review and updates for 8310242
>  - Merge branch 'master' into fix/descstring-spec
>  - Update the note for getName
>  - Convert the note in fromDescriptorString to apiNote
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/cd5b8fd8...ef7004e4

I have published the updated javadoc with Class.forName spec update integrated: https://cr.openjdk.org/~liach/8309819/09/java.base/java/lang/Class.html

The CSR has been re-finalized as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14411#issuecomment-1610438288

From jpai at openjdk.org  Wed Jun 28 01:29:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Jun 2023 01:29:08 GMT
Subject: [jdk21] RFR: 8310914: Remove 2 malformed java/foreign ProblemList
 entries
In-Reply-To: <wRCAQXGQ4Bjo_PfOUcLN8IiGs86oUqsQLoKJ55h11L4=.0d1bcb84-c893-41c1-b94a-b260755e46b6@github.com>
References: <wRCAQXGQ4Bjo_PfOUcLN8IiGs86oUqsQLoKJ55h11L4=.0d1bcb84-c893-41c1-b94a-b260755e46b6@github.com>
Message-ID: <halKBpyBHENveDDebmrh31e69pKz6idTsZGuQeqOshk=.03411970-cda5-4c49-8944-4dbfed6b8176@github.com>

On Tue, 27 Jun 2023 20:48:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f07e396b](https://github.com/openjdk/jdk/commit/f07e396bda4567fd35677704b9aa974426266363) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 27 Jun 2023 and was reviewed by Jaikiran Pai.
> 
> Thanks!

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/75#pullrequestreview-1502089872

From liach at openjdk.org  Wed Jun 28 01:34:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 01:34:30 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v17]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <mIWoss4xsPeCQ9Ix5hwCwKPJGjhPKa9ITkOOZSmaG70=.5f6507ab-2bcb-4748-841c-b766d90269f7@github.com>

> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
> 
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
> 
> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
> 
> 
> Benchmark                                            Mode  Cnt    Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Comment update from mandy
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/8b8c672f..3c5d380b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=15-16

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From liach at openjdk.org  Wed Jun 28 01:35:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 01:35:08 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
Message-ID: <QQj-wjHySOSDcOYUN2XMyyCyhBjPjng3QgqX53T9J-o=.cd9181dd-104d-4929-a38f-e5819c1b52ca@github.com>

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo <duke at openjdk.org> wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

I've investigated the few xxNoRepl methods and think they are best coalesced together into newStringNoRepl and getBytesNoRepl taking byte arrays.

1. The exceptions to the NoRepl methods was added in [8205058](https://bugs.openjdk.org/browse/JDK-8205058) when the access method only catered to Files use cases; these are applicable nowhere else.
2. The UTF8 noRepl methods are sometimes implemented incorrectly, especially getBytesUTF8NoRepl, which always copies the array. They are added specifically for Zip handling as well.

Thus, I recommend the following changes:
1. Make the NoRepl methods throw IllegalArgument (like NoRepl1 do) by default; move the exception handling logic into Files implementation, the only place where it's actually needed.
2. Coalesce all charset-specific NoRepl methods in JLA into newStringNoRepl/getBytesNoRepl; the ones in String itself can stay, for they simplify code much.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610464404

From liach at openjdk.org  Wed Jun 28 01:49:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 01:49:05 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
Message-ID: <KV3ERpBx-8TgENXMjIr2fHL6onCqN5RH1EPaj_RbvLI=.39db9eb4-69c7-4e29-bad8-ef948601c3cc@github.com>

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo <duke at openjdk.org> wrote:

>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>> 
>> Reasons:
>> 
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter;
>> * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - Merge branch 'openjdk:master' into latin1-no-repl
>  - update javadoc
>  - clean newStringNoRepl1
>  - clean newStringNoRepl1
>  - Rename jla to JLA
>  - Create new method JavaLangAccess::newStringLatin1NoRepl

On a side note, `NoRepl` means "no replication", implying the passed array is already trusted. I think you should do something like this instead:

public static String readString(Path path, Charset cs) throws IOException { 
    Objects.requireNonNull(path); 
    Objects.requireNonNull(cs); 

    byte[] ba = readAllBytes(path); 
    if (path.getClass().getModule() != Object.class.getModule())
        return new String(ba, 0, ba.length, cs);
    return JLA.newStringNoRepl(ba, cs); 
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1610485537

From duke at openjdk.org  Wed Jun 28 03:43:06 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 28 Jun 2023 03:43:06 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger
Message-ID: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>

This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.

I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.

I've add a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:

Before (JDK 20.0.1):


Benchmark                       (size)  Mode  Cnt     Score    Error  Units
Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op


After:


Benchmark                       (size)  Mode  Cnt     Score     Error  Units
Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op


I've submitted a bug report for this to the [Java Bug Database](https://bugs.java.com/bugdatabase/). No CSR needed since the behavior is not changed.

-------------

Commit messages:
 - Typo: indices -> radices
 - Merge branch 'optimize-unsigned-string' of https://github.com/yuantj/jdk-pr into optimize-unsigned-string
 - Merge branch 'openjdk:master' into optimize-unsigned-string
 - Merge branch 'openjdk:master' into optimize-unsigned-string
 - Add benchmark
 - Update Long.java

Changes: https://git.openjdk.org/jdk/pull/14654/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14654&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311009
  Stats: 21 lines in 2 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14654.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14654/head:pull/14654

PR: https://git.openjdk.org/jdk/pull/14654

From duke at openjdk.org  Wed Jun 28 03:43:06 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 28 Jun 2023 03:43:06 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger
In-Reply-To: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
Message-ID: <e-zzfkEBmWa7XA3VVw5G_fKw-SyVwvSQDcn4K4r8dY8=.b806b8b8-8648-4ef2-9db1-e62f744c644c@github.com>

On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
> 
> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
> 
> I've add a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
> 
> Before (JDK 20.0.1):
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
> 
> 
> After:
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
> 
> 
> I've submitted a bug report for this to the [Java Bug Database](https://bugs.java.com/bugdatabase/). No CSR needed since the behavior is not changed.

Please ignore the merge warning from the bot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14654#issuecomment-1607673759

From thartmann at openjdk.org  Wed Jun 28 05:22:12 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 28 Jun 2023 05:22:12 GMT
Subject: [jdk21] RFR: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
In-Reply-To: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>
References: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>
Message-ID: <63VHhxlwewgAEwQHo8ptdW9xmXHtNn8STH126BEW4DE=.38fecbf9-fa49-43d3-8024-2ea49ca3013f@github.com>

On Tue, 27 Jun 2023 07:46:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459). Applies cleanly.
> 
> Thanks,
> Tobias

Thanks, Vladimir!

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/68#issuecomment-1610754095

From thartmann at openjdk.org  Wed Jun 28 05:22:13 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 28 Jun 2023 05:22:13 GMT
Subject: [jdk21] Integrated: 8310459: [BACKOUT] 8304450: [vectorapi] Refactor
 VectorShuffle implementation
In-Reply-To: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>
References: <ozlG8lhjKO4Xyj9U1LBZlwLOtPC39u_-NtmmoGC3-24=.d6e0bc79-9485-470d-ae58-fcee0a8c6cbc@github.com>
Message-ID: <iL02iH5NXAdQh_o0e_JeSPIMZGg1HTxSTlEycNCi0L4=.7eb69fd7-acd4-4c6f-8fab-a4415960e1a6@github.com>

On Tue, 27 Jun 2023 07:46:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459). Applies cleanly.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 9998c07b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/9998c07bd9348b5850a68cd8d8b6bbcfed5cc5fc
Stats:     3895 lines in 64 files changed: 1169 ins; 1819 del; 907 mod

8310459: [BACKOUT] 8304450: [vectorapi] Refactor VectorShuffle implementation

Reviewed-by: kvn
Backport-of: ff9a7541097bd853306a8594c97774f36877a0f9

-------------

PR: https://git.openjdk.org/jdk21/pull/68

From alanb at openjdk.org  Wed Jun 28 06:12:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jun 2023 06:12:12 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>
Message-ID: <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>

On Tue, 27 Jun 2023 21:52:08 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>  - Merge branch 'master' into JDK-8308995
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>    whitespace.
>  - some changes from review.
>    
>    read0() to implRead()
>    write0() to implWrite()
>    trailing whitespace
>  - fix copyright date
>  - Added micro benchmark to measure socket event overhead.
>  - Some changes from review.
>    
>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>    a reverse lookup when fetching the hostname of the remote address.
>  - remove unnecessary cast
>  - 8308995: Update Network IO JFR events to be static mirror events

src/java.base/share/classes/java/net/Socket.java line 1133:

> 1131:                 return parent.getSoTimeout();
> 1132:             } catch (Throwable t) {
> 1133:                 // ignored - avoiding exceptions in jfr event data gathering

This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1244728684

From liach at openjdk.org  Wed Jun 28 06:16:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 06:16:09 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
Message-ID: <8d8hNz_cwdKGnSgSleFt9YdRIj73R-lNWvWdByZiB70=.c580ba78-2404-4a84-96c2-50fee3f760fd@github.com>

On Tue, 27 Jun 2023 14:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang 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 branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

@asotona Can you review this patch that migrates MethodTypeDesc creation to static final field access whenever possible? This allows to reuse cached descriptor strings and avoid revalidation. In addition, I dropped the jdkTreePrimitive benchmark for jdk.classfile.Write, which is identical to jdkTree as far as I see.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14640#issuecomment-1610809614

From liach at openjdk.org  Wed Jun 28 06:17:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 06:17:28 GMT
Subject: RFR: 8311020: Typo cleanup in Classfile API
Message-ID: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>

This is a cleanup patch that fixes:
1. `ClassfileBuilder` should be sealed but was not; it's now sealed.
2. Various typo fixes, including spelling errors, wrong descriptions, and unnecessary full qualifications for classes in the same package.

Requesting a review from @asotona. There's a few other more complex issues discovered, which I will describe on the mailing list to elicit a discussion for best solutions.

-------------

Commit messages:
 - 8311020: Typo cleanup in Classfile API

Changes: https://git.openjdk.org/jdk/pull/14687/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14687&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311020
  Stats: 49 lines in 28 files changed: 3 ins; 3 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/14687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14687/head:pull/14687

PR: https://git.openjdk.org/jdk/pull/14687

From mbaesken at openjdk.org  Wed Jun 28 06:54:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 06:54:15 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v4]
In-Reply-To: <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
Message-ID: <C2-UUagDxny8B77nO8DEXjvUjU3jihIdw-0WlBc3ESE=.2b1d572f-2da4-4c2e-896a-317d7b20b303@github.com>

On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

Thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1610866191

From mbaesken at openjdk.org  Wed Jun 28 06:54:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 06:54:16 GMT
Subject: Integrated: JDK-8310380: Handle problems in core-related tests on
 macOS when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <_kf3OJmeEyW36gl2VpVoCiPuOUubkqc-u07Ht7SSxnw=.b841cf2f-3440-4f4a-975c-ae01644dc67f@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

This pull request has now been integrated.

Changeset: 39c104df
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39c104df44f17c1d65e35becd4272f73e2c6610c
Stats:     56 lines in 4 files changed: 37 ins; 12 del; 7 mod

8310380: Handle problems in core-related tests on macOS when codesign tool does not work

Reviewed-by: lucy, clanger, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/14562

From liach at openjdk.org  Wed Jun 28 07:02:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 07:02:17 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v9]
In-Reply-To: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
Message-ID: <nUxCWqXBbfxXKWnOpQ9aEqXAz3GInytnmLBi_pSnsqI=.8ccaf3ed-426b-4859-82ac-66e06243c09f@github.com>

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Classfile object update
 - Merge branch 'master' into invoke-test-classfile
 - Merge branch 'master' into invoke-test-classfile
 - Switch to ConstantDescs for <init> <clinit> and void constants
 - Merge AnnotationsTest, remove ModuleTargetAttribute call
 - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
 - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge branch 'master' into invoke-test-classfile
 - Fix LambdaStackTrace after running
 - formatting
 - ... and 4 more: https://git.openjdk.org/jdk/compare/526dba1a...d0b6c2ae

-------------

Changes: https://git.openjdk.org/jdk/pull/13009/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=08
  Stats: 1954 lines in 31 files changed: 307 ins; 883 del; 764 mod
  Patch: https://git.openjdk.org/jdk/pull/13009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13009/head:pull/13009

PR: https://git.openjdk.org/jdk/pull/13009

From duke at openjdk.org  Wed Jun 28 07:47:18 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 28 Jun 2023 07:47:18 GMT
Subject: Withdrawn: 8289220: Locale.forLanguageTag throws NPE due to soft ref
 used in locale cache being cleared
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <a9tIGyZRcY3g5hVcTTnTDAKn-i7p0Fr2zYZ2teEYIjI=.b6c2e027-17ae-4925-8b19-f9f66755314f@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14211

From duke at openjdk.org  Wed Jun 28 07:57:25 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 28 Jun 2023 07:57:25 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger [v2]
In-Reply-To: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
Message-ID: <sWHpozHw3XmXWKJPEHK96mUHbLtIh1lNHwz1vZvCTLg=.094e1e22-3207-4440-89d3-ca228b330140@github.com>

> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
> 
> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
> 
> I've add a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
> 
> Before (JDK 20.0.1):
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
> 
> 
> After:
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
> 
> 
> I've submitted a bug report for this to the [Java Bug Database](https://bugs.java.com/bugdatabase/). No CSR needed since the behavior is not changed.

Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14654/files
  - new: https://git.openjdk.org/jdk/pull/14654/files/4c336988..46f67e33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14654&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14654&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14654.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14654/head:pull/14654

PR: https://git.openjdk.org/jdk/pull/14654

From rgiulietti at openjdk.org  Wed Jun 28 07:57:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 28 Jun 2023 07:57:27 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger
In-Reply-To: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
Message-ID: <FAUxdYNYp-LmFmL3A6gKuCA-pT8yA5geWiKjmRiWC_g=.3ea2b60a-9271-46b1-814f-a3b29456da3c@github.com>

On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
> 
> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
> 
> I've add a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
> 
> Before (JDK 20.0.1):
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
> 
> 
> After:
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
> 
> 
> I've submitted a bug report for this to the [Java Bug Database](https://bugs.java.com/bugdatabase/). No CSR needed since the behavior is not changed.

The change looks good (but I'm not an official reviewer).
Please update the copyright year in the micro benchmark.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14654#issuecomment-1610936673

From duke at openjdk.org  Wed Jun 28 07:57:51 2023
From: duke at openjdk.org (Tingjun Yuan)
Date: Wed, 28 Jun 2023 07:57:51 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger
In-Reply-To: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
Message-ID: <D0pqoFdanG8yVTud0icesCR6os6Ig3TjPo8XMl6eMVQ=.79232c15-c33d-4c29-9f3c-f62d218a24cf@github.com>

On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
> 
> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
> 
> I've add a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
> 
> Before (JDK 20.0.1):
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
> 
> 
> After:
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
> 
> 
> I've submitted a bug report for this to the [Java Bug Database](https://bugs.java.com/bugdatabase/). No CSR needed since the behavior is not changed.

BTW, do I need to remove `toUnsignedBigInteger` method (which is private and no longer used)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14654#issuecomment-1610942630

From rgiulietti at openjdk.org  Wed Jun 28 08:09:05 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 28 Jun 2023 08:09:05 GMT
Subject: RFR: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger [v2]
In-Reply-To: <sWHpozHw3XmXWKJPEHK96mUHbLtIh1lNHwz1vZvCTLg=.094e1e22-3207-4440-89d3-ca228b330140@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
 <sWHpozHw3XmXWKJPEHK96mUHbLtIh1lNHwz1vZvCTLg=.094e1e22-3207-4440-89d3-ca228b330140@github.com>
Message-ID: <Rg0kiGkvuay3dC9LYSxwhgZ4XnTCdEj3IIc544j__UY=.3be4036b-dd9d-4167-bad1-7efffda0c392@github.com>

On Wed, 28 Jun 2023 07:57:25 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

>> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
>> 
>> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
>> 
>> I've added a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
>> 
>> Before (JDK 20.0.1):
>> 
>> 
>> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
>> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
>> 
>> 
>> After:
>> 
>> 
>> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
>> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
>> 
>> 
>> No CSR needed since the behavior is not changed.
>
> Tingjun Yuan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

I checked whether the method is ever searched for reflectively: this seems _not_ be the case in the JDK codebase. So I guess it can be removed from `Long.java`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14654#issuecomment-1610958354

From jpai at openjdk.org  Wed Jun 28 08:58:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 28 Jun 2023 08:58:09 GMT
Subject: RFR: 8301569: jmod list option and jimage list --help not
 interpreted correctly on turkish locale [v4]
In-Reply-To: <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <ha9G7VISmCG7eEz7sb5Gqm7FmqCo9W_NwpgsBGqZIDQ=.36018680-396d-4af7-ab91-632f36a21eab@github.com>
Message-ID: <-L6EWnnh8jrJI05fr48R6FlRySv461avh0I2Ko1aOXQ=.4280a525-090f-4df1-8a38-6b3486bb4942@github.com>

On Tue, 27 Jun 2023 15:20:33 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageTask, JlinkTask and VersionPropsPlugin

Marked as reviewed by jpai (Reviewer).

Thank you Glavo for these changes. The latest changes look good to me. I see that others more familiar with this code have approved the current state of the PR. I'll run some internal tests just to make sure nothing unexpectedly breaks, before sponsoring this today.

-------------

PR Review: https://git.openjdk.org/jdk/pull/12281#pullrequestreview-1502611452
PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1611025979

From asotona at openjdk.org  Wed Jun 28 08:59:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 28 Jun 2023 08:59:06 GMT
Subject: RFR: 8311020: Typo cleanup in Classfile API
In-Reply-To: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
References: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
Message-ID: <4q7dlxmB87F4Ein4VOKoFJ_59umDhZcMOn4X-fU9mPw=.65a96235-2339-480f-9d0c-5dcc74b89263@github.com>

On Wed, 28 Jun 2023 06:09:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> This is a cleanup patch that fixes:
> 1. `ClassfileBuilder` should be sealed but was not; it's now sealed.
> 2. Various typo fixes, including spelling errors, wrong descriptions, and unnecessary full qualifications for classes in the same package.
> 
> Requesting a review from @asotona. There's a few other more complex issues discovered, which I will describe on the mailing list to elicit a discussion for best solutions.

src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 500:

> 498:             case OfClass clv -> leafs("class", clv.className().stringValue());
> 499:             case OfEnum ev -> leafs("enum class", ev.className().stringValue(),
> 500:                                     "constant name", ev.constantName().stringValue());

Here the same typo is repeated in ClassPrinterTest, which actually fails after the fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14687#discussion_r1244907999

From duke at openjdk.org  Wed Jun 28 09:02:01 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 28 Jun 2023 09:02:01 GMT
Subject: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to
 String::newStringLatin1NoRepl [v4]
In-Reply-To: <KV3ERpBx-8TgENXMjIr2fHL6onCqN5RH1EPaj_RbvLI=.39db9eb4-69c7-4e29-bad8-ef948601c3cc@github.com>
References: <GhtOigwdW3GRuBl_ij2FwElObi3JdrvVfe3O6TFYYyY=.98d1da72-d869-4f05-a048-c50950823d18@github.com>
 <2kaBpDtR8Q8sm6OjUgsYXUmO1EBnkoNo4yWa1iuZZYI=.a7e962d5-307d-4eee-a6da-2686903c38ff@github.com>
 <KV3ERpBx-8TgENXMjIr2fHL6onCqN5RH1EPaj_RbvLI=.39db9eb4-69c7-4e29-bad8-ef948601c3cc@github.com>
Message-ID: <ZFVY4lUy8a38Pa7TIYInx-1JmwelzBNl4aS6xt08i3U=.9de0915a-c71e-435d-b4e6-dd83142836ee@github.com>

On Wed, 28 Jun 2023 01:45:51 GMT, Chen Liang <liach at openjdk.org> wrote:

> On a side note, `NoRepl` means "no replication", implying the passed array is already trusted. I think you should do something like this instead:

I think `NoRepl` means "no replace", it's an ambiguous acronym.

It cannot be replaced by `new String(byte[], int, int, Charset)` because the constructor will replaces malformed-input and unmappable-character sequences with this charset's default replacement string.

I think throwing an exception when malformed or unmappable bytes is encountered is a useful behavior, and maybe a new public API should be provided to users.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14655#issuecomment-1611031664

From shade at openjdk.org  Wed Jun 28 10:15:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 28 Jun 2023 10:15:12 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond [v2]
In-Reply-To: <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
 <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
Message-ID: <5jn1AQQwdAmbkChE-UbODsY5owoDAaTBI-b12qxhH78=.63a6d06a-8b9c-4b7d-92f0-134b93426325@github.com>

On Tue, 27 Jun 2023 16:34:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8310232-TickClock-ArithExp
>  - Removed bugid from the test class description
>  - refactor return statement
>  - 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

src/java.base/share/classes/java/time/Clock.java line 762:

> 760:         public long millis() {
> 761:             long millis = baseClock.millis();
> 762:             return tickNanos < 1000_000L ? millis : millis - Math.floorMod(millis, tickNanos / 1000_000L);

Cleaner precedence:

Suggestion:

            long trunc = (tickNanos >= 1000_000L) ? Math.floorMod(millis, tickNanos / 1000_000L) : 0;
            return millis - trunc;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14657#discussion_r1244999939

From stsypanov at openjdk.org  Wed Jun 28 11:13:16 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 28 Jun 2023 11:13:16 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
Message-ID: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>

Double-checked locking should rely on local variable to avoid racy reads from volatile field.

-------------

Commit messages:
 - 8311030: ResourceBundle.handleKeySet() is racy

Changes: https://git.openjdk.org/jdk/pull/14692/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14692&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311030
  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14692/head:pull/14692

PR: https://git.openjdk.org/jdk/pull/14692

From asotona at openjdk.org  Wed Jun 28 12:10:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 28 Jun 2023 12:10:05 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
Message-ID: <MWHnZxnOIPeYIYkdp80fWAJDVcFdFBG464VPbqfq_VA=.5b0fa7aa-677d-482b-a9ad-eb0bf608e884@github.com>

On Tue, 27 Jun 2023 14:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang 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 branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

This code replacing repeated symbols instantiation with static fields looks good.

However the patch also contains significant refactoring of jdk.jlink SystemModulesPlugin
and significant refactoring of the JMH benchmarks Write class.

I suggest to split this PR or link additional issues to it.

There is missing description of the problems so the proposed solution cannot be reviewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14640#issuecomment-1611284383

From mbaesken at openjdk.org  Wed Jun 28 12:57:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 12:57:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
Message-ID: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>

On Thu, 22 Jun 2023 14:20:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/java.sql/share/classes/java/sql/DriverManager.java line 658:
> 
>> 656:          * (which is invoking this class indirectly)
>> 657:          * classloader, so that the JDBC driver class outside the image
>> 658:          * can be loaded from here.
> 
> This code should probably be changed to use VM.isSystemDomainLoader(callerCL).
> 
> I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:
> 
> "If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

Hi Alan, regarding usage of class VM I get 
'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
Is there any concern to export it as well to module java.sql  ?
And btw did you mean to use it like this, in the if  ?

`        if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
            callerCL = Thread.currentThread().getContextClassLoader();
        }`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245164604

From alanb at openjdk.org  Wed Jun 28 13:19:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jun 2023 13:19:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
Message-ID: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>

On Wed, 28 Jun 2023 12:54:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
> 
> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`

It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245197137

From mbaesken at openjdk.org  Wed Jun 28 13:25:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 13:25:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
Message-ID: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>

On Wed, 28 Jun 2023 13:16:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, regarding usage of class VM I get 
>> 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
>> Is there any concern to export it as well to module java.sql  ?
>> And btw did you mean to use it like this, in the if  ?
>> 
>> `
>>  if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
>>             callerCL = Thread.currentThread().getContextClassLoader();
>> }
>> `
>
>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>> 
>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
> 
> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245204791

From liach at openjdk.org  Wed Jun 28 14:12:12 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 14:12:12 GMT
Subject: RFR: 8311020: Typo cleanup in Classfile API [v2]
In-Reply-To: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
References: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
Message-ID: <h2kCJ45edIuIIwhwW-N3coaib8eWjOkS00O5_UlHhTs=.1b38de64-dd73-4482-a16b-83996603690c@github.com>

> This is a cleanup patch that fixes:
> 1. `ClassfileBuilder` should be sealed but was not; it's now sealed.
> 2. Various typo fixes, including spelling errors, wrong descriptions, and unnecessary full qualifications for classes in the same package.
> 
> Requesting a review from @asotona. There's a few other more complex issues discovered, which I will describe on the mailing list to elicit a discussion for best solutions.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix classfile test typos detected by IDE, fix tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14687/files
  - new: https://git.openjdk.org/jdk/pull/14687/files/e2dd9184..675774b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14687&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14687&range=00-01

  Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14687/head:pull/14687

PR: https://git.openjdk.org/jdk/pull/14687

From liach at openjdk.org  Wed Jun 28 14:12:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 14:12:15 GMT
Subject: RFR: 8311020: Typo cleanup in Classfile API [v2]
In-Reply-To: <4q7dlxmB87F4Ein4VOKoFJ_59umDhZcMOn4X-fU9mPw=.65a96235-2339-480f-9d0c-5dcc74b89263@github.com>
References: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
 <4q7dlxmB87F4Ein4VOKoFJ_59umDhZcMOn4X-fU9mPw=.65a96235-2339-480f-9d0c-5dcc74b89263@github.com>
Message-ID: <NH7GNN9lssZimyR_iJ5ZVBb0_M7C1tuUkRPanoKKttI=.1ddd3eba-06c8-4eb2-b18b-9e97f9eb734b@github.com>

On Wed, 28 Jun 2023 08:56:28 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix classfile test typos detected by IDE, fix tests
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 500:
> 
>> 498:             case OfClass clv -> leafs("class", clv.className().stringValue());
>> 499:             case OfEnum ev -> leafs("enum class", ev.className().stringValue(),
>> 500:                                     "constant name", ev.constantName().stringValue());
> 
> Here the same typo is repeated in ClassPrinterTest, which actually fails after the fix.

Thanks for the reminder. I've checked IDE-reported typos in the tests and fixed 2; jdk.classfile tests pass on my machine now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14687#discussion_r1245272265

From rriggs at openjdk.org  Wed Jun 28 14:16:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 14:16:10 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond [v2]
In-Reply-To: <5jn1AQQwdAmbkChE-UbODsY5owoDAaTBI-b12qxhH78=.63a6d06a-8b9c-4b7d-92f0-134b93426325@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
 <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
 <5jn1AQQwdAmbkChE-UbODsY5owoDAaTBI-b12qxhH78=.63a6d06a-8b9c-4b7d-92f0-134b93426325@github.com>
Message-ID: <z5ULXxsVFJLWTXUx9XbFoaR_UflcqT-9zb6xsyAOhEg=.1b5622aa-8e1c-4d80-b7f9-fe3276e2db43@github.com>

On Wed, 28 Jun 2023 10:12:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8310232-TickClock-ArithExp
>>  - Removed bugid from the test class description
>>  - refactor return statement
>>  - 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond
>
> src/java.base/share/classes/java/time/Clock.java line 762:
> 
>> 760:         public long millis() {
>> 761:             long millis = baseClock.millis();
>> 762:             return tickNanos < 1000_000L ? millis : millis - Math.floorMod(millis, tickNanos / 1000_000L);
> 
> Cleaner precedence:
> 
> Suggestion:
> 
>             long trunc = (tickNanos >= 1000_000L) ? Math.floorMod(millis, tickNanos / 1000_000L) : 0;
>             return millis - trunc;

Either is fine, the current version avoids any extra operations if no (further) truncation is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14657#discussion_r1245282851

From prappo at openjdk.org  Wed Jun 28 14:24:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 14:24:03 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <ow3S3p8XruamqYsKnafB4kLGPcREhoMNT8ypZEvn5pQ=.0b28cf2d-cf24-46ce-b067-f1b3beae5f66@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

To put this into perspective, the race you are trying to fix seems benign, so the PR qualifies as a performance improvement, not a bug fix. Is my understanding correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1611506000

From liach at openjdk.org  Wed Jun 28 15:30:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 15:30:37 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v5]
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <aogvhejpk3oWNObvY2pYy40tmfNbEv3K8wVJs_jVd_g=.84bf7f83-6739-437c-a428-8afdd4102a55@github.com>

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Revert irrelevant changes
 - Merge branch 'master' into fix/cd-usage
 - Merge branch 'master' into fix/cd-usage
 - Merge branch 'master' into fix/cd-usage
 - Fix build
 - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

-------------

Changes: https://git.openjdk.org/jdk/pull/14640/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14640&range=04
  Stats: 131 lines in 6 files changed: 39 ins; 19 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/14640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14640/head:pull/14640

PR: https://git.openjdk.org/jdk/pull/14640

From liach at openjdk.org  Wed Jun 28 15:33:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 15:33:10 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v4]
In-Reply-To: <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <Q-6rfExUON-OJi3Ww7K2mXWPovfmK0JTCgaSD72OF0Q=.53651bbd-62bf-4f03-a3fa-8a859da8f78f@github.com>
Message-ID: <6m11IpeWXdPJkMPli3V3SWj40Z-N1DoM3HtP9eRXens=.1a5b2693-26aa-4695-a762-27d20172b980@github.com>

On Tue, 27 Jun 2023 14:20:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang 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 branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

I have reverted the changes to SystemModulesPlugin and Write. Can you review this patch again?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14640#issuecomment-1611654121

From asotona at openjdk.org  Wed Jun 28 16:01:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 28 Jun 2023 16:01:27 GMT
Subject: RFR: 8310848: Convert ClassDesc and MethodTypeDesc to be stored in
 static final fields [v5]
In-Reply-To: <aogvhejpk3oWNObvY2pYy40tmfNbEv3K8wVJs_jVd_g=.84bf7f83-6739-437c-a428-8afdd4102a55@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
 <aogvhejpk3oWNObvY2pYy40tmfNbEv3K8wVJs_jVd_g=.84bf7f83-6739-437c-a428-8afdd4102a55@github.com>
Message-ID: <BuMb5o0-JFRRFpQmCjRJbQZKhjVtPx0S-8tD7NlxHQI=.e4043c3d-b1a9-4a82-9821-e0c8778e0a8a@github.com>

On Wed, 28 Jun 2023 15:30:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Revert irrelevant changes
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Merge branch 'master' into fix/cd-usage
>  - Fix build
>  - 8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

It looks good ?

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14640#pullrequestreview-1503464828

From asotona at openjdk.org  Wed Jun 28 16:19:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 28 Jun 2023 16:19:57 GMT
Subject: RFR: 8311020: Typo cleanup in Classfile API [v2]
In-Reply-To: <h2kCJ45edIuIIwhwW-N3coaib8eWjOkS00O5_UlHhTs=.1b38de64-dd73-4482-a16b-83996603690c@github.com>
References: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
 <h2kCJ45edIuIIwhwW-N3coaib8eWjOkS00O5_UlHhTs=.1b38de64-dd73-4482-a16b-83996603690c@github.com>
Message-ID: <aeCZNW35L_nty7erapMwQARaJds9AdOdY2SJH16Rnbs=.794f2811-6411-4cf9-aa14-f1bda3eb5877@github.com>

On Wed, 28 Jun 2023 14:12:12 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This is a cleanup patch that fixes:
>> 1. `ClassfileBuilder` should be sealed but was not; it's now sealed.
>> 2. Various typo fixes, including spelling errors, wrong descriptions, and unnecessary full qualifications for classes in the same package.
>> 
>> Requesting a review from @asotona. There's a few other more complex issues discovered, which I will describe on the mailing list to elicit a discussion for best solutions.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix classfile test typos detected by IDE, fix tests

Thank you for fixing the typos.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14687#pullrequestreview-1503501942

From naoto at openjdk.org  Wed Jun 28 16:58:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Jun 2023 16:58:57 GMT
Subject: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime
 when tick is 1 microsecond [v2]
In-Reply-To: <z5ULXxsVFJLWTXUx9XbFoaR_UflcqT-9zb6xsyAOhEg=.1b5622aa-8e1c-4d80-b7f9-fe3276e2db43@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
 <Tp1HdEUGoFz1HHxVl7NSj4JarZSzDNX59QMb_SZgGnc=.105750c2-c7a2-4cbc-8e30-806ccdce81a1@github.com>
 <5jn1AQQwdAmbkChE-UbODsY5owoDAaTBI-b12qxhH78=.63a6d06a-8b9c-4b7d-92f0-134b93426325@github.com>
 <z5ULXxsVFJLWTXUx9XbFoaR_UflcqT-9zb6xsyAOhEg=.1b5622aa-8e1c-4d80-b7f9-fe3276e2db43@github.com>
Message-ID: <vQ6EpGtXUbLRsNdP7Hed73uMwxx2hdsXutPDy_tf4Tc=.8d5de2f6-074a-42b4-9f5a-34ffa4bc15a1@github.com>

On Wed, 28 Jun 2023 14:12:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/Clock.java line 762:
>> 
>>> 760:         public long millis() {
>>> 761:             long millis = baseClock.millis();
>>> 762:             return tickNanos < 1000_000L ? millis : millis - Math.floorMod(millis, tickNanos / 1000_000L);
>> 
>> Cleaner precedence:
>> 
>> Suggestion:
>> 
>>             long trunc = (tickNanos >= 1000_000L) ? Math.floorMod(millis, tickNanos / 1000_000L) : 0;
>>             return millis - trunc;
>
> Either is fine, the current version avoids any extra operations if no (further) truncation is needed.

Thanks. I think it is OK as it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14657#discussion_r1245509389

From lkorinth at openjdk.org  Wed Jun 28 17:04:24 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 28 Jun 2023 17:04:24 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
Message-ID: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>

Remove trailing "blank" lines in source files.

I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.

The fix removes trailing lines matching ^[[:space:]]*$ in

- *.java
- *.cpp
- *.hpp
- *.c
- *.h 

I have applied the following bash script to each file:

    file="$1"
    
    while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
        truncate -s -1 "$file"
    done

`git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
`git diff --ignore-blank-lines  master` displays one change

-------------

Commit messages:
 - h
 - c
 - hpp
 - cpp
 - 8311043: Remove trailing blank lines in source files

Changes: https://git.openjdk.org/jdk/pull/14698/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311043
  Stats: 4529 lines in 4382 files changed: 0 ins; 4529 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14698/head:pull/14698

PR: https://git.openjdk.org/jdk/pull/14698

From duke at openjdk.org  Wed Jun 28 17:14:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 28 Jun 2023 17:14:11 GMT
Subject: RFR: 8310929: Optimization for Integer.toString
Message-ID: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>

Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  

this optimization can also be used in StringBuilder#appent(int) and Long#toString.

# Benchmark Result


make test TEST="micro:java.lang.Integers.toString*"


## [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
* cpu : intel xeon sapphire rapids (x64)
``` diff
-Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
-Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
-Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
-Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op

+Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
+Integers.toStringBig       500  avgt   15  5.164 ? 0.052  us/op +31.89%
+Integers.toStringSmall     500  avgt   15  3.844 ? 0.025  us/op +24.71%
+Integers.toStringTiny      500  avgt   15  3.453 ? 0.027  us/op +8.65%


### [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
* cpu : amd epc genoa (x64)
``` diff
-Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
-Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
-Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
-Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op

+Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
+Integers.toStringBig       500  avgt   15  5.063 ? 0.175  us/op +33.55%
+Integers.toStringSmall     500  avgt   15  3.498 ? 0.123  us/op +28.10%
+Integers.toStringTiny      500  avgt   15  2.743 ? 0.147  us/op +0.65%


## [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
* cpu : aliyun yitian 710 (aarch64)
``` diff
-Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
-Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
-Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
-Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op

+Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
+Integers.toStringBig       500  avgt   15  8.157 ? 0.274  us/op +48.10%
+Integers.toStringSmall     500  avgt   15  7.207 ? 0.330  us/op -1.22%
+Integers.toStringTiny      500  avgt   15  6.912 ? 0.199  us/op -8.52%

-------------

Commit messages:
 - 8310929: Optimization for Integer.toString

Changes: https://git.openjdk.org/jdk/pull/14699/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310929
  Stats: 159 lines in 1 file changed: 153 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From mcimadamore at openjdk.org  Wed Jun 28 17:28:57 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Jun 2023 17:28:57 GMT
Subject: RFR: 8310405: Linker.Option.firstVariadicArg should specify which
 index values are valid [v3]
In-Reply-To: <k-myLLKzDkkNIirmZzuOzQdOOxCZUcev8uEaThYE1iE=.bb39fb46-47aa-4e55-afe7-0ce402eefba6@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
 <k-myLLKzDkkNIirmZzuOzQdOOxCZUcev8uEaThYE1iE=.bb39fb46-47aa-4e55-afe7-0ce402eefba6@github.com>
Message-ID: <YzHxrhNgScK6y5Ulq9b7xrAluOLyH7jccAQE8S9TV60=.6af901bb-61ed-4ed1-aba4-63584a71a8d5@github.com>

On Fri, 23 Jun 2023 23:58:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.
>
> Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - review comments
>  - Update src/java.base/share/classes/java/lang/foreign/Linker.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Phrasing
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14565#pullrequestreview-1503628781

From jvernee at openjdk.org  Wed Jun 28 17:37:06 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 28 Jun 2023 17:37:06 GMT
Subject: Integrated: 8310405: Linker.Option.firstVariadicArg should specify
 which index values are valid
In-Reply-To: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
References: <6TXJp2ejHYClUyRw9lNfKX2VIV8pq2fM6gHofhoqjMQ=.1e213286-13a3-4aac-823e-bc13d896fa10@github.com>
Message-ID: <RgobSsulwSvY3BpZ69EJzlZgUDoeLcjv18mjF8A3R5g=.b60532f9-ea46-4abe-abaa-9f7b3a0b04fb@github.com>

On Tue, 20 Jun 2023 14:21:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve the specification of `Linker.Option.firstVariadicArg`, by specifying more clearly which index values are valid.

This pull request has now been integrated.

Changeset: 7fffdb5e
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7fffdb5e60351026c9ee77f438b8fe505d85de4c
Stats:     19 lines in 1 file changed: 15 ins; 0 del; 4 mod

8310405: Linker.Option.firstVariadicArg should specify which index values are valid

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14565

From jvernee at openjdk.org  Wed Jun 28 17:42:14 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 28 Jun 2023 17:42:14 GMT
Subject: [jdk21] RFR: 8310405: Linker.Option.firstVariadicArg should specify
 which index values are valid
Message-ID: <qGc0fj4RPki2s8DXQOkx4-5BsJZ9Fmbyo50tS5FqJKM=.3dfab3df-d410-4719-a4a3-e029c4f21f85@github.com>

Hi all,

This pull request contains a backport of commit [7fffdb5e](https://github.com/openjdk/jdk/commit/7fffdb5e60351026c9ee77f438b8fe505d85de4c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Jorn Vernee on 28 Jun 2023 and was reviewed by Maurizio Cimadamore.

Thanks!

-------------

Commit messages:
 - Backport 7fffdb5e60351026c9ee77f438b8fe505d85de4c

Changes: https://git.openjdk.org/jdk21/pull/78/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=78&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310405
  Stats: 19 lines in 1 file changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/78.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/78/head:pull/78

PR: https://git.openjdk.org/jdk21/pull/78

From rriggs at openjdk.org  Wed Jun 28 17:46:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 17:46:51 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation [v2]
In-Reply-To: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
Message-ID: <xYTzl-aQuM2OBce4oRJtQuNQxEsofVyPkkeew8QuwEk=.2abc5a12-302e-447c-9dec-1212fc48031e@github.com>

> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
> The code is refactored in `compareTo` to do the comparison of `LocalDateTime` exactly once, if it is needed.
> 
> This case is NOT covered by an existing test in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Reopen to work on an improved fix
  Add a test for the specific condition being optimized, the test was missing in the original.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14618/files
  - new: https://git.openjdk.org/jdk/pull/14618/files/a5fcbd0a..352a3fae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14618&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14618&range=00-01

  Stats: 27 lines in 2 files changed: 12 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14618/head:pull/14618

PR: https://git.openjdk.org/jdk/pull/14618

From rriggs at openjdk.org  Wed Jun 28 17:46:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 17:46:53 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation
In-Reply-To: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
Message-ID: <1w2xF3k2BC9IBIzEWfvH5mCf4CnSEFiInMOEJggH6nU=.206b2169-1718-471d-8da8-025517974ae7@github.com>

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
> The code is refactored in `compareTo` to do the comparison of `LocalDateTime` exactly once, if it is needed.
> 
> This case is NOT covered by an existing test in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

Reopening this to propose a different implementation and to 
provide the test of the specific condition that is missing from java/time/jck/java/time/TCKOffsetDateTime.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14618#issuecomment-1611829783

From mcimadamore at openjdk.org  Wed Jun 28 17:53:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 28 Jun 2023 17:53:58 GMT
Subject: [jdk21] RFR: 8310405: Linker.Option.firstVariadicArg should
 specify which index values are valid
In-Reply-To: <qGc0fj4RPki2s8DXQOkx4-5BsJZ9Fmbyo50tS5FqJKM=.3dfab3df-d410-4719-a4a3-e029c4f21f85@github.com>
References: <qGc0fj4RPki2s8DXQOkx4-5BsJZ9Fmbyo50tS5FqJKM=.3dfab3df-d410-4719-a4a3-e029c4f21f85@github.com>
Message-ID: <bClSlaKdeeWPID_uuDvQ-h7_VB1l2BU6LT-uSDPex2E=.fa17d557-ad30-497b-a7d2-b39279ff117c@github.com>

On Wed, 28 Jun 2023 17:34:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7fffdb5e](https://github.com/openjdk/jdk/commit/7fffdb5e60351026c9ee77f438b8fe505d85de4c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 28 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/78#pullrequestreview-1503668090

From rgiulietti at openjdk.org  Wed Jun 28 17:56:58 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 28 Jun 2023 17:56:58 GMT
Subject: RFR: 8310929: Optimization for Integer.toString
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <Z5DShRGcrKeM3DX36f_bN7wb8Kc-XIyHZBsnObhki6s=.a78675e9-0d97-4c33-a849-22ba2cb3e5d4@github.com>

On Wed, 28 Jun 2023 17:06:56 GMT, ??? <duke at openjdk.org> wrote:

> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
> 
> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
> 
> # Benchmark Result
> 
> 
> make test TEST="micro:java.lang.Integers.toString*"
> 
> 
> ## [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  5.164 ? 0.052  us/op +31.89%
> +Integers.toStringSmall     500  avgt   15  3.844 ? 0.025  us/op +24.71%
> +Integers.toStringTiny      500  avgt   15  3.453 ? 0.027  us/op +8.65%
> 
> 
> ### [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  5.063 ? 0.175  us/op +33.55%
> +Integers.toStringSmall     500  avgt   15  3.498 ? 0.123  us/op +28.10%
> +Integers.toStringTiny      500  avgt   15  2.743 ? 0.147  us/op +0.65%
> 
> 
> ## [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  8.157 ? 0.274  us/op +48.10%
> +Integers.toStringSmall     500  avgt   15  7.207 ? 0.330  us/op -1.22%
> +Integers.toStringTiny      500  avgt   15  6.912 ? 0.199  us/op -8.52%

src/java.base/share/classes/java/lang/Integer.java line 478:

> 476: 
> 477:         byte[] buf;
> 478:         if (q1 == 0) {

You could postpone the division to compute `q1` later, and here test whether `i < 1_000`.
I've no statistics, but I guess it makes sense to optimize for tiny `int`s by avoiding a division.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1245571903

From jvernee at openjdk.org  Wed Jun 28 18:32:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 28 Jun 2023 18:32:59 GMT
Subject: [jdk21] Integrated: 8310405: Linker.Option.firstVariadicArg should
 specify which index values are valid
In-Reply-To: <qGc0fj4RPki2s8DXQOkx4-5BsJZ9Fmbyo50tS5FqJKM=.3dfab3df-d410-4719-a4a3-e029c4f21f85@github.com>
References: <qGc0fj4RPki2s8DXQOkx4-5BsJZ9Fmbyo50tS5FqJKM=.3dfab3df-d410-4719-a4a3-e029c4f21f85@github.com>
Message-ID: <GGK4OUbSDVZT6gCFiGDWFbo-oOIDE6e2h_nf1y2gkFg=.70bb6621-c968-418f-8832-f56006bf4db5@github.com>

On Wed, 28 Jun 2023 17:34:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7fffdb5e](https://github.com/openjdk/jdk/commit/7fffdb5e60351026c9ee77f438b8fe505d85de4c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 28 Jun 2023 and was reviewed by Maurizio Cimadamore.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 45f252b7
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/45f252b7f99e461f81150b383e194547bcfd7ee9
Stats:     19 lines in 1 file changed: 15 ins; 0 del; 4 mod

8310405: Linker.Option.firstVariadicArg should specify which index values are valid

Reviewed-by: mcimadamore
Backport-of: 7fffdb5e60351026c9ee77f438b8fe505d85de4c

-------------

PR: https://git.openjdk.org/jdk21/pull/78

From tprinzing at openjdk.org  Wed Jun 28 18:53:12 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 28 Jun 2023 18:53:12 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
Message-ID: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>

> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
> 
> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
> 
> In the java.base module:
> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
> 
> In the jdk.jfr module:
> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
> 
> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
> Passed: jdk/jfr/event/io/TestSocketEvents.java
> 
> I added a micro benchmark which measures the overhead of handling the jfr socket events.
> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  less exception filtering when fetching socket read timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14342/files
  - new: https://git.openjdk.org/jdk/pull/14342/files/27a766c7..d6f7df72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14342&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14342/head:pull/14342

PR: https://git.openjdk.org/jdk/pull/14342

From stsypanov at openjdk.org  Wed Jun 28 18:53:55 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 28 Jun 2023 18:53:55 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <IMdmNXo_4UMT6o3QtJt6abq-20S8DpBYunZ3iV8aFl0=.7f5a96fe-7b98-4161-a407-5b3d74577d87@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

It'd be a benign race in case all members of `HashSet` are `final`, but they aren't, so there are no safe publication guarantees.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1611915175

From mchung at openjdk.org  Wed Jun 28 19:00:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 19:00:13 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
Message-ID: <hAnLonRWi_9sUaqeDsPxqeA46yksAmF9obl6kG8xbhY=.878dc4d5-b8ec-4572-b134-c4d6b26b3da0@github.com>

On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

Thanks for the update.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 481:

> 479:             MethodHandle originalTypeField;
> 480:             try {
> 481:                 originalTypeField = new Lookup(type).findStaticGetter(type, ORIGINAL_TYPE_NAME, Class.class);

If some random class `X` has the field "originalType" with value `I`, `isWrapperClass` would cause spinning a MH proxy class `I` as it calls `getProxyClassInfo` and return true.   `getProxyClassInfo` should be only called from `asInterfaceInstance`.

I think this can be done by having a `WeakHashMap<Class<?>, Boolean>` and `getProxyClassInfo` puts an entry with `TRUE` when a new proxy class is generated.

test/jdk/java/lang/reflect/Proxy/ProxyModuleMapping.java line 42:

> 40:         // unnamed module gets access to sun.invoke package (e.g. via --add-exports)
> 41:         new ProxyModuleMapping(sun.invoke.WrapperInstance.class).test();
> 42: 

The test case is to verify that proxy can access qualified exports.   So better to keep this test case and replace with an internal interface e.g. `jdk.internal.misc.VM.BufferPool`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1503496814
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1245624265
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1245462594

From mchung at openjdk.org  Wed Jun 28 19:04:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 19:04:14 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
Message-ID: <ypCYSAI8lNCfWOOnT8r44kBp8eGGyaIUbRrQIBV8RX0=.46921f5e-d7c8-4965-8f04-3e8483f4dba5@github.com>

On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

Thanks for the update.

For `WRAPPER_TYPES` class value, it's used to determine if it's a wrapper class.   If `X` is a random class with the field "originalType" with value `I`, `isWrapperClass` would cause spinning a MH proxy class I as it calls `getProxyClassInfo` and return true.  

I think instead of having a class value for querying if it's a wrapper class, this can be done by having a `WeakHashMap<Class<?>, Boolean>`. `getProxyClassInfo` should be only called from `asInterfaceInstance` and puts an entry with TRUE when a new proxy class is generated.

I will push my patch to a branch later today to contribute to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1611927517

From duke at openjdk.org  Wed Jun 28 19:20:51 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 28 Jun 2023 19:20:51 GMT
Subject: RFR: 8310929: Optimization for Integer.toString
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <_Io5vfxzN4Emx-hrzKMddNc304ah9OJqXtJB3IlDrMw=.bfe52286-12e1-4749-9783-496ccc816644@github.com>

On Wed, 28 Jun 2023 17:06:56 GMT, ??? <duke at openjdk.org> wrote:

> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
> 
> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
> 
> # Benchmark Result
> 
> 
> make test TEST="micro:java.lang.Integers.toString*"
> 
> 
> ## [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  5.164 ? 0.052  us/op +31.89%
> +Integers.toStringSmall     500  avgt   15  3.844 ? 0.025  us/op +24.71%
> +Integers.toStringTiny      500  avgt   15  3.453 ? 0.027  us/op +8.65%
> 
> 
> ### [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  5.063 ? 0.175  us/op +33.55%
> +Integers.toStringSmall     500  avgt   15  3.498 ? 0.123  us/op +28.10%
> +Integers.toStringTiny      500  avgt   15  2.743 ? 0.147  us/op +0.65%
> 
> 
> ## [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  8.157 ? 0.274  us/op +48.10%
> +Integers.toStringSmall     500  avgt   15  7.207 ? 0.330  us/op -1.22%
> +Integers.toStringTiny      500  avgt   15  6.912 ? 0.199  us/op -8.52%

Although this method is `IntrinsicCandidate`, in reality it will only be optimized in the fluent-chain of `StringBuilder`/`StringBuffer`, so optimizing its Java implementation is meaningful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1611961052

From duke at openjdk.org  Wed Jun 28 19:21:08 2023
From: duke at openjdk.org (duke)
Date: Wed, 28 Jun 2023 19:21:08 GMT
Subject: Withdrawn: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <coBFNT8q0d0jy1iczNhAI8HHltvLSeSCGyp7nWeHpVI=.285ba5b3-f158-4a8d-b754-b3a1d08b7543@github.com>

On Wed, 22 Feb 2023 15:23:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12719

From psandoz at openjdk.org  Wed Jun 28 19:22:03 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 28 Jun 2023 19:22:03 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v17]
In-Reply-To: <mIWoss4xsPeCQ9Ix5hwCwKPJGjhPKa9ITkOOZSmaG70=.5f6507ab-2bcb-4748-841c-b766d90269f7@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <mIWoss4xsPeCQ9Ix5hwCwKPJGjhPKa9ITkOOZSmaG70=.5f6507ab-2bcb-4748-841c-b766d90269f7@github.com>
Message-ID: <xUKH8TnfxnuPI2XTqlj1AOqxOeq3_wiUAx1WJgVZDUE=.e06fe6af-309d-41cd-bc56-9f78988d6ae8@github.com>

On Wed, 28 Jun 2023 01:34:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
>> 
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
>> 
>> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
>> 
>> 
>> Benchmark                                            Mode  Cnt    Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update from mandy
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13821#pullrequestreview-1503820182

From psandoz at openjdk.org  Wed Jun 28 19:22:05 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 28 Jun 2023 19:22:05 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <3FuGPb8jn42Gl0W8hd0_69ZXlMadqVytc1_w71q0Kvg=.eb926215-3651-4c59-b1ae-20132ee3ae1d@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
 <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>
 <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>
 <3FuGPb8jn42Gl0W8hd0_69ZXlMadqVytc1_w71q0Kvg=.eb926215-3651-4c59-b1ae-20132ee3ae1d@github.com>
Message-ID: <nIZUve0DqL0M2rJM9NZHC9JCsNZiwkZpR3ekZdA3xJs=.b75ef6bd-2de3-441d-8088-6f2708f7c472@github.com>

On Wed, 28 Jun 2023 00:08:35 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The MH on VH case is worth considering; the indirect VH cases are already covered by `-Djava.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT=true`.
>
> Done; added a test case to test initialization on toMethodHandle use in latest push, passed locally.

Ok. I just realized you could also run using the system property `java.lang.invoke.VarHandle.VAR_HANDLE_GUARDS` to disables the guards, and it will go through the MH invokers, achieving the same thing. Up to you if you want to keep the current test or use the system property.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245661478

From mchung at openjdk.org  Wed Jun 28 19:22:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 19:22:16 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
Message-ID: <AuwciRfw7q-o-uO3IFW_LemWWS5vGIbP5dr_jsIOebU=.8e115cdf-5f86-4b78-93ad-21276204eeac@github.com>

On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 313:

> 311: 
> 312:     private static ProxyClassInfo getProxyClassInfo(Class<?> intfc) throws IllegalArgumentException {
> 313:         while (true) {

I think this needs to recompute the class value only one time if it finds the proxy class is unloaded and the reference is cleared.   The caller and the locals are holding a strong reference to the interface and so the newly created proxy class won't be GC'ed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1245661519

From psandoz at openjdk.org  Wed Jun 28 19:22:10 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 28 Jun 2023 19:22:10 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
 <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>
 <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>
Message-ID: <vM2YMASWZ3FaUCyCpSuT9D6zdhxDjpxCLMnLuJJvMtg=.db8cf9d1-2f3e-498b-8771-13de93c44741@github.com>

On Tue, 27 Jun 2023 23:33:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/invoke/LazyStaticColdStart.java line 92:
>> 
>>> 90:             });
>>> 91: 
>>> 92:             static {
>> 
>> Is this static block required?
>
> I use this block to remove the overhead around MethodHandle and VarHandle infrastructure initialization (such as LF spinning) that is not related to any particular class; so that I measure only the impact of encountering a new class.

Ah, implied by "... and initializes the lazy/non-lazy handles to prevent further creation costs" Could you also add a small comment above this block?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245655494

From jvernee at openjdk.org  Wed Jun 28 19:22:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 28 Jun 2023 19:22:55 GMT
Subject: [jdk21] Integrated: 8310914: Remove 2 malformed java/foreign
 ProblemList entries
In-Reply-To: <wRCAQXGQ4Bjo_PfOUcLN8IiGs86oUqsQLoKJ55h11L4=.0d1bcb84-c893-41c1-b94a-b260755e46b6@github.com>
References: <wRCAQXGQ4Bjo_PfOUcLN8IiGs86oUqsQLoKJ55h11L4=.0d1bcb84-c893-41c1-b94a-b260755e46b6@github.com>
Message-ID: <foMUV7fMl0wT1GdBet1-UE2FNCP39-y8CUA_Ej15StA=.9145c0bf-4ecf-46f3-b474-660877f8aa4f@github.com>

On Tue, 27 Jun 2023 20:48:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [f07e396b](https://github.com/openjdk/jdk/commit/f07e396bda4567fd35677704b9aa974426266363) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 27 Jun 2023 and was reviewed by Jaikiran Pai.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 722794f9
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/722794f9200ec22c09444b317f9f3a91a1d1386e
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8310914: Remove 2 malformed java/foreign ProblemList entries

Reviewed-by: jpai
Backport-of: f07e396bda4567fd35677704b9aa974426266363

-------------

PR: https://git.openjdk.org/jdk21/pull/75

From duke at openjdk.org  Wed Jun 28 19:36:03 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 28 Jun 2023 19:36:03 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v9]
In-Reply-To: <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>
Message-ID: <AvHTTEZ5U-D0TdohICA1ZRQkAzp10ODGtY0aXvL1jxI=.7ef08cc7-cf01-4b56-834b-f76100dbf0ed@github.com>

On Tue, 27 Jun 2023 20:29:36 GMT, Glavo <duke at openjdk.org> wrote:

>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
>> 
>> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
>> 
>> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add 8310843 to @bug

Can someone review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1611992072

From naoto at openjdk.org  Wed Jun 28 19:38:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Jun 2023 19:38:01 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation [v2]
In-Reply-To: <xYTzl-aQuM2OBce4oRJtQuNQxEsofVyPkkeew8QuwEk=.2abc5a12-302e-447c-9dec-1212fc48031e@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
 <xYTzl-aQuM2OBce4oRJtQuNQxEsofVyPkkeew8QuwEk=.2abc5a12-302e-447c-9dec-1212fc48031e@github.com>
Message-ID: <l792LSPjOne06dqboelo6x_SRu7FBhv3eWXxw_UTBY0=.af7d41ad-a367-4c62-802f-7c882222b507@github.com>

On Wed, 28 Jun 2023 17:46:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
>> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
>> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
>> The code is refactored in `compareTo` to do the comparison of `LocalDateTime` exactly once, if it is needed.
>> 
>> This case is NOT covered by an existing test in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reopen to work on an improved fix
>   Add a test for the specific condition being optimized, the test was missing in the original.

test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java line 1384:

> 1382:         assertEquals(b.compareTo(b) == 0, true);
> 1383:         assertEquals(a.toInstant().compareTo(b.toInstant()) == 0, true);
> 1384:         assertEquals(OffsetDateTime.timeLineOrder().compare(a,b) == 0, true);

Could be in a separate test case, as this method tests `compareTo` method?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14618#discussion_r1245676546

From mchung at openjdk.org  Wed Jun 28 19:55:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 19:55:13 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
Message-ID: <UcBHmDXrGMHWIO18hhPdAOQ88fn5X2Xv0RBY3GteS2c=.8f477156-8192-465f-a72b-81ea80a620c3@github.com>

On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

See the diff at https://github.com/liachmodded/jdk/compare/explore/mhp-iface...mlchung:jdk:mh-proxies

I made a few changes in my branch.
1. Change `WRAPPER_TYPES` to `WeakHashMap` to accurately determine if the given class is  the proxy class
2. I dropped `ProxyClassInfo` and use `Lookup`.  I see it's a simplification.   If `wrapperInstanceTarget` and `wrapperInstanceType` are frequently called, it makes sense to cache the method handles.
3. Should it use soft reference or weak reference?  It depends if `asInterfaceInstance` will be used heavily.
4. I also dropped `SamInfo` and `getStats` as it can be inlined in the caller, which I think it's clearer to see what it does in place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1612014844

From rriggs at openjdk.org  Wed Jun 28 20:01:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 20:01:57 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation [v2]
In-Reply-To: <l792LSPjOne06dqboelo6x_SRu7FBhv3eWXxw_UTBY0=.af7d41ad-a367-4c62-802f-7c882222b507@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
 <xYTzl-aQuM2OBce4oRJtQuNQxEsofVyPkkeew8QuwEk=.2abc5a12-302e-447c-9dec-1212fc48031e@github.com>
 <l792LSPjOne06dqboelo6x_SRu7FBhv3eWXxw_UTBY0=.af7d41ad-a367-4c62-802f-7c882222b507@github.com>
Message-ID: <GtyUFO0BfN5VccdtTcgsnsctuJk8VGbic5C6WXEEEC4=.c5d94e5b-ac72-42fc-b511-438c6ac6eeaa@github.com>

On Wed, 28 Jun 2023 19:35:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reopen to work on an improved fix
>>   Add a test for the specific condition being optimized, the test was missing in the original.
>
> test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java line 1384:
> 
>> 1382:         assertEquals(b.compareTo(b) == 0, true);
>> 1383:         assertEquals(a.toInstant().compareTo(b.toInstant()) == 0, true);
>> 1384:         assertEquals(OffsetDateTime.timeLineOrder().compare(a,b) == 0, true);
> 
> Could be in a separate test case, as this method tests `compareTo` method?

This is one of a sequence of tests of compareTo.  The other (previous) tests include verifying the assertion about the result of the `timeLineOrder` comparator with the same data.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14618#discussion_r1245695820

From rriggs at openjdk.org  Wed Jun 28 20:05:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 20:05:54 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

Looks ok; was this a tool detected race?

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1503889426

From amaembo at gmail.com  Wed Jun 28 20:15:51 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 28 Jun 2023 22:15:51 +0200
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAE+3fjbkkg=DKjMmb+is1TLbDe0XPRGeQ+vPQ64eG6Afbv9yNg@mail.gmail.com>

Hello!

Interesting read, thanks. I'm the author of the StreamEx library,
which actually enhances Stream API, and I use it during my daily job,
so I have some thoughts about extending Stream API as well. Below are
some of them.

First, there are many useful operations that can be trivially defined
in terms of existing operations. For example,
  mapPartial(Function<? super T, ? extends Optional<? extends R>> mapper)
It's essentially map(mapper).flatMap(Optional::stream), though it's
much more performant to express it as
  map(value -> mapper.apply(value).orElse(null)).filter(Objects::nonNull)
It might be desired to encapsulate such implementations in static
methods, and here .chain() or .transform() method would be helpful,
see https://bugs.openjdk.org/browse/JDK-8140283.

There are also some operations that cannot be expressed via existing
'normal' operations, and could be implemented taking spliterator() of
the original stream.
This is somewhat limited, especially taking into account how
WrappingSpliterator handles tryAdvance and trySplit. Stream API would
certainly benefit
if it can be more transparent and provide better ways to extend it.

One problematic place is how to provide a reasonable default
implementation for new methods like 'gather'. There are many
third-party implementations of Stream interface in the wild. Many of
them
just delegate most of the operations to JDK stream, adding some custom
logic. It should be expected that calling 'gather' on them will work
according to the spec.

Another thing that bothers me is parallel stream support. Not every
custom operation that you may imagine could be efficiently implemented
for parallel streams. But for some operations this is certainly
possible. It's unclear whether the proposed Gatherer interface is
flexible enough to provide good parallelization for operations. I have
a couple of exercises:

1. public <R> Stream<R> pairMap(BiFunction<? super T, ? super T, ?
extends R> mapper) {...}
  This operation processes overlapping adjacent pairs of the source
stream (the resulting stream is one element shorter). It's quite
useful, it's used 12 times in our production code. Also, it's a nice
building block for other operations. For example, we have Stream<T>
mapFirst(Function<? super T, ? extends T> mapper) {...} which maps the
first element of the stream, leaving other elements intact. It could
be implemented as prepend(sentinel).pairMap((left, right) -> left ==
sentinel ? mapper.apply(right) : right) (prepend can be trivially
expressed via concat()). It's possible (though hard) to implement
parallel pairMap using spliterator() escape hatch, and it will do its
work nicely without performance hiccups and using only the constant
amount of memory per every forked parallel task. I think such an
operation is a good test for new extensions. If pairMap could be
expressed in terms of newly-proposed operations, and it would nicely
work in parallel, it would be a strong argument that the new API is
good.

2. Collapse family. The basic idea is 'anti-flatMap'. It processes the
stream respecting its order, and sometimes combines adjacent elements
to a single one using different rules. It normally uses BiPredicate<T,
T> to check whether two adjacent elements should be collapsed. There
are at least five public operations in this family:
  Stream<T> collapse(BiPredicate<? super T, ? super T> collapsible) --
like your proposed collapseRuns or deduplicateAdjacent
  Stream<T> collapse(BiPredicate<? super T, ? super T> collapsible,
BinaryOperator<T> merger) -- similar but with custom associative
operation that merges collapsible elements
  <R, A> Stream<R> collapse(BiPredicate<? super T, ? super T>
collapsible, Collector<? super T, A, R> collector) -- similar but
merging collapsible elements using the specified collector
  Stream<Entry<T, Long>> runLengths() -- produces pairs that track
number of elements collapsed into one
  Stream<List<T>> groupRuns(BiPredicate<? super T, ? super T>
sameGroup) -- like collapse(collapsible, toList()) but much better
optimized
  <U> Stream<U> intervalMap(BiPredicate<? super T, ? super T>
sameInterval, BiFunction<? super T, ? super T, ? extends U> mapper) --
mapper applies to the first and last element of every interval.
Possible application: convert Stream(1,2,3,6,7,8) to Stream(new
Interval(1, 3), new Interval(6, 8)) (collapse adjacent numbers into a
single 'interval' record)

  It's also possible (though very hard) to provide efficient
parallelizable implementation of these methods using spliterator().
Again, if a new API allows doing this simpler without much performance
overhead, it would be a big win. The proposed implementation provides
no combiner, so apparently it's not parallel-friendly.

Other operations that people may want:
  <V, R> Stream<R> zipWith(BaseStream<V, ?> other, BiFunction<? super
T, ? super V, ? extends R> mapper) -- zip two streams (one can zip
with IntStream.range(0, ...).boxed() to get a stream of elements with
their indices). Quite impossible to parallelize efficiently in the
general case
  Stream<T> ifEmpty(Stream<? extends T> another) -- replace contents
of this stream with another stream but only if this stream is
completely empty. Surprisingly useful, somewhat like orElseGet in
Optional. Is it possible to parallelize efficiently if the original
stream is empty and the other is parallel?

Another thing that I noticed when extending Stream API is that
short-circuiting collectors would be a good addition. I have such an
API, and there are a number of such collectors:
  <T> Collector<T, ?, Optional<T>> onlyOne() -- returns element if the
stream contains exactly one element; otherwise returns empty optional.
Stops if the second element is observed
  <T extends Enum<T>> Collector<T, ?, EnumSet<T>> toEnumSet(Class<T>
enumClass) -- collects stream of enum values to EnumSet. Stops if all
values are already there
  <T> Collector<T, ?, Optional<T>> first() -- just first element of the stream
  <T> Collector<T, ?, List<T>> head(int n) -- first n elements of the stream
  <T, S extends Collection<T>> Collector<S, ?, Set<T>> intersecting()
-- intersection of collections in the stream. Stops if the current
intersection is empty.
  <T> Collector<T, ?, OptionalInt> andingInt(ToIntFunction<T> mapper)
-- perform bitwise & on results of mapper function. Stops if the
current result is 0.
  Collector<CharSequence, ?, String> commonPrefix() -- finds common
prefix for the stream of char sequences. Stops if common prefix is
already empty
  <T> Collector<T, ?, Optional<T>> reducingWithZero(T zero,
BinaryOperator<T> op) -- more generic reduction collector which stops
if current value reaches the supplied zero value
And so on. The most useful is probably a flavor of joining() which can
limit the resulting string, adding an ellipsis (and stopping consuming
the input, of course). To implement them, we need only one new
Predicate<A> finished() method in the collector that tells for current
accumulator if we reached the end or not (and probably a new
characteristic). Many combining collectors (mapping, filtering,
flatMapping, partitioningBy) can be adapted to produce a
short-circuiting collector if the downstream collector is
short-circuiting. All of these collectors can parallelize nicely. I
needed to hack the collect() terminal operation to support this stuff
properly.

With best regards,
Tagir Valeev.

On Tue, Jun 27, 2023 at 7:11?PM Viktor Klang <viktor.klang at oracle.com> wrote:
>
> Hi core-libs-dev,
>
> Over the past 6+ months I've been thinking about, and tinkering with, how we'd be able to expose a user-facing API for extensible intermediate java.util.stream.Stream operations?a feature envisioned all the way back when Streams were created.
>
> I'm now at a point where I have a viable design and implementation, and so I'm turning to you for your feedback: on the direction taken; the API concepts; and, in particular, is there anything which I have overlooked/missed?
>
> (If you, like myself, prefer reading pre-rendered markdown, click here)
>
>
>
>
> # Gathering the streams
>
> ## Introduction
>
> Java 8 introduced the `java.util.stream` API, which represents a lazily
> computed, potentially unbounded sequence of values (Streams was also the first
> designed-for-lambdas API in the JDK). Streams supports the ability to process
> the stream either sequentially or in parallel.
>
> A `Stream` pipeline consists of a source (collection, array, generator, etc),
> zero or more intermediate operations (`Stream` -> `Stream` transforms), and an
> eager terminal operation which produces a value or a side-effect.
>
> The Streams API come with a reasonably rich, but fixed set of built-in
> operations (mapping, filtering, reduction, sorting, etc), as well as an
> extensible terminal operation (`Stream::collect`) that enables the stream
> contents to be flexibly summarized in a variety of forms.  The resulting API is
> rich enough that users have had good experience with streams, but there are
> repeated requests for "please add operation X to streams".
>
> In this document, we explore a corresponding extensible _intermediate_
> operation, called `Stream::gather`, which is able to address many of the
> requests we've gotten for additional operations.
>
> ## "Missing" intermediate operations
>
> Over the years, many new operations for streams have been proposed.  Each of
> them may be useful in some situation, but many of them are too narrow to be
> included in the core `Stream` API.  We'd like for people to be able to plug
> these operations in via an extension point, as with `Stream::collect`.
>
> Here are some examples of proposed intermediate operations that are not easily
> expressible as intermediate operations on `Stream` today.
>
> * **Folds**.  Folding is a generalization of reduction.  With reduction, the
>   result type is the same as the element type, the combiner is associative, and
>   the initial value is an identity for the combiner.   For a fold, these
>   conditions are not required, though we give up parallelizability.
>
>   Example: `foldLeft("", (str,elem) -> str + " " + elem.toString())` over the values
>   `[1,2,3]` yields `["1 2 3"]`.
>
>   See https://bugs.openjdk.org/browse/JDK-8133680 & https://bugs.openjdk.org/browse/JDK-8292845
>
> * **Unfolds**.  This takes an aggregate and decomposes it into elements.  An
>   `unfold` can reverse the operation of the above fold example using `Scanner`
>   or `String::split`.
>
>   Example: `unfold(e -> new Scanner(e), Scanner::hasNextInt, Scanner::nextInt)`
>   `["1 2 3"]` yields `[1,2,3]`.
>
>   See: https://bugs.openjdk.org/browse/JDK-8151408
>
> * **Barriers**.  Usually all operations of a stream pipeline can run
>   simultaneously as data is available.  In some cases, we may wish to have a
>   barrier that requires that the entirety of one operation is completed before
>   providing any elements to the next operation.
>
>   Example: `someStream.a(...).barrier(someEffect)...` would require that all
>   effects from `a` are completed before executing `someEffect` or producing any
>   downstream values.
>
>   See: https://bugs.openjdk.org/browse/JDK-8294246
>
> * **Windowing**.  Given a stream, we may wish to construct a stream which
>   groups the original elements, either in overlapping or disjoint groups.
>
>   Example: `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
>   Example: `slidingWindow(2)` over the values `[1,2,3]` yields `[[1,2],[2,3],[3,4]]`.
>
>   See: https://stackoverflow.com/questions/34158634/how-to-transform-a-java-stream-into-a-sliding-window
>
> * **Prefix scans**. Prefix scans are a stream of incremental reductions.
>   Perhaps surprisingly, some prefix scans are parallelizable, and we are exploring adding support for that beyond `Arrays.parallelPrefix()`.
>
>   Example: `scan((sum, next) -> sum + next)` over  values `[1,2,3,4]` yields `[1,3,6,10]`
>
>   See: https://stackoverflow.com/questions/55265797/cumulative-sum-using-java-8-stream-api
>
> * **Duplicated elements**.  The `distinct` operation will remove duplicates; sometimes we want only the elements that are duplicated.
>
>   Example: `duplicates(Object::equals)` over values `[1,1,2,3,4]` yields `[1]`
>
>   See: https://stackoverflow.com/questions/27677256/java-8-streams-to-find-the-duplicate-elements
>
> * **Running duplicate elimination**.  Here, we want to eliminate adjacent repeated elements.
>
>   Example: `collapseRuns(Object::equals)` over values `[1,1,2,3,3]` yields `[1,2,3]`
>
> These are just a few of the stream operations people have wished for?
> and while many operations are too specialized to include in the core library,
> all are things we'd like for people to be able to express with streams.
>
> ## Extending streams
>
> It was always desired for `java.util.stream.Stream` to have an extension point
> for intermediate operations; when the library was first built, this wish-list
> item was recorded: https://bugs.openjdk.org/browse/JDK-8132369.  There were many
> reasons that this was not included in the initial version, the most important
> being that it was not at all obvious what the right API was.
>
> The set of intermediate operations on Streams carries the exact same trade-off
> as [CISC](Complex Instruction Set Computing) vs [RISC](Reduced Instruction Set
> Computing), namely: either you have to provide a rather sizeable set of
> specialized operations, or you provide a small set of general operations.
>
> For the **CISC**-strategy, the main drawback is that not all operations is
> equally useful, and having a large set of operations to choose from creates a
> barrier to effective usage by making the correct choice harder to identify.
>
> For the **RISC**-strategy, the main drawback is that it puts more effort on the
> user to encode more specialized operations over a set of generic operations,
> making code harder to read, and harder to maintain, for the user.
>
> However, one success story was `Collector`; this allowed us to extend _terminal_
> operations with a good balance of expressiveness, reuse, and API footprint.  We
> would like to do the same for intermediate operations -- and we can draw some
> inspiration from `Collector` to get there.
>
> ## Requirements
>
> Breaking down operations into intermediate and terminal is a useful distinction, however,
> in reality there are many more characteristics we could use to describe operations,
> and relatively few operations use exactly the same subset of characteristics.
> The following is a curated set of characteristics of stream operations;
> if we want to enable generic, user-defineable, intermediate operations on streams,
> we probably have to provide for them all.
>
> | Ordinal | Feature                  | What this means in practice                                 | Example operation(s)                |
> |---------|--------------------------|-------------------------------------------------------------|-------------------------------------|
> |    1    | Intermediate operation   | Add custom new operations to Stream pipelines               | *map*, *filter*                     |
> |    2    | Incremental operation    | Evaluate the Stream pipeline depth-first                    | *map*, *filter*                     |
> |    3    | Stateful operation       | Remember information between processing elements            | *limit*, *foldLeft*                 |
> |    4    | N:M inputs-to-outputs    | Encode a wide array of operations                           | *limit*, *flatMap*                  |
> |    5    | Prefix consumption       | An operation should consume only as much as needed          | *limit*, *takeWhile*                |
> |    6    | Beginning-of-stream hook | Ability to have initialization logic                        | *foldLeft*, *grouped*               |
> |    7    | End-of-stream hook       | Flush elements downstream                                   | *sorted*, *grouped*                 |
> |    8    | Opt-in parallelizability | Speed up CPU-bound processing for parallelizable operations | *reduce*, *map*                     |
>
> Now when we have a better idea of what we need to achieve, let's have a look at
> what our options are.
>
> ## Comparing existing operations
>
> Let's look at the operations we already have, to see if they would fit the bill
> as a generic extension point for intermediate `Stream`-operations.
>
> These are, in order, `Stream.map()`, `Stream.flatMap(?)` (`Stream.mapMulti(?)`
> is analogous), and `Collector` & `Stream.collect(?)`?and in the table below we
> see how they line up against our requirements.
>
> | Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector |
> |---------|--------------------------|---------------------------|---------------------------|-----------------|
> |    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    |
> |    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    |
> |    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             |
> |    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         |
> |    5    | Prefix consumption       | No                        | No                        | No              |
> |    6    | Beginning-of-stream hook | No                        | No                        | Yes             |
> |    7    | End-of-stream hook       | No                        | No                        | Yes             |
> |    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   |
>
> Looking at the options above, none of them are going to, as-is, fit the bill as
> an extension point for generic intermediate `Stream` operations, but one of them
> has more promise than the others: `Collector`.  Obvious needed upgrades are
> supporting short-circuiting and incremental generation of output; let's see what
> that looks like in practice.
>
> ## Collector 2.0
>
> Let's start with a clone of `Collector<T,A,R>` called `Gatherer<T,A,R>`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     Supplier<A> supplier();
>     BiConsumer<A, T> accumulator();
>     BinaryOperator<A> combiner();
>     Function<A, R> finisher();
> }
> ```
>
> Now, we need to make it output 0...M elements instead of strictly 1.  In order
> to do that, we need a way to programmatically output elements from the
> `accumulator` to make it incremental (and has the added benefit that it would be
> able to run depth-first).  Adding an additional argument, a downstream handle,
> to `accumulator` and `finisher` allows us to push elements downstream both for
> each input, and at the end of stream. As there exists no suitable pre-existing
> interface, we'll define a new interface named `Integrator` and rename `accumulator`
> to the more fitting `integrator`.
> Our `finisher` will also not have a useful return value, so we'll make it `void`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     interface Integrator<A,T,R> {
>         void integrate(A state, T element, Consumer<? super R> downstream);
>     }
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Consumer<? super> R> finisher();
> }
> ```
>
> Next, we need to tackle short-circuiting and add an upstream signal from each
> invocation of the `integrator` so we can detect when the integration does not
> want any more elements. We do this by returning a boolean from `integrate`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     interface Integrator<A,T,R> {
>         boolean integrate(A state, T element, Consumer<? super R> downstream);
>     }
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Consumer<? super> R> finisher();
> }
> ```
>
> Transitively supporting short-circuiting, i.e. that a downstream handle does
> not want to receive any more elements, requires us to make the same change as
> we did for `integrate`?return a `boolean` instead of `void`, and since the
> only built-in candidate would be `Predicate`, which is not supposed to have
> side-effects, let's introduce our own type `Sink`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     interface Sink<R> {
>         boolean flush(R element);
>     }
>     interface Integrator<A,T,R> {
>         boolean integrate(A state, T element, Sink<? super R> downstream);
>     }
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Sink<? super R>> finisher();
> }
> ```
>
> Finally, we need to address parallelism.  To opt-in to parallelism we can make
> the combiner optional -- we call it only for parallel executions, and if it is
> not present, execution is constrained to sequential.
>
> To demonstrate how all of the above fits together, we implement `fixedWindow(N)`
> where `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
>
> ```java
>     /**
>      * Gathers elements into fixed-size windows. The last window can contain fewer elements.
>      * @param windowSize the size of the windows
>      * @return a new gatherer which gathers elements into fixed-size windows
>      * @param <T> the type of elements this Gatherer gathers
>      */
>     public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
>         if (windowSize < 1)
>             throw new IllegalArgumentException("'windowSize' must be greater than zero");
>         else {
>             Supplier<ArrayList<T>> supplier =
>                 () ->  new ArrayList<T>(windowSize);
>
>             Integrator<ArrayList<T>, T, List<T>> integrator =
>                 (openWindow, element, downstream) -> {
>                     if (openWindow.add(element) && openWindow.size() >= windowSize) {
>                         var closedWindow = List.copyOf(openWindow);
>                         openWindow.clear();
>                         return downstream.flush(closedWindow);
>                     } else
>                         return true;
>                 };
>
>             // This combiner signals that we opt-out of parallelisation
>             BinaryOperator<ArrayList<T>> combiner =
>                 Gatherer.unsupportedCombiner();
>
>             BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher =
>                 (openWindow, downstream) -> {
>                     if(!openWindow.isEmpty()) {
>                         downstream.flush(List.copyOf(openWindow));
>                         openWindow.clear();
>                     }
>                 };
>
>             return Gatherer.of(supplier, integrator, combiner, finisher);
>         }
>     }
> ```
>
> Or by implementing the `Gatherer` interface directly like so:
>
> ```java
>     /**
>      * Gathers elements into fixed-size windows. The last window can contain fewer elements.
>      * @param windowSize the size of the windows
>      * @return a new gatherer which gathers elements into fixed-size windows
>      * @param <T> the type of elements this Gatherer gathers
>      */
>     public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
>         if (windowSize < 1)
>             throw new IllegalArgumentException("'windowSize' must be greater than zero");
>
>         class FixedWindowGatherer implements Gatherer<T,ArrayList<T>,List<T>> {
>             @Override
>             public Supplier<ArrayList<T>> initializer() {
>                 return () -> new ArrayList<>(windowSize);
>             }
>
>             @Override
>             public Integrator<ArrayList<T>, T, List<T>> integrator() {
>                 return (openWindow, element, downstream) -> {
>                     if (openWindow.add(element) && openWindow.size() >= windowSize) {
>                         var closedWindow = List.copyOf(openWindow);
>                         openWindow.clear();
>                         return downstream.flush(closedWindow);
>                     } else
>                         return true;
>                 };
>             }
>
>             @Override
>             public BinaryOperator<ArrayList<T>> combiner() {
>                 return Gatherer.unsupportedCombiner();
>             }
>
>             @Override
>             public BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher() {
>                 return (openWindow, downstream) -> {
>                     if(!openWindow.isEmpty()) {
>                         downstream.flush(List.copyOf(openWindow));
>                         openWindow.clear();
>                     }
>                 };
>             }
>         }
>         return new FixedWindowGatherer();
>     }
> ```
>
> Compared to Collector, it would look like the following:
>
> | Ordinal | Feature                  | `Collector<T,A,R>`                | `Gatherer<T,A,R>`                     |
> |---------|--------------------------|-----------------------------------|---------------------------------------|
> |    1    | Beginning-of-stream hook | `A supply()`                      | `A supply()`                          |
> |    2    | Per element              | `void accept(A, T)`               | `boolean integrate(A, T, Sink<R>)`    |
> |    3    | End-of-stream hook       | `R apply(A)`                      | `void accept(A, Sink<R>)`             |
> |    4    | Parallelizability        | `A apply(A, A)`                   | `A apply(A, A)`                       |
>
> To integrate it with `java.util.stream.Stream` we add the following method to
> it: `Stream<R> gather(Gatherer<T,?,R> gatherer)`
>
> Now we can use our `fixedWindow` Gatherer:
>
> ```java
> jshell> Stream.iterate(0, i -> i + 1).limit(10).gather(fixedWindow(2)).toList();
> $1 ==> [[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]]
> ```
>
> Gatherer now provides all features:
>
> | Ordinal | Feature                  | Using Gatherer          | Explanation                                                                            |
> |---------|--------------------------|-------------------------|----------------------------------------------------------------------------------------|
> |    1    | Intermediate operation   | Yes                     | A Gatherer's output is the following operation's input                                 |
> |    2    | Incremental operation    | Yes                     | A Gatherer can produce elements in response to consuming elements                      |
> |    3    | Stateful operation       | Yes                     | A Gatherer supplies its own state, which can be Void/null if stateless                 |
> |    4    | N:M inputs-to-outputs    | Yes                     | A Gatherer can consume and produce any number of elements                              |
> |    5    | Prefix consumption       | Yes                     | A Gatherer can signal that it is done by returning `false` from its `integrate`-method |
> |    6    | Beginning-of-stream hook | Yes                     | A Gatherer can run logic when creating its initial state                               |
> |    7    | End-of-stream hook       | Yes                     | A Gatherer's `finisher` is invoked at the end of input                                 |
> |    8    | Opt-in parallelizability | Yes                     | A Gatherer's `combiner` is optional                                                    |
>
> ## Summary
>
> None of the current candidates for a user-extensible API for generic
> intermediate stream operations fit the set of requirements, but `Collector`
> can form an excellent basis for a new construct, called `Gatherer`,
> which after a limited set of modifications checks all the boxes:
>
> | Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector | Using Gatherer |
> |---------|--------------------------|---------------------------|---------------------------|-----------------|----------------|
> |    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    | Yes            |
> |    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    | Yes            |
> |    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             | Yes            |
> |    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         | Yes            |
> |    5    | Prefix consumption       | No                        | No                        | No              | Yes            |
> |    6    | Beginning-of-stream hook | No                        | No                        | Yes             | Yes            |
> |    7    | End-of-stream hook       | No                        | No                        | Yes             | Yes            |
> |    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   | Yes            |
>
> As it turned out, we were a short hop away from a generic, stand-alone,
> reusable, parallelizable, API for intermediate operations all along!
>
> ## But wait ? there's more
>
> While the aforementioned solution contains the bare-minimum to meet our requirements,
> the following will provide some significant quality-of-life improvements.
>
> ### Compositionality
>
> The astute reader may have noticed that by adding the `gather(Gatherer)`-method on `Stream`,
> one can in-effect **compose** `Gatherer`s together:
>
> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Stream<Long> stream = Stream.of(1).gather(someGatherer).gather(someOtherGatherer);
> ```
>
> As it turns out, it is possible to define a `default Gatherer andThen(Gatherer)`-method on `Gatherer` which composes `Gatherer`s:
>
> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Gatherer<Integer,?,Long> gatherer = someGatherer.andThen(someOtherGatherer);
> ```
>
> This makes it possible to both de-couple operations from their use-sites,
> as well as create more sophisticated `Gatherer`s from simple ones.
>
> But that's not all?by introducing a `default Collector collect(Collector)`-method
> it is also possible to compose a `Gatherer` with a `Collector`,
> and the result is another `Collector`:
>
> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Collector<Long,?,List<Long>> someGatherer.andThen(someOtherGatherer).collect(Collectors.toList());
> ```
>
> All of this together, it is now possible to build `Stream`-processing:
> "source-to-destination" using `Stream.gather(?).gather(?).gather(?)`;
> "intermediaries-first" using `gatherer.andThen(?).andThen(?);` and,
> "destination-to-source" using `gatherer.collect(otherGatherer.collect(?))`.
>
> ### Familiarity
>
> Since `Gatherer` is an evolution of `Collector` there's a clear on-ramp
> for any and all Java developers who are already familiar with `Collector`.
>
> ### Reusability
>
> `Gatherer`s, by virtue of being stand-alone, reusable, intermediaries,
> paired with compositionality and opt-in parallelization, allows for transformations
> to be created once and maintained in a single place, no matter if it is going to be
> used as a `Collector`, a `Gatherer`, or a `Stream`.
>
> ### Optimizability
>
> `Collector` has the notion of `Characteristics`, a `Set` of flags which describes them.
> This information can then be used by the underlying machinery which uses them
> to optimize their evaluation. The same approach can be used for `Gatherer`s.
>
> ### Summary 2.0
>
> Taking all of the above into consideration, we end up with a definition like the following:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>
>     interface Sink<R> {
>         boolean flush(R element);
>     }
>
>     interface Integrator<A,T,R> {
>         boolean integrate(A state, T element, Sink<? super R> downstream);
>     }
>
>     enum Characteristics {
>         GREEDY,          // Never short-circuits
>         SIZE_PRESERVING, // Emits exactly once per input element
>         STATELESS;       // No need to initialize or combine state
>     }
>
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Sink<? super R>> finisher();
>     Set<Characteristics> characteristics();
>
>     default <AA, RR> Gatherer<T,?,RR> andThen(Gatherer<R,AA,RR> that) {
>         // Gatherers is analoguous to Collectors
>         return Gatherers.Composite.of(this, that);
>     }
>
>     default <RR> Collector<T,?,RR> collect(Collector<R, ?, RR> collector) {
>         // Gatherers is analoguous to Collectors
>         return Gatherers.GathererCollector.of(this, collector);
>     }
> }
> ```
>
> ## Appetizers
>
> The following examples showcase how `Gatherer` can be used to implement a diverse set
> of pre-existing, and future, intermediate operations for `Stream`s.
>
> ### How to implement `map(mapper)`
>
> ```java
> public final static <T,R> Gatherer<T, ?, R> map(Function<? super T, ? extends R> mapper) {
>     return Gatherer.of(
>         () -> (Void)null,
>         (nothing, element, downstream) ->
>             downstream.flush(mapper.apply(element)),
>         (l,r) -> l,
>         (nothing, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(map(i -> i + 1)).toList()
> $1 ==> [2, 3, 4, 5]
> ```
>
> ### How to implement `flatMap(mapper)`
>
> ```java
> public final static <T,R> Gatherer<T, ?, R> flatMap(Function<? super T, ? extends Stream<R>> mapper) {
>     return Gatherer.of(
>         () -> (Void)null,
>         (nothing, element, downstream) -> {
>             try(Stream<? extends R> s = mapper.apply(element)) {
>                 return s == null || s.sequential().allMatch(downstream::flush);
>             }
>         },
>         (l,r) -> l,
>         (nothing, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(flatMap(i -> Stream.of(i + 1))).toList()
> $1 ==> [2, 3, 4, 5]
> ```
>
> ### How to implement `takeWhile(predicate)`
>
> ```java
> public final static <T> Gatherer<T, ?, T> takeWhile(Predicate<? super T> predicate) {
>     return Gatherer.of(
>         () -> (Void)null,
>         (nothing, element, downstream) ->
>             predicate.test(element) && downstream.flush(element),
>         (l, r) -> l,
>         (nothing, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(takeWhile(i -> i < 3)).toList()
> $1 ==> [1, 2]
> ```
>
> ### How to implement `limit(N)`
>
> ```java
> public static <M> Gatherer<M, ?, M> limit(long limit) {
>     if (limit < 0)
>         throw new IllegalArgumentException("'limit' has to be non-negative");
>
>     class At { long n = 0; }
>     return Gatherer.of(
>             At::new,
>             (at, element, downstream) ->
>                 at.n < limit && downstream.flush(element) && ++at.n < limit,
>             Gatherer.unsupportedCombiner(),
>             (at, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(limit(2)).toList()
> $1 ==> [1, 2]
> ```
>
> ### How to implement prefix `scanLeft`
>
> ```java
> public static <T,R> Gatherer<T,?,R> scanLeft(R initial, BiFunction<R,T,R> scanner) {
>     class State { R current = initial; }
>     return Gatherer.of(
>             State::new,
>             (state, element, downstream) ->
>                 downstream.flush(state.current = scanner.apply(state.current, element)),
>             Gatherer.unsupportedCombiner(),
>             (state, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(scanLeft("'", (acc, elem) -> acc + elem + "'")).toList()
> $1 ==> ['1', '1'2', '1'2'3', '1'2'3'4']
> ```
>
> ### How to implement `fold(initial, folder)`
>
> ```java
> public static <T> Gatherer<T,?,T> fold(T initial, BinaryOperator<T> folder) {
>     class State { T current = initial; }
>     return Gatherer.of(
>         State::new,
>         (state, element, downstream) -> {
>             state.current = folder.apply(state.current, element);
>             return true;
>         },
>         (l, r) -> {
>             l.current = folder.apply(l.current, r.current);
>             return l;
>         },
>         (state, downstream) -> downstream.flush(state.current)
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(fold(0, (acc, elem) -> acc + elem)).toList()
> $1 ==> [10]
> ```
>
> ### How to implement `foldLeft(initial, folder)`
>
> ```java
> public static <T,R> Gatherer<T,?,R> foldLeft(R initial, BiFunction<R,T,R> folder) {
>     class State { R current = initial; }
>     return Gatherer.of(
>         State::new,
>         (state, element, downstream) -> {
>             state.current = folder.apply(state.current, element);
>             return true;
>         },
>         Gatherer.unsupportedCombiner(),
>         (state, downstream) -> downstream.flush(state.current)
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(foldLeft(0L, (acc, elem) -> acc + elem)).toList()
> $1 ==> [10]
> ```
>
> ### How to implement `deduplicateAdjacent()`
>
> ```java
> public static <T> Gatherer<T,?,T> deduplicateAdjacent() {
>     class State { T prev; boolean hasPrev; }
>     return Gatherer.of(
>         State::new,
>         (state, element, downstream) -> {
>             if (!state.hasPrev) {
>                 state.hasPrev = true;
>                 state.prev = element;
>                 return downstream.flush(element);
>             } else if (!Objects.equals(state.prev, element)) {
>                 state.prev = element;
>                 return downstream.flush(element);
>             } else {
>                 return true; // skip duplicate
>             }
>         },
>         Gatherer.unsupportedCombiner(),
>         (state, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,2,3,2,4).gather(deduplicateAdjacent()).toList()
> $1 ==> [1, 2, 3, 2, 4]
> ```
>

From rriggs at openjdk.org  Wed Jun 28 20:22:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 28 Jun 2023 20:22:01 GMT
Subject: RFR: 8310033: Clarify return value of Java Time compareTo methods
 [v4]
In-Reply-To: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
References: <3X5hQPE85CXqfrlCtTnuP9XlaIttZGmlrgT5pi1lHms=.883f9c5c-e36d-444e-a6a8-6f5d91a28796@github.com>
Message-ID: <O3GEFg-3Zc0sIEUZ0kLAwG8jU8cmJ9nwy7C1moGWZbo=.95214208-4a57-4eda-97bb-2f2a935e4770@github.com>

> In java.time packages, clarify timeline order javadoc to mention "before" and "after" in the value of the `compareTo` method return values. 
> Add javadoc @see tags to isBefore and isAfter methods
> 
> Replace use of "negative" and positive with "less than zero" and "greater than zero" in javadoc @return
> The term "positive" is ambiguous, zero is considered positive and indicates equality.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Improve descriptions to be more specific and remove inappropriate use of before/after
  Remove extra blank lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14479/files
  - new: https://git.openjdk.org/jdk/pull/14479/files/a0acac19..62f01b5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14479&range=02-03

  Stats: 16 lines in 9 files changed: 0 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14479/head:pull/14479

PR: https://git.openjdk.org/jdk/pull/14479

From naoto at openjdk.org  Wed Jun 28 20:23:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Jun 2023 20:23:01 GMT
Subject: RFR: 8310241: OffsetDateTime compareTo redundant computation [v2]
In-Reply-To: <xYTzl-aQuM2OBce4oRJtQuNQxEsofVyPkkeew8QuwEk=.2abc5a12-302e-447c-9dec-1212fc48031e@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
 <xYTzl-aQuM2OBce4oRJtQuNQxEsofVyPkkeew8QuwEk=.2abc5a12-302e-447c-9dec-1212fc48031e@github.com>
Message-ID: <MpHz1XOs0QYLdUf6npaRKpg0DabBes_OPrQsXBnwaxo=.43853ec7-d2ed-4946-ba09-87d05c794865@github.com>

On Wed, 28 Jun 2023 17:46:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
>> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
>> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
>> The code is refactored in `compareTo` to do the comparison of `LocalDateTime` exactly once, if it is needed.
>> 
>> This case is NOT covered by an existing test in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reopen to work on an improved fix
>   Add a test for the specific condition being optimized, the test was missing in the original.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14618#pullrequestreview-1503926085

From naoto at openjdk.org  Wed Jun 28 20:23:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 Jun 2023 20:23:54 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <u4sem03Y7DOtH4M6BTiCNFdw1umudZ2DuMAvhlPZkQA=.e6cb35d8-d1e8-445b-bada-f2df5f2ac119@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

+1

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1503927831

From jlu at openjdk.org  Wed Jun 28 20:27:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Jun 2023 20:27:28 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v2]
In-Reply-To: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
Message-ID: <NQYItq5p7CEaF7S1IR7B8jn2ehTYxYVRwlQM-0sgXTs=.1cbbdc16-9d2a-499c-9c47-06118551e2a4@github.com>

> Please review this PR which refactors Currency tests to use JUnit.
> 
> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
> 
> - Tests are no longer dependent on each other (order of execution does not matter)
> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
> 
> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Rename Bug4512215.java as MinorUndefinedCodes.java and update goal of test file
 - Refactor and improve ValidateISO4217.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/2d6ed5a7..bff5cc6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=00-01

  Stats: 496 lines in 3 files changed: 178 ins; 199 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

PR: https://git.openjdk.org/jdk/pull/14682

From prappo at openjdk.org  Wed Jun 28 20:32:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 28 Jun 2023 20:32:53 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <knF664yGNDuITQrtjJhNL39BT2I8O0EKq00TBcHyOdk=.8ed64435-04c2-4703-bbf9-60f6834a8d1b@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

While I still cannot see any malignancy in that race, the proposed change makes the code simpler to reason about and probably faster to execute. Also, the change does not seem to introduce new bugs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1612062693

From jlu at openjdk.org  Wed Jun 28 20:34:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Jun 2023 20:34:30 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v3]
In-Reply-To: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
Message-ID: <gjVX4xVkkclEu4u-3yLMbazqSsCY67d9ovLhp9xJmgI=.e14d348a-f168-43fb-bdb5-2b8e70c69953@github.com>

> Please review this PR which refactors Currency tests to use JUnit.
> 
> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
> 
> - Tests are no longer dependent on each other (order of execution does not matter)
> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
> 
> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Rename Bug8154295.java as NumCodeAsStringTest.java
 - Re-include the data version check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/bff5cc6c..3975c57f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=01-02

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

PR: https://git.openjdk.org/jdk/pull/14682

From brian.goetz at oracle.com  Wed Jun 28 20:37:10 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 28 Jun 2023 16:37:10 -0400
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <CAE+3fjbkkg=DKjMmb+is1TLbDe0XPRGeQ+vPQ64eG6Afbv9yNg@mail.gmail.com>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAE+3fjbkkg=DKjMmb+is1TLbDe0XPRGeQ+vPQ64eG6Afbv9yNg@mail.gmail.com>
Message-ID: <5a1e1cb5-ff29-4a75-43cb-62ef5d381f6c@oracle.com>

Thanks for these comments.? To respond indirectly to your point about 
parallelization, many of the challenges arise from a tradeoff made in 
designing Spliterator, that arises from the desire to be able to extract 
parallelism not only from the really easy case (arrays), but also more 
complex cases like trees.

Spliterator leaves the choice of where to split to the data structure, 
because the data structure knows how its data is laid out.? This lets, 
for example, trees split left-and-right, rather than trying to find a 
pivot point somewhere halfway down the right side of the tree.? This, in 
turn, reduces the cost of splitting and the cost of extracting the next 
element -- all critical elements in parallel performance.

What we traded away when we did this is the ability to predictably split 
in a given place (which makes parallel zipWith nearly impossible), and 
to a lesser degree to know where a split is in the traversal (a 
spliterator may, but is not required to, provide this information.)? 
This ripples into your pairMap example, though not in nearly a bad way 
as with zip; when pairMapping [ 1, 2, 3, 4, 5, 6 ], and let's say we 
split between 3 and 4, we know that f(4,5) and f(5, 6) are in the 
output, and we can precompute them, but we have to buffer until we 
combine so we can extract f(3, 4).? (Actually, whether we have to buffer 
depends on whether combination combines f(3, 4) into the left or right 
split.? For this particular problem, we'd not need to buffer if the 
extra element went into the left split.)

You have a worse problem with non-sliding windows, where we'd want to 
split the above stream into f(1, 2), f(3, 4), f(5, 6). When we split 
between 3 and 4, we may not know whether we're at an odd or even offset, 
so we might not even be able to start computing f(4, 5) because it might 
not be in the output at all.

Again, these come more from the deliberate design tradeoffs made with 
Spliterator, rather than from the particular way gatherers do their 
combination.? In some cases, it might even be more efficient to copy to 
the source to a more predictably splittable representation before 
parallel execution.



On 6/28/2023 4:15 PM, Tagir Valeev wrote:
> Hello!
>
> Interesting read, thanks. I'm the author of the StreamEx library,
> which actually enhances Stream API, and I use it during my daily job,
> so I have some thoughts about extending Stream API as well. Below are
> some of them.
>
> First, there are many useful operations that can be trivially defined
> in terms of existing operations. For example,
>    mapPartial(Function<? super T, ? extends Optional<? extends R>> mapper)
> It's essentially map(mapper).flatMap(Optional::stream), though it's
> much more performant to express it as
>    map(value -> mapper.apply(value).orElse(null)).filter(Objects::nonNull)
> It might be desired to encapsulate such implementations in static
> methods, and here .chain() or .transform() method would be helpful,
> seehttps://bugs.openjdk.org/browse/JDK-8140283.
>
> There are also some operations that cannot be expressed via existing
> 'normal' operations, and could be implemented taking spliterator() of
> the original stream.
> This is somewhat limited, especially taking into account how
> WrappingSpliterator handles tryAdvance and trySplit. Stream API would
> certainly benefit
> if it can be more transparent and provide better ways to extend it.
>
> One problematic place is how to provide a reasonable default
> implementation for new methods like 'gather'. There are many
> third-party implementations of Stream interface in the wild. Many of
> them
> just delegate most of the operations to JDK stream, adding some custom
> logic. It should be expected that calling 'gather' on them will work
> according to the spec.
>
> Another thing that bothers me is parallel stream support. Not every
> custom operation that you may imagine could be efficiently implemented
> for parallel streams. But for some operations this is certainly
> possible. It's unclear whether the proposed Gatherer interface is
> flexible enough to provide good parallelization for operations. I have
> a couple of exercises:
>
> 1. public <R> Stream<R> pairMap(BiFunction<? super T, ? super T, ?
> extends R> mapper) {...}
>    This operation processes overlapping adjacent pairs of the source
> stream (the resulting stream is one element shorter). It's quite
> useful, it's used 12 times in our production code. Also, it's a nice
> building block for other operations. For example, we have Stream<T>
> mapFirst(Function<? super T, ? extends T> mapper) {...} which maps the
> first element of the stream, leaving other elements intact. It could
> be implemented as prepend(sentinel).pairMap((left, right) -> left ==
> sentinel ? mapper.apply(right) : right) (prepend can be trivially
> expressed via concat()). It's possible (though hard) to implement
> parallel pairMap using spliterator() escape hatch, and it will do its
> work nicely without performance hiccups and using only the constant
> amount of memory per every forked parallel task. I think such an
> operation is a good test for new extensions. If pairMap could be
> expressed in terms of newly-proposed operations, and it would nicely
> work in parallel, it would be a strong argument that the new API is
> good.
>
> 2. Collapse family. The basic idea is 'anti-flatMap'. It processes the
> stream respecting its order, and sometimes combines adjacent elements
> to a single one using different rules. It normally uses BiPredicate<T,
> T> to check whether two adjacent elements should be collapsed. There
> are at least five public operations in this family:
>    Stream<T> collapse(BiPredicate<? super T, ? super T> collapsible) --
> like your proposed collapseRuns or deduplicateAdjacent
>    Stream<T> collapse(BiPredicate<? super T, ? super T> collapsible,
> BinaryOperator<T> merger) -- similar but with custom associative
> operation that merges collapsible elements
>    <R, A> Stream<R> collapse(BiPredicate<? super T, ? super T>
> collapsible, Collector<? super T, A, R> collector) -- similar but
> merging collapsible elements using the specified collector
>    Stream<Entry<T, Long>> runLengths() -- produces pairs that track
> number of elements collapsed into one
>    Stream<List<T>> groupRuns(BiPredicate<? super T, ? super T>
> sameGroup) -- like collapse(collapsible, toList()) but much better
> optimized
>    <U> Stream<U> intervalMap(BiPredicate<? super T, ? super T>
> sameInterval, BiFunction<? super T, ? super T, ? extends U> mapper) --
> mapper applies to the first and last element of every interval.
> Possible application: convert Stream(1,2,3,6,7,8) to Stream(new
> Interval(1, 3), new Interval(6, 8)) (collapse adjacent numbers into a
> single 'interval' record)
>
>    It's also possible (though very hard) to provide efficient
> parallelizable implementation of these methods using spliterator().
> Again, if a new API allows doing this simpler without much performance
> overhead, it would be a big win. The proposed implementation provides
> no combiner, so apparently it's not parallel-friendly.
>
> Other operations that people may want:
>    <V, R> Stream<R> zipWith(BaseStream<V, ?> other, BiFunction<? super
> T, ? super V, ? extends R> mapper) -- zip two streams (one can zip
> with IntStream.range(0, ...).boxed() to get a stream of elements with
> their indices). Quite impossible to parallelize efficiently in the
> general case
>    Stream<T> ifEmpty(Stream<? extends T> another) -- replace contents
> of this stream with another stream but only if this stream is
> completely empty. Surprisingly useful, somewhat like orElseGet in
> Optional. Is it possible to parallelize efficiently if the original
> stream is empty and the other is parallel?
>
> Another thing that I noticed when extending Stream API is that
> short-circuiting collectors would be a good addition. I have such an
> API, and there are a number of such collectors:
>    <T> Collector<T, ?, Optional<T>> onlyOne() -- returns element if the
> stream contains exactly one element; otherwise returns empty optional.
> Stops if the second element is observed
>    <T extends Enum<T>> Collector<T, ?, EnumSet<T>> toEnumSet(Class<T>
> enumClass) -- collects stream of enum values to EnumSet. Stops if all
> values are already there
>    <T> Collector<T, ?, Optional<T>> first() -- just first element of the stream
>    <T> Collector<T, ?, List<T>> head(int n) -- first n elements of the stream
>    <T, S extends Collection<T>> Collector<S, ?, Set<T>> intersecting()
> -- intersection of collections in the stream. Stops if the current
> intersection is empty.
>    <T> Collector<T, ?, OptionalInt> andingInt(ToIntFunction<T> mapper)
> -- perform bitwise & on results of mapper function. Stops if the
> current result is 0.
>    Collector<CharSequence, ?, String> commonPrefix() -- finds common
> prefix for the stream of char sequences. Stops if common prefix is
> already empty
>    <T> Collector<T, ?, Optional<T>> reducingWithZero(T zero,
> BinaryOperator<T> op) -- more generic reduction collector which stops
> if current value reaches the supplied zero value
> And so on. The most useful is probably a flavor of joining() which can
> limit the resulting string, adding an ellipsis (and stopping consuming
> the input, of course). To implement them, we need only one new
> Predicate<A> finished() method in the collector that tells for current
> accumulator if we reached the end or not (and probably a new
> characteristic). Many combining collectors (mapping, filtering,
> flatMapping, partitioningBy) can be adapted to produce a
> short-circuiting collector if the downstream collector is
> short-circuiting. All of these collectors can parallelize nicely. I
> needed to hack the collect() terminal operation to support this stuff
> properly.
>
> With best regards,
> Tagir Valeev.
>
> On Tue, Jun 27, 2023 at 7:11?PM Viktor Klang<viktor.klang at oracle.com>  wrote:
>> Hi core-libs-dev,
>>
>> Over the past 6+ months I've been thinking about, and tinkering with, how we'd be able to expose a user-facing API for extensible intermediate java.util.stream.Stream operations?a feature envisioned all the way back when Streams were created.
>>
>> I'm now at a point where I have a viable design and implementation, and so I'm turning to you for your feedback: on the direction taken; the API concepts; and, in particular, is there anything which I have overlooked/missed?
>>
>> (If you, like myself, prefer reading pre-rendered markdown, click here)
>>
>>
>>
>>
>> # Gathering the streams
>>
>> ## Introduction
>>
>> Java 8 introduced the `java.util.stream` API, which represents a lazily
>> computed, potentially unbounded sequence of values (Streams was also the first
>> designed-for-lambdas API in the JDK). Streams supports the ability to process
>> the stream either sequentially or in parallel.
>>
>> A `Stream` pipeline consists of a source (collection, array, generator, etc),
>> zero or more intermediate operations (`Stream` -> `Stream` transforms), and an
>> eager terminal operation which produces a value or a side-effect.
>>
>> The Streams API come with a reasonably rich, but fixed set of built-in
>> operations (mapping, filtering, reduction, sorting, etc), as well as an
>> extensible terminal operation (`Stream::collect`) that enables the stream
>> contents to be flexibly summarized in a variety of forms.  The resulting API is
>> rich enough that users have had good experience with streams, but there are
>> repeated requests for "please add operation X to streams".
>>
>> In this document, we explore a corresponding extensible _intermediate_
>> operation, called `Stream::gather`, which is able to address many of the
>> requests we've gotten for additional operations.
>>
>> ## "Missing" intermediate operations
>>
>> Over the years, many new operations for streams have been proposed.  Each of
>> them may be useful in some situation, but many of them are too narrow to be
>> included in the core `Stream` API.  We'd like for people to be able to plug
>> these operations in via an extension point, as with `Stream::collect`.
>>
>> Here are some examples of proposed intermediate operations that are not easily
>> expressible as intermediate operations on `Stream` today.
>>
>> * **Folds**.  Folding is a generalization of reduction.  With reduction, the
>>    result type is the same as the element type, the combiner is associative, and
>>    the initial value is an identity for the combiner.   For a fold, these
>>    conditions are not required, though we give up parallelizability.
>>
>>    Example: `foldLeft("", (str,elem) -> str + " " + elem.toString())` over the values
>>    `[1,2,3]` yields `["1 2 3"]`.
>>
>>    Seehttps://bugs.openjdk.org/browse/JDK-8133680  &https://bugs.openjdk.org/browse/JDK-8292845
>>
>> * **Unfolds**.  This takes an aggregate and decomposes it into elements.  An
>>    `unfold` can reverse the operation of the above fold example using `Scanner`
>>    or `String::split`.
>>
>>    Example: `unfold(e -> new Scanner(e), Scanner::hasNextInt, Scanner::nextInt)`
>>    `["1 2 3"]` yields `[1,2,3]`.
>>
>>    See:https://bugs.openjdk.org/browse/JDK-8151408
>>
>> * **Barriers**.  Usually all operations of a stream pipeline can run
>>    simultaneously as data is available.  In some cases, we may wish to have a
>>    barrier that requires that the entirety of one operation is completed before
>>    providing any elements to the next operation.
>>
>>    Example: `someStream.a(...).barrier(someEffect)...` would require that all
>>    effects from `a` are completed before executing `someEffect` or producing any
>>    downstream values.
>>
>>    See:https://bugs.openjdk.org/browse/JDK-8294246
>>
>> * **Windowing**.  Given a stream, we may wish to construct a stream which
>>    groups the original elements, either in overlapping or disjoint groups.
>>
>>    Example: `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
>>    Example: `slidingWindow(2)` over the values `[1,2,3]` yields `[[1,2],[2,3],[3,4]]`.
>>
>>    See:https://stackoverflow.com/questions/34158634/how-to-transform-a-java-stream-into-a-sliding-window
>>
>> * **Prefix scans**. Prefix scans are a stream of incremental reductions.
>>    Perhaps surprisingly, some prefix scans are parallelizable, and we are exploring adding support for that beyond `Arrays.parallelPrefix()`.
>>
>>    Example: `scan((sum, next) -> sum + next)` over  values `[1,2,3,4]` yields `[1,3,6,10]`
>>
>>    See:https://stackoverflow.com/questions/55265797/cumulative-sum-using-java-8-stream-api
>>
>> * **Duplicated elements**.  The `distinct` operation will remove duplicates; sometimes we want only the elements that are duplicated.
>>
>>    Example: `duplicates(Object::equals)` over values `[1,1,2,3,4]` yields `[1]`
>>
>>    See:https://stackoverflow.com/questions/27677256/java-8-streams-to-find-the-duplicate-elements
>>
>> * **Running duplicate elimination**.  Here, we want to eliminate adjacent repeated elements.
>>
>>    Example: `collapseRuns(Object::equals)` over values `[1,1,2,3,3]` yields `[1,2,3]`
>>
>> These are just a few of the stream operations people have wished for?
>> and while many operations are too specialized to include in the core library,
>> all are things we'd like for people to be able to express with streams.
>>
>> ## Extending streams
>>
>> It was always desired for `java.util.stream.Stream` to have an extension point
>> for intermediate operations; when the library was first built, this wish-list
>> item was recorded:https://bugs.openjdk.org/browse/JDK-8132369.  There were many
>> reasons that this was not included in the initial version, the most important
>> being that it was not at all obvious what the right API was.
>>
>> The set of intermediate operations on Streams carries the exact same trade-off
>> as [CISC](Complex Instruction Set Computing) vs [RISC](Reduced Instruction Set
>> Computing), namely: either you have to provide a rather sizeable set of
>> specialized operations, or you provide a small set of general operations.
>>
>> For the **CISC**-strategy, the main drawback is that not all operations is
>> equally useful, and having a large set of operations to choose from creates a
>> barrier to effective usage by making the correct choice harder to identify.
>>
>> For the **RISC**-strategy, the main drawback is that it puts more effort on the
>> user to encode more specialized operations over a set of generic operations,
>> making code harder to read, and harder to maintain, for the user.
>>
>> However, one success story was `Collector`; this allowed us to extend _terminal_
>> operations with a good balance of expressiveness, reuse, and API footprint.  We
>> would like to do the same for intermediate operations -- and we can draw some
>> inspiration from `Collector` to get there.
>>
>> ## Requirements
>>
>> Breaking down operations into intermediate and terminal is a useful distinction, however,
>> in reality there are many more characteristics we could use to describe operations,
>> and relatively few operations use exactly the same subset of characteristics.
>> The following is a curated set of characteristics of stream operations;
>> if we want to enable generic, user-defineable, intermediate operations on streams,
>> we probably have to provide for them all.
>>
>> | Ordinal | Feature                  | What this means in practice                                 | Example operation(s)                |
>> |---------|--------------------------|-------------------------------------------------------------|-------------------------------------|
>> |    1    | Intermediate operation   | Add custom new operations to Stream pipelines               | *map*, *filter*                     |
>> |    2    | Incremental operation    | Evaluate the Stream pipeline depth-first                    | *map*, *filter*                     |
>> |    3    | Stateful operation       | Remember information between processing elements            | *limit*, *foldLeft*                 |
>> |    4    | N:M inputs-to-outputs    | Encode a wide array of operations                           | *limit*, *flatMap*                  |
>> |    5    | Prefix consumption       | An operation should consume only as much as needed          | *limit*, *takeWhile*                |
>> |    6    | Beginning-of-stream hook | Ability to have initialization logic                        | *foldLeft*, *grouped*               |
>> |    7    | End-of-stream hook       | Flush elements downstream                                   | *sorted*, *grouped*                 |
>> |    8    | Opt-in parallelizability | Speed up CPU-bound processing for parallelizable operations | *reduce*, *map*                     |
>>
>> Now when we have a better idea of what we need to achieve, let's have a look at
>> what our options are.
>>
>> ## Comparing existing operations
>>
>> Let's look at the operations we already have, to see if they would fit the bill
>> as a generic extension point for intermediate `Stream`-operations.
>>
>> These are, in order, `Stream.map()`, `Stream.flatMap(?)` (`Stream.mapMulti(?)`
>> is analogous), and `Collector` & `Stream.collect(?)`?and in the table below we
>> see how they line up against our requirements.
>>
>> | Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector |
>> |---------|--------------------------|---------------------------|---------------------------|-----------------|
>> |    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    |
>> |    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    |
>> |    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             |
>> |    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         |
>> |    5    | Prefix consumption       | No                        | No                        | No              |
>> |    6    | Beginning-of-stream hook | No                        | No                        | Yes             |
>> |    7    | End-of-stream hook       | No                        | No                        | Yes             |
>> |    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   |
>>
>> Looking at the options above, none of them are going to, as-is, fit the bill as
>> an extension point for generic intermediate `Stream` operations, but one of them
>> has more promise than the others: `Collector`.  Obvious needed upgrades are
>> supporting short-circuiting and incremental generation of output; let's see what
>> that looks like in practice.
>>
>> ## Collector 2.0
>>
>> Let's start with a clone of `Collector<T,A,R>` called `Gatherer<T,A,R>`:
>>
>> ```java
>> /** @param <T> the element type
>>   *  @param <A> the (mutable) intermediate accumulation type
>>   *  @param <R> the (probably immutable) final accumulation type
>>   */
>> interface Gatherer<T,A,R> {
>>      Supplier<A> supplier();
>>      BiConsumer<A, T> accumulator();
>>      BinaryOperator<A> combiner();
>>      Function<A, R> finisher();
>> }
>> ```
>>
>> Now, we need to make it output 0...M elements instead of strictly 1.  In order
>> to do that, we need a way to programmatically output elements from the
>> `accumulator` to make it incremental (and has the added benefit that it would be
>> able to run depth-first).  Adding an additional argument, a downstream handle,
>> to `accumulator` and `finisher` allows us to push elements downstream both for
>> each input, and at the end of stream. As there exists no suitable pre-existing
>> interface, we'll define a new interface named `Integrator` and rename `accumulator`
>> to the more fitting `integrator`.
>> Our `finisher` will also not have a useful return value, so we'll make it `void`:
>>
>> ```java
>> /** @param <T> the element type
>>   *  @param <A> the (mutable) intermediate accumulation type
>>   *  @param <R> the (probably immutable) final accumulation type
>>   */
>> interface Gatherer<T,A,R> {
>>      interface Integrator<A,T,R> {
>>          void integrate(A state, T element, Consumer<? super R> downstream);
>>      }
>>      Supplier<A> supplier();
>>      Integrator<A, T, R> integrator();
>>      BinaryOperator<A> combiner();
>>      BiConsumer<A, Consumer<? super> R> finisher();
>> }
>> ```
>>
>> Next, we need to tackle short-circuiting and add an upstream signal from each
>> invocation of the `integrator` so we can detect when the integration does not
>> want any more elements. We do this by returning a boolean from `integrate`:
>>
>> ```java
>> /** @param <T> the element type
>>   *  @param <A> the (mutable) intermediate accumulation type
>>   *  @param <R> the (probably immutable) final accumulation type
>>   */
>> interface Gatherer<T,A,R> {
>>      interface Integrator<A,T,R> {
>>          boolean integrate(A state, T element, Consumer<? super R> downstream);
>>      }
>>      Supplier<A> supplier();
>>      Integrator<A, T, R> integrator();
>>      BinaryOperator<A> combiner();
>>      BiConsumer<A, Consumer<? super> R> finisher();
>> }
>> ```
>>
>> Transitively supporting short-circuiting, i.e. that a downstream handle does
>> not want to receive any more elements, requires us to make the same change as
>> we did for `integrate`?return a `boolean` instead of `void`, and since the
>> only built-in candidate would be `Predicate`, which is not supposed to have
>> side-effects, let's introduce our own type `Sink`:
>>
>> ```java
>> /** @param <T> the element type
>>   *  @param <A> the (mutable) intermediate accumulation type
>>   *  @param <R> the (probably immutable) final accumulation type
>>   */
>> interface Gatherer<T,A,R> {
>>      interface Sink<R> {
>>          boolean flush(R element);
>>      }
>>      interface Integrator<A,T,R> {
>>          boolean integrate(A state, T element, Sink<? super R> downstream);
>>      }
>>      Supplier<A> supplier();
>>      Integrator<A, T, R> integrator();
>>      BinaryOperator<A> combiner();
>>      BiConsumer<A, Sink<? super R>> finisher();
>> }
>> ```
>>
>> Finally, we need to address parallelism.  To opt-in to parallelism we can make
>> the combiner optional -- we call it only for parallel executions, and if it is
>> not present, execution is constrained to sequential.
>>
>> To demonstrate how all of the above fits together, we implement `fixedWindow(N)`
>> where `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
>>
>> ```java
>>      /**
>>       * Gathers elements into fixed-size windows. The last window can contain fewer elements.
>>       * @param windowSize the size of the windows
>>       * @return a new gatherer which gathers elements into fixed-size windows
>>       * @param <T> the type of elements this Gatherer gathers
>>       */
>>      public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
>>          if (windowSize < 1)
>>              throw new IllegalArgumentException("'windowSize' must be greater than zero");
>>          else {
>>              Supplier<ArrayList<T>> supplier =
>>                  () ->  new ArrayList<T>(windowSize);
>>
>>              Integrator<ArrayList<T>, T, List<T>> integrator =
>>                  (openWindow, element, downstream) -> {
>>                      if (openWindow.add(element) && openWindow.size() >= windowSize) {
>>                          var closedWindow = List.copyOf(openWindow);
>>                          openWindow.clear();
>>                          return downstream.flush(closedWindow);
>>                      } else
>>                          return true;
>>                  };
>>
>>              // This combiner signals that we opt-out of parallelisation
>>              BinaryOperator<ArrayList<T>> combiner =
>>                  Gatherer.unsupportedCombiner();
>>
>>              BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher =
>>                  (openWindow, downstream) -> {
>>                      if(!openWindow.isEmpty()) {
>>                          downstream.flush(List.copyOf(openWindow));
>>                          openWindow.clear();
>>                      }
>>                  };
>>
>>              return Gatherer.of(supplier, integrator, combiner, finisher);
>>          }
>>      }
>> ```
>>
>> Or by implementing the `Gatherer` interface directly like so:
>>
>> ```java
>>      /**
>>       * Gathers elements into fixed-size windows. The last window can contain fewer elements.
>>       * @param windowSize the size of the windows
>>       * @return a new gatherer which gathers elements into fixed-size windows
>>       * @param <T> the type of elements this Gatherer gathers
>>       */
>>      public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
>>          if (windowSize < 1)
>>              throw new IllegalArgumentException("'windowSize' must be greater than zero");
>>
>>          class FixedWindowGatherer implements Gatherer<T,ArrayList<T>,List<T>> {
>>              @Override
>>              public Supplier<ArrayList<T>> initializer() {
>>                  return () -> new ArrayList<>(windowSize);
>>              }
>>
>>              @Override
>>              public Integrator<ArrayList<T>, T, List<T>> integrator() {
>>                  return (openWindow, element, downstream) -> {
>>                      if (openWindow.add(element) && openWindow.size() >= windowSize) {
>>                          var closedWindow = List.copyOf(openWindow);
>>                          openWindow.clear();
>>                          return downstream.flush(closedWindow);
>>                      } else
>>                          return true;
>>                  };
>>              }
>>
>>              @Override
>>              public BinaryOperator<ArrayList<T>> combiner() {
>>                  return Gatherer.unsupportedCombiner();
>>              }
>>
>>              @Override
>>              public BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher() {
>>                  return (openWindow, downstream) -> {
>>                      if(!openWindow.isEmpty()) {
>>                          downstream.flush(List.copyOf(openWindow));
>>                          openWindow.clear();
>>                      }
>>                  };
>>              }
>>          }
>>          return new FixedWindowGatherer();
>>      }
>> ```
>>
>> Compared to Collector, it would look like the following:
>>
>> | Ordinal | Feature                  | `Collector<T,A,R>`                | `Gatherer<T,A,R>`                     |
>> |---------|--------------------------|-----------------------------------|---------------------------------------|
>> |    1    | Beginning-of-stream hook | `A supply()`                      | `A supply()`                          |
>> |    2    | Per element              | `void accept(A, T)`               | `boolean integrate(A, T, Sink<R>)`    |
>> |    3    | End-of-stream hook       | `R apply(A)`                      | `void accept(A, Sink<R>)`             |
>> |    4    | Parallelizability        | `A apply(A, A)`                   | `A apply(A, A)`                       |
>>
>> To integrate it with `java.util.stream.Stream` we add the following method to
>> it: `Stream<R> gather(Gatherer<T,?,R> gatherer)`
>>
>> Now we can use our `fixedWindow` Gatherer:
>>
>> ```java
>> jshell> Stream.iterate(0, i -> i + 1).limit(10).gather(fixedWindow(2)).toList();
>> $1 ==> [[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]]
>> ```
>>
>> Gatherer now provides all features:
>>
>> | Ordinal | Feature                  | Using Gatherer          | Explanation                                                                            |
>> |---------|--------------------------|-------------------------|----------------------------------------------------------------------------------------|
>> |    1    | Intermediate operation   | Yes                     | A Gatherer's output is the following operation's input                                 |
>> |    2    | Incremental operation    | Yes                     | A Gatherer can produce elements in response to consuming elements                      |
>> |    3    | Stateful operation       | Yes                     | A Gatherer supplies its own state, which can be Void/null if stateless                 |
>> |    4    | N:M inputs-to-outputs    | Yes                     | A Gatherer can consume and produce any number of elements                              |
>> |    5    | Prefix consumption       | Yes                     | A Gatherer can signal that it is done by returning `false` from its `integrate`-method |
>> |    6    | Beginning-of-stream hook | Yes                     | A Gatherer can run logic when creating its initial state                               |
>> |    7    | End-of-stream hook       | Yes                     | A Gatherer's `finisher` is invoked at the end of input                                 |
>> |    8    | Opt-in parallelizability | Yes                     | A Gatherer's `combiner` is optional                                                    |
>>
>> ## Summary
>>
>> None of the current candidates for a user-extensible API for generic
>> intermediate stream operations fit the set of requirements, but `Collector`
>> can form an excellent basis for a new construct, called `Gatherer`,
>> which after a limited set of modifications checks all the boxes:
>>
>> | Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector | Using Gatherer |
>> |---------|--------------------------|---------------------------|---------------------------|-----------------|----------------|
>> |    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    | Yes            |
>> |    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    | Yes            |
>> |    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             | Yes            |
>> |    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         | Yes            |
>> |    5    | Prefix consumption       | No                        | No                        | No              | Yes            |
>> |    6    | Beginning-of-stream hook | No                        | No                        | Yes             | Yes            |
>> |    7    | End-of-stream hook       | No                        | No                        | Yes             | Yes            |
>> |    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   | Yes            |
>>
>> As it turned out, we were a short hop away from a generic, stand-alone,
>> reusable, parallelizable, API for intermediate operations all along!
>>
>> ## But wait ? there's more
>>
>> While the aforementioned solution contains the bare-minimum to meet our requirements,
>> the following will provide some significant quality-of-life improvements.
>>
>> ### Compositionality
>>
>> The astute reader may have noticed that by adding the `gather(Gatherer)`-method on `Stream`,
>> one can in-effect **compose** `Gatherer`s together:
>>
>> ```java
>> Gatherer<Integer,?,String> someGatherer = ?;
>> Gatherer<String,?,Long> someOtherGatherer = ?;
>> Stream<Long> stream = Stream.of(1).gather(someGatherer).gather(someOtherGatherer);
>> ```
>>
>> As it turns out, it is possible to define a `default Gatherer andThen(Gatherer)`-method on `Gatherer` which composes `Gatherer`s:
>>
>> ```java
>> Gatherer<Integer,?,String> someGatherer = ?;
>> Gatherer<String,?,Long> someOtherGatherer = ?;
>> Gatherer<Integer,?,Long> gatherer = someGatherer.andThen(someOtherGatherer);
>> ```
>>
>> This makes it possible to both de-couple operations from their use-sites,
>> as well as create more sophisticated `Gatherer`s from simple ones.
>>
>> But that's not all?by introducing a `default Collector collect(Collector)`-method
>> it is also possible to compose a `Gatherer` with a `Collector`,
>> and the result is another `Collector`:
>>
>> ```java
>> Gatherer<Integer,?,String> someGatherer = ?;
>> Gatherer<String,?,Long> someOtherGatherer = ?;
>> Collector<Long,?,List<Long>> someGatherer.andThen(someOtherGatherer).collect(Collectors.toList());
>> ```
>>
>> All of this together, it is now possible to build `Stream`-processing:
>> "source-to-destination" using `Stream.gather(?).gather(?).gather(?)`;
>> "intermediaries-first" using `gatherer.andThen(?).andThen(?);` and,
>> "destination-to-source" using `gatherer.collect(otherGatherer.collect(?))`.
>>
>> ### Familiarity
>>
>> Since `Gatherer` is an evolution of `Collector` there's a clear on-ramp
>> for any and all Java developers who are already familiar with `Collector`.
>>
>> ### Reusability
>>
>> `Gatherer`s, by virtue of being stand-alone, reusable, intermediaries,
>> paired with compositionality and opt-in parallelization, allows for transformations
>> to be created once and maintained in a single place, no matter if it is going to be
>> used as a `Collector`, a `Gatherer`, or a `Stream`.
>>
>> ### Optimizability
>>
>> `Collector` has the notion of `Characteristics`, a `Set` of flags which describes them.
>> This information can then be used by the underlying machinery which uses them
>> to optimize their evaluation. The same approach can be used for `Gatherer`s.
>>
>> ### Summary 2.0
>>
>> Taking all of the above into consideration, we end up with a definition like the following:
>>
>> ```java
>> /** @param <T> the element type
>>   *  @param <A> the (mutable) intermediate accumulation type
>>   *  @param <R> the (probably immutable) final accumulation type
>>   */
>> interface Gatherer<T,A,R> {
>>
>>      interface Sink<R> {
>>          boolean flush(R element);
>>      }
>>
>>      interface Integrator<A,T,R> {
>>          boolean integrate(A state, T element, Sink<? super R> downstream);
>>      }
>>
>>      enum Characteristics {
>>          GREEDY,          // Never short-circuits
>>          SIZE_PRESERVING, // Emits exactly once per input element
>>          STATELESS;       // No need to initialize or combine state
>>      }
>>
>>      Supplier<A> supplier();
>>      Integrator<A, T, R> integrator();
>>      BinaryOperator<A> combiner();
>>      BiConsumer<A, Sink<? super R>> finisher();
>>      Set<Characteristics> characteristics();
>>
>>      default <AA, RR> Gatherer<T,?,RR> andThen(Gatherer<R,AA,RR> that) {
>>          // Gatherers is analoguous to Collectors
>>          return Gatherers.Composite.of(this, that);
>>      }
>>
>>      default <RR> Collector<T,?,RR> collect(Collector<R, ?, RR> collector) {
>>          // Gatherers is analoguous to Collectors
>>          return Gatherers.GathererCollector.of(this, collector);
>>      }
>> }
>> ```
>>
>> ## Appetizers
>>
>> The following examples showcase how `Gatherer` can be used to implement a diverse set
>> of pre-existing, and future, intermediate operations for `Stream`s.
>>
>> ### How to implement `map(mapper)`
>>
>> ```java
>> public final static <T,R> Gatherer<T, ?, R> map(Function<? super T, ? extends R> mapper) {
>>      return Gatherer.of(
>>          () -> (Void)null,
>>          (nothing, element, downstream) ->
>>              downstream.flush(mapper.apply(element)),
>>          (l,r) -> l,
>>          (nothing, downstream) -> {}
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(map(i -> i + 1)).toList()
>> $1 ==> [2, 3, 4, 5]
>> ```
>>
>> ### How to implement `flatMap(mapper)`
>>
>> ```java
>> public final static <T,R> Gatherer<T, ?, R> flatMap(Function<? super T, ? extends Stream<R>> mapper) {
>>      return Gatherer.of(
>>          () -> (Void)null,
>>          (nothing, element, downstream) -> {
>>              try(Stream<? extends R> s = mapper.apply(element)) {
>>                  return s == null || s.sequential().allMatch(downstream::flush);
>>              }
>>          },
>>          (l,r) -> l,
>>          (nothing, downstream) -> {}
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(flatMap(i -> Stream.of(i + 1))).toList()
>> $1 ==> [2, 3, 4, 5]
>> ```
>>
>> ### How to implement `takeWhile(predicate)`
>>
>> ```java
>> public final static <T> Gatherer<T, ?, T> takeWhile(Predicate<? super T> predicate) {
>>      return Gatherer.of(
>>          () -> (Void)null,
>>          (nothing, element, downstream) ->
>>              predicate.test(element) && downstream.flush(element),
>>          (l, r) -> l,
>>          (nothing, downstream) -> {}
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(takeWhile(i -> i < 3)).toList()
>> $1 ==> [1, 2]
>> ```
>>
>> ### How to implement `limit(N)`
>>
>> ```java
>> public static <M> Gatherer<M, ?, M> limit(long limit) {
>>      if (limit < 0)
>>          throw new IllegalArgumentException("'limit' has to be non-negative");
>>
>>      class At { long n = 0; }
>>      return Gatherer.of(
>>              At::new,
>>              (at, element, downstream) ->
>>                  at.n < limit && downstream.flush(element) && ++at.n < limit,
>>              Gatherer.unsupportedCombiner(),
>>              (at, downstream) -> {}
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(limit(2)).toList()
>> $1 ==> [1, 2]
>> ```
>>
>> ### How to implement prefix `scanLeft`
>>
>> ```java
>> public static <T,R> Gatherer<T,?,R> scanLeft(R initial, BiFunction<R,T,R> scanner) {
>>      class State { R current = initial; }
>>      return Gatherer.of(
>>              State::new,
>>              (state, element, downstream) ->
>>                  downstream.flush(state.current = scanner.apply(state.current, element)),
>>              Gatherer.unsupportedCombiner(),
>>              (state, downstream) -> {}
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(scanLeft("'", (acc, elem) -> acc + elem + "'")).toList()
>> $1 ==> ['1', '1'2', '1'2'3', '1'2'3'4']
>> ```
>>
>> ### How to implement `fold(initial, folder)`
>>
>> ```java
>> public static <T> Gatherer<T,?,T> fold(T initial, BinaryOperator<T> folder) {
>>      class State { T current = initial; }
>>      return Gatherer.of(
>>          State::new,
>>          (state, element, downstream) -> {
>>              state.current = folder.apply(state.current, element);
>>              return true;
>>          },
>>          (l, r) -> {
>>              l.current = folder.apply(l.current, r.current);
>>              return l;
>>          },
>>          (state, downstream) -> downstream.flush(state.current)
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(fold(0, (acc, elem) -> acc + elem)).toList()
>> $1 ==> [10]
>> ```
>>
>> ### How to implement `foldLeft(initial, folder)`
>>
>> ```java
>> public static <T,R> Gatherer<T,?,R> foldLeft(R initial, BiFunction<R,T,R> folder) {
>>      class State { R current = initial; }
>>      return Gatherer.of(
>>          State::new,
>>          (state, element, downstream) -> {
>>              state.current = folder.apply(state.current, element);
>>              return true;
>>          },
>>          Gatherer.unsupportedCombiner(),
>>          (state, downstream) -> downstream.flush(state.current)
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,3,4).gather(foldLeft(0L, (acc, elem) -> acc + elem)).toList()
>> $1 ==> [10]
>> ```
>>
>> ### How to implement `deduplicateAdjacent()`
>>
>> ```java
>> public static <T> Gatherer<T,?,T> deduplicateAdjacent() {
>>      class State { T prev; boolean hasPrev; }
>>      return Gatherer.of(
>>          State::new,
>>          (state, element, downstream) -> {
>>              if (!state.hasPrev) {
>>                  state.hasPrev = true;
>>                  state.prev = element;
>>                  return downstream.flush(element);
>>              } else if (!Objects.equals(state.prev, element)) {
>>                  state.prev = element;
>>                  return downstream.flush(element);
>>              } else {
>>                  return true; // skip duplicate
>>              }
>>          },
>>          Gatherer.unsupportedCombiner(),
>>          (state, downstream) -> {}
>>      );
>> }
>> ```
>>
>> ```java
>> jshell> Stream.of(1,2,2,3,2,4).gather(deduplicateAdjacent()).toList()
>> $1 ==> [1, 2, 3, 2, 4]
>> ```
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230628/2be28e4f/attachment-0001.htm>

From jlu at openjdk.org  Wed Jun 28 20:49:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 Jun 2023 20:49:18 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v4]
In-Reply-To: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
Message-ID: <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>

> Please review this PR which refactors Currency tests to use JUnit.
> 
> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
> 
> - Tests are no longer dependent on each other (order of execution does not matter)
> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
> 
> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove unusued JUnit imports from ValidateISO4217.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/3975c57f..10d54167

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

PR: https://git.openjdk.org/jdk/pull/14682

From duke at openjdk.org  Wed Jun 28 22:19:04 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Wed, 28 Jun 2023 22:19:04 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v2]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>

> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
> 
> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
> 
> # Benchmark Result
> 
> 
> make test TEST="micro:java.lang.Integers.toString*"
> 
> 
> ## [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  5.164 ? 0.052  us/op +31.89%
> +Integers.toStringSmall     500  avgt   15  3.844 ? 0.025  us/op +24.71%
> +Integers.toStringTiny      500  avgt   15  3.453 ? 0.027  us/op +8.65%
> 
> 
> ### [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  5.063 ? 0.175  us/op +33.55%
> +Integers.toStringSmall     500  avgt   15  3.498 ? 0.123  us/op +28.10%
> +Integers.toStringTiny      500  avgt   15  2.743 ? 0.147  us/op +0.65%
> 
> 
> ## [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR)
> +Integers.toStringBig       500  avgt   15  8.157 ? 0.274  us/op +48.10%
> +Integers.toStringSmall     500  avgt   15  7.207 ? 0.330  us/op -1.22%
> +Integers.toStringTiny      500  avgt   15  6.912 ? 0.199  us/op -8.52%

??? has updated the pull request incrementally with one additional commit since the last revision:

  postpone the division

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/8bdda26b..3355d211

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=00-01

  Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From mchung at openjdk.org  Wed Jun 28 23:11:04 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 28 Jun 2023 23:11:04 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v17]
In-Reply-To: <mIWoss4xsPeCQ9Ix5hwCwKPJGjhPKa9ITkOOZSmaG70=.5f6507ab-2bcb-4748-841c-b766d90269f7@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <mIWoss4xsPeCQ9Ix5hwCwKPJGjhPKa9ITkOOZSmaG70=.5f6507ab-2bcb-4748-841c-b766d90269f7@github.com>
Message-ID: <3-tr-IKWOKexhKSYUBnUsnQf_YhYclnmK29xHEDQXrM=.81e7c8c2-90fe-456d-aee6-f2c355f8b9a9@github.com>

On Wed, 28 Jun 2023 01:34:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
>> 
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
>> 
>> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
>> 
>> 
>> Benchmark                                            Mode  Cnt    Score    Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update from mandy
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

Looks good in general.  Some minor comments.

I suggest to create a CSR to document the behavioral change to match the specification.

src/java.base/share/classes/java/lang/invoke/LazyInitializingVarHandle.java line 129:

> 127: 
> 128:         try {
> 129:             return MH_ensureInitialized = IMPL_LOOKUP.findVirtual(LazyInitializingVarHandle.class,

Suggestion:

            return MH_ensureInitialized = MethodHandles.lookup().findVirtual(LazyInitializingVarHandle.class,


No need to use the superpower lookup.

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2086:

> 2084:      * be linked directly. If a VarHandle is indirect, it must override
> 2085:      * {@link #isAccessModeSupported} and {@link #getMethodHandleUncached}
> 2086:      * which access MemberNames..

Suggestion:

     * which access MemberNames.

test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 30:

> 28:  *          initialization mechanism..
> 29:  * @run junit LazyInitializingTest
> 30:  * @run junit/othervm -Djava.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT=true LazyInitializingTest

I wonder if this new test should run with all combination of 
`java.lang.invoke.VarHandle.VAR_HANDLE_GUARDS` and `java.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT` as done in other `VarHandleTestXXX`.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13821#pullrequestreview-1504321038
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245899498
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245901726
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245905901

From duke at openjdk.org  Thu Jun 29 00:10:57 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 00:10:57 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v2]
In-Reply-To: <Z5DShRGcrKeM3DX36f_bN7wb8Kc-XIyHZBsnObhki6s=.a78675e9-0d97-4c33-a849-22ba2cb3e5d4@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Z5DShRGcrKeM3DX36f_bN7wb8Kc-XIyHZBsnObhki6s=.a78675e9-0d97-4c33-a849-22ba2cb3e5d4@github.com>
Message-ID: <DMsjfmKqxkJQn1Y3mArEY-OcqrWiC2fBOZCyLtPI8Ww=.2676b59a-a7c9-4483-b35c-75e546078834@github.com>

On Wed, 28 Jun 2023 17:53:04 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   postpone the division
>
> src/java.base/share/classes/java/lang/Integer.java line 478:
> 
>> 476: 
>> 477:         byte[] buf;
>> 478:         if (q1 == 0) {
> 
> You could postpone the division to compute `q1` later, and here test whether `i < 1_000`.
> I've no statistics, but I guess it makes sense to optimize for tiny `int`s by avoiding a division.

I have submitted the changes and updated the benchmark results, which shows an improvement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1245940981

From liach at openjdk.org  Thu Jun 29 00:43:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 00:43:59 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v9]
In-Reply-To: <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>
Message-ID: <Z0fKm3OV-M7aDjltGgll3apaCFlQUernOpEFdUDeWQY=.30787a08-ee60-4edb-b062-bc8b700e76b4@github.com>

On Tue, 27 Jun 2023 20:29:36 GMT, Glavo <duke at openjdk.org> wrote:

>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
>> 
>> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
>> 
>> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add 8310843 to @bug

@minborg Sorry for pinging, but I think this might be of your interest since you've introduced the ByteArray classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612278100

From liach at openjdk.org  Thu Jun 29 00:51:14 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 00:51:14 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v18]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <En1lbq7LLBRm1zevnzyO9BG2v6cAb8nEHZB5uc0YCrI=.b012b0d1-6a6f-4416-94fc-72e78811dd82@github.com>

> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
> 
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
> 
> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
> 
> 
> Benchmark                                            Mode  Cnt    Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Mandy suggestions
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/3c5d380b..b079fee5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=16-17

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From joe.darcy at oracle.com  Thu Jun 29 01:31:04 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 28 Jun 2023 18:31:04 -0700
Subject: List extending Collection/SequencedCollection
In-Reply-To: <CA+DiXd7WgO2fuNJ=OAwUVutjBhk_1uN38uZ77=6-hNW6jCgyTg@mail.gmail.com>
References: <CA+DiXd7WgO2fuNJ=OAwUVutjBhk_1uN38uZ77=6-hNW6jCgyTg@mail.gmail.com>
Message-ID: <591c1b08-a05c-5347-5965-c750aec10aa2@oracle.com>

Hello,

What is Painless doing that would fail under

 ??? List extends SequencedCollection ...

but work under

 ??? List extends SequencedCollection, Collection ...

The two definition are semantically equivalent since SequencedCollection 
itself extends Collection.

The JDK 22 javadoc for List shows:

> All Superinterfaces:
> ??? Collection<E>, Iterable<E>, SequencedCollection<E> 

There are certainly implementation artifacts concerning the details of 
how a type was declared that exposed via core reflection (for the 
javax.lang.model API during annotation processing at compile time), but 
it is a bug for third party programs to rely on such details.

HTH,

-Joe

On 6/27/2023 7:37 AM, Ryan Ernst wrote:
> Hi core-libs-dev,
>
> I know various threads have existed over the past few months on
> SequencedCollection and its implications on compatibility. I wanted to
> raise this semi-related issue we noticed recently after beginning
> testing against Java 21.
>
> Elasticsearch began testing against Java 21, and noticed a series of
> failures in Painless (our builtin scripting language, which
> dynamically compiles to bytecode). Most tests that used List failed to
> compile, with several unknown methods (eg add). Painless builds a
> hierarchy of classes it knows about for method resolution. This
> hierarchy didn't know anything about SequencedCollection since we
> currently compile against Java 17. Now, this was ultimately a bug in
> Painless, because we knew there could be cases where we encounter
> unknown classes in the hierarchy (eg a class which is not blessed to
> be visible in the language). However, I think the reason we found that
> bug (List extending from SequencedCollection) might still cause issues
> for some.
>
> While debugging the issue, something that struck me as interesting in
> the SequencedCollection hierarchy is the difference between List and
> SortedSet. Both of these classes were made to be compatible with
> sequenced classes by adding the new classes as super interfaces,
> SequencedCollection and SequencedSet, respectively. However, while
> SortedSet was *added* as a super interface, List had its super
> interface Collection *replaced* by SequencedCollection.
>
> I don't know enough about the rampdown process to know if this is
> still fixable in Java 21. It is probably an extreme edge case that
> doesn't matter, since eg instanceof Collection will still work in
> existing code. But for consistency, it would seem better to maintain
> Collection as a direct super interface of List. Is there any reason
> such a change doesn't fit with the collections architecture going
> forward?

From duke at openjdk.org  Thu Jun 29 01:37:03 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 29 Jun 2023 01:37:03 GMT
Subject: Integrated: 8301569: jmod list option and jimage list --help not
 interpreted correctly on turkish locale
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <iYSVNnf2EibFFuZCHy2sCfsc3PntcIQ7mhY6s1tLM9I=.ba58a165-22aa-4939-bb5b-6e482497b7a8@github.com>

On Sun, 29 Jan 2023 15:37:28 GMT, Glavo <duke at openjdk.org> wrote:

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

This pull request has now been integrated.

Changeset: 6f58ab2b
Author:    Glavo <zjx001202 at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f58ab2bb9e0f02752628daa70e332cd2248e446
Stats:     8 lines in 4 files changed: 1 ins; 0 del; 7 mod

8301569: jmod list option and jimage list --help not interpreted correctly on turkish locale

Reviewed-by: mchung, naoto, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/12281

From liach at openjdk.org  Thu Jun 29 01:47:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 01:47:53 GMT
Subject: RFR: JDK-8310814: Clarify the targetName parameter of
 Lookup::findClass [v2]
In-Reply-To: <G4xMfIr9T7jCfDqWXjsQfD6Bo6fPuBE-pHpx9KKnh94=.323c6e31-1f7e-4a14-ae92-17c412aeeae2@github.com>
References: <4vRzMGX2j9h8rKnHa0tPrU8CKgJxD8gkETl56W5mW28=.91aae64d-1041-4e1c-99bd-97d7574be3b1@github.com>
 <G4xMfIr9T7jCfDqWXjsQfD6Bo6fPuBE-pHpx9KKnh94=.323c6e31-1f7e-4a14-ae92-17c412aeeae2@github.com>
Message-ID: <kOtm1e_xBlqq8Yd-xe8nXPx7phIjVhBzMpssiia9mwE=.d2684acc-9fe7-4f11-aa52-defbc09bc71c@github.com>

On Mon, 26 Jun 2023 23:13:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR updates the spec of `Lookup::findClass` to reflect the current behavior that requires a binary name or a string representing an array class in the form as returned by `Class::getName`.    
>> 
>> `test/jdk/java/lang/invoke/accessClassAndFindClass/TestFindClass.java` already covers the test cases of a nested class and an array class.
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8310833: Clarify the targetName parameter of Lookup::findClass

A nice correction and followup of `Class::forName` spec update.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/14668#pullrequestreview-1504443389

From liach at openjdk.org  Thu Jun 29 01:55:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 01:55:30 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v19]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <jm_AJ5zALuQSbilifFRNapuZczcMuCy0g9lPwzsBgws=.1d43a13c-9354-4afd-a444-5c759e2db804@github.com>

> This patch implements lazy initialization for VarHandle working on static fields. It has a good initial call performance.
> 
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH implementation methods. If called via MethodHandle, a barrier is added in the MethodHandle instead.
> 
> The new test ensures the correctness of Lazy VH for both direct and indirect invocation; the performance of MethodHandle version of lazy VH is not yet tested.
> 
> 
> Benchmark                                            Mode  Cnt    Score    Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   41.490 ? 12.331  us/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   21.810 ? 16.964  us/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   57.860 ? 13.738  us/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10   93.300 ? 18.858  us/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   39.860 ?  9.362  us/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   17.630 ?  1.111  us/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10  123.170 ? 62.468  us/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  105.390 ? 41.815  us/op

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Run Lazy test with all flags, Classfile and comment update to ColdStart, other minor cleanup
 - Merge branch 'master' into lazy-static-varhandle
 - Mandy suggestions
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Comment update from mandy
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Add lazy init test for toMethodHandle
 - Apply suggestions from code review
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Rollback VHG changes
 - Split the concepts of asDirect and target
 - Fix bugs
 - Merge branch 'master' into lazy-static-varhandle
 - ... and 23 more: https://git.openjdk.org/jdk/compare/ded13707...6e54b61d

-------------

Changes: https://git.openjdk.org/jdk/pull/13821/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=18
  Stats: 796 lines in 10 files changed: 636 ins; 52 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From liach at openjdk.org  Thu Jun 29 01:55:30 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 01:55:30 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v17]
In-Reply-To: <3-tr-IKWOKexhKSYUBnUsnQf_YhYclnmK29xHEDQXrM=.81e7c8c2-90fe-456d-aee6-f2c355f8b9a9@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <mIWoss4xsPeCQ9Ix5hwCwKPJGjhPKa9ITkOOZSmaG70=.5f6507ab-2bcb-4748-841c-b766d90269f7@github.com>
 <3-tr-IKWOKexhKSYUBnUsnQf_YhYclnmK29xHEDQXrM=.81e7c8c2-90fe-456d-aee6-f2c355f8b9a9@github.com>
Message-ID: <mUUt7-Hvdey-cq2VKbmBA8yRdoLaxluv88E8yxTivec=.60a41cef-4451-4a64-8c96-9e805a07f055@github.com>

On Wed, 28 Jun 2023 23:08:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I suggest to create a CSR to document the behavioral change to match the specification.

CSR filed for this behavior change; no spec updates but there's minor class-loading compatibility risk. I would be grateful if you can review the CSR.

> test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 30:
> 
>> 28:  *          initialization mechanism..
>> 29:  * @run junit LazyInitializingTest
>> 30:  * @run junit/othervm -Djava.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT=true LazyInitializingTest
> 
> I wonder if this new test should run with all combination of 
> `java.lang.invoke.VarHandle.VAR_HANDLE_GUARDS` and `java.lang.invoke.VarHandle.VAR_HANDLE_IDENTITY_ADAPT` as done in other `VarHandleTestXXX`.

Done, now the test runs with all 4 combinations and passes on my end.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1612317158
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245997356

From liach at openjdk.org  Thu Jun 29 01:55:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 01:55:31 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v14]
In-Reply-To: <vM2YMASWZ3FaUCyCpSuT9D6zdhxDjpxCLMnLuJJvMtg=.db8cf9d1-2f3e-498b-8771-13de93c44741@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <sLik6-3mZnNMj1MKdSh5QCLjPwjywvVm1cBQBflJPEw=.a5b063c0-e7b1-43aa-9782-297acee68079@github.com>
 <xCobDFKSM1IoAM3-wnwLgbfFPsYlz1vRDYHq5aMgc5I=.92409cd7-0022-4cda-aad4-f88695697800@github.com>
 <7H3mVsDodgtPoGm7iCaSvhXtfQHj08OsVaCnv3dKAHM=.659f2440-5fcc-4873-84e9-0937369157ec@github.com>
 <vM2YMASWZ3FaUCyCpSuT9D6zdhxDjpxCLMnLuJJvMtg=.db8cf9d1-2f3e-498b-8771-13de93c44741@github.com>
Message-ID: <dqXG5P8haS53dZGsik414eikagweqyAm_Y3znh1Fwgs=.a22c4d52-c167-4c08-8b40-762aa61eb3f3@github.com>

On Wed, 28 Jun 2023 19:15:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I use this block to remove the overhead around MethodHandle and VarHandle infrastructure initialization (such as LF spinning) that is not related to any particular class; so that I measure only the impact of encountering a new class.
>
> Ah, implied by "... and initializes the lazy/non-lazy handles to prevent further creation costs" Could you also add a small comment above this block?

Done. Also commented on each line about what each call initializes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1245997747

From liach at openjdk.org  Thu Jun 29 03:16:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 03:16:15 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v19]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <ZbsMg67GdEn7H-M9MumzGijPaD9htHOiNG31prqSNLI=.79eb7851-f7b7-482c-a5fa-b81440be4210@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's faster than old implementation in general.
> 
> Benchmark for revision 17:
> 
> Benchmark                                                          Mode  Cnt      Score       Error  Units
> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallL...

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Code cleanup, thanks mandy!
 - Merge branch 'master' of https://github.com/openjdk/jdk into explore/mhp-iface
 - 1. Change WRAPPER_TYPES to WeakHashMap to accurately determine if the given class is
      the proxy class
   
   Discussion:
   2. I dropped ProxyClassInfo and use Lookup just to see the simplication.
      If wrapperInstanceTarget and wrapperInstanceType are frequently called, it makes
      sense to cache the method handles.
   
   3. Should it use SoftReference or WeakReference?  It depends if asInterfaceInstance
      will be used heavily.
   
   3. I also dropped SamInfo and getStats as it can be inlined in the caller, which
      I think it's clearer to see what it does in place.
 - SecurityManager fixed, minimize changes
 - Merge branch 'master' into explore/mhp-iface
 - Some changes per Mandy's review. SecurityManager test fails in this patch
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - Merge branch 'master' into explore/mhp-iface
 - stage, needs to fix is mh proxy instance check
 - ... and 31 more: https://git.openjdk.org/jdk/compare/6f58ab2b...340b0751

-------------

Changes: https://git.openjdk.org/jdk/pull/13197/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=18
  Stats: 1274 lines in 15 files changed: 1022 ins; 163 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

PR: https://git.openjdk.org/jdk/pull/13197

From liach at openjdk.org  Thu Jun 29 03:16:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 03:16:16 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v18]
In-Reply-To: <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <Fh1UNUxEUPYOoDpoyRsJJg5oCkiCjFoksTQaMJqnr8Y=.2564e3f9-9320-4eb4-b66d-2a3b3397f46d@github.com>
Message-ID: <q56-XkgpNH2DGJr19kzyvxMTpI4wlthg3fw730FpEVU=.4959459c-2199-40dd-8d2b-9a0b068cef7c@github.com>

On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:
> 
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - Merge branch 'master' into explore/mhp-iface
>  - Remove assertion, no longer true with teleport definition in MHP
>  - Fix tabs, and tests about modules and constructor access
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/05e9c41e...07cc1279

Thank you mandy. Your patch works out of the box. I added some minor cleanup (such as using newSetFromMap for clarity) and adjusted the ProxyModuleMapping test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1612363839

From liach at openjdk.org  Thu Jun 29 05:47:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 05:47:03 GMT
Subject: Integrated: 8311020: Typo cleanup in Classfile API
In-Reply-To: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
References: <1vsUQVlbWvzZL0VKmNUjJEbGLLRo5nOxtoWXkMvMXTk=.4fdbc8df-3a87-48e7-bcbb-083271164318@github.com>
Message-ID: <h4bNrKzCTyenKtVJh-Sl2RSdQUS62sfH-nUJeteQl-Y=.7fc84e14-6c89-4637-81fd-84df8c4d2d9c@github.com>

On Wed, 28 Jun 2023 06:09:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> This is a cleanup patch that fixes:
> 1. `ClassfileBuilder` should be sealed but was not; it's now sealed.
> 2. Various typo fixes, including spelling errors, wrong descriptions, and unnecessary full qualifications for classes in the same package.
> 
> Requesting a review from @asotona. There's a few other more complex issues discovered, which I will describe on the mailing list to elicit a discussion for best solutions.

This pull request has now been integrated.

Changeset: cbf418a4
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbf418a4863f92241f116f782f9a676b7cb4771d
Stats:     56 lines in 30 files changed: 3 ins; 3 del; 50 mod

8311020: Typo cleanup in Classfile API

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/14687

From duke at openjdk.org  Thu Jun 29 06:17:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 06:17:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <5G9wEB5x53xB5H2LGyyONLkfVxVA1MPfsoSJx_29t4A=.d102b2b4-aef4-4284-8050-d819c23352b8@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5G9wEB5x53xB5H2LGyyONLkfVxVA1MPfsoSJx_29t4A=.d102b2b4-aef4-4284-8050-d819c23352b8@github.com>
Message-ID: <yt096OnyDka-vE6d12Ad0C_3CIWHkzRLVz3usw4geZg=.78a91cd4-6143-489d-b3d4-0c398bdf9135@github.com>

On Tue, 27 Jun 2023 14:10:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and make private constructor.
>
> src/java.base/share/classes/jdk/internal/util/Hex256.java line 38:
> 
>> 36: 
>> 37:     @Stable
>> 38:     public static final short[] DIGITS;
> 
> If UUID shows up in startup class loading this array would be a candidate for loading by CDS, as mentioned in earlier review comments. Please create a separate issue to evaluate and add the code to load the array using CDS.

now it's reuse the field of HexDigits.DIGITS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1246155736

From duke at openjdk.org  Thu Jun 29 06:17:12 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 06:17:12 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]
In-Reply-To: <9TP7iwF3auFo6ejyysEJmbflMTtKH83QudQppaRB-BE=.fea5cdc9-0770-45be-959b-4749c279517e@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <bL0gV9sssVolguYy2bTe6c3-XPRL1_gQShmYUZDnru8=.6eb15014-30fb-49ea-8b1d-9be8411415f2@github.com>
 <5Dcx9V1INGDFUSjUrMNWkkCwxOEXUD6bOVfRpyQg2XU=.d94c2ef4-7cc3-4c05-b78c-a73e41ee4df2@github.com>
 <dbB7wtYHPK8H1s-2obVXr2S8_H_TvFLGA-CZF4t3cDk=.a78048ea-138c-4f63-a86b-009b92b8f3fb@github.com>
 <rkcnhDsXyjqvkgETTV7qNXX0Hqdj0RdQIcY2r_izabU=.c6a29601-0679-4f7a-9487-900064c1bc0d@github.com>
 <ES39yOI-ivq2AtL12D4ikvxwFxPXNXo9-3g5CCnuS4E=.57574c15-74de-4af5-be36-4fd67ab83e79@github.com>
 <X1HGlSBYDgX0dN1e30XS7-C7SawfsFpxCotWtwh5S8k=.7dc15c53-e7c8-4b04-8c8c-42fc7ff5aaa4@github.com>
 <cV9ZPBqlIFTUH1LfMrrLVW9s2qUC3p75RxhFcZT6fEo=.eac94ec0-0011-40d4-b09c-ac8dad0a4209@github.com>
 <oUCm849mz0deVEuwgBNlgB-EVM5cxQVXb0huuRMjylk=.4e9717b4-65ce-40ed-8234-8ae5cb8e8928@github.com>
 <_DfZ5tA9FKaNC2eW0hZCZZ-Tb_Mn8AQOLy69wXpLwUI=.dbcdfde1-263d-4cdb-83fe-5cec7fdcc2e1@github.com>
 <3pplgfhEpBo6LiXTwlFRbDS2oSb1ELbz9t7
 F-WsTJ28=.b3cf3a50-bc95-489f-aded-e0fcea41b279@github.com>
 <9TP7iwF3auFo6ejyysEJmbflMTtKH83QudQppaRB-BE=.fea5cdc9-0770-45be-959b-4749c279517e@github.com>
Message-ID: <s_G3J1iFOG9XigiJq9aOyEPkB5WI9zvk7_WnVhtdTUU=.6e5733c3-6d6c-43c5-b82d-91dac7c65b70@github.com>

On Tue, 27 Jun 2023 16:12:50 GMT, ??? <duke at openjdk.org> wrote:

>>> Sadly, jdk.internal.util is exported to other modules so it does need to be looked at from an integrity perspective.
>> 
>> This is indeed a problem to consider.
>> 
>> Maybe we can move this array back into `HexDigits`. Then we create a new package `jdk.internal.digits` and move `Digits`, `DecimalDigits`, `HexDigits`, `OctalDigits` all into it.
>
> Hex256 has been moved to jdk.internal.digits, jdk.internal.digits is not exported.

now it's reuse the field of java.util.HexDigits#DIGITS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1246156442

From erikj at openjdk.org  Thu Jun 29 07:23:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 07:23:54 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <nuJPc-yjOE7DrniF-EEjhLk-HQOBXJs4Ju4rWV4xxpw=.29e0f50a-084f-4091-8d96-ef05ab41427b@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261

From dholmes at openjdk.org  Thu Jun 29 07:43:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 07:43:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

It also seems far too large and disruptive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676

From alanb at openjdk.org  Thu Jun 29 07:44:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 07:44:56 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v6]
In-Reply-To: <Qi92DOk4kYykz5F2zFEiYAaq1N-xPztobdmsSa3PgMQ=.b8879da8-be21-4839-acd3-f6b1fe5dc410@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <pOvLWlwkhuJBmWjY3aG9T_vUK3IMuqLh3vxpYhdXXek=.8ad03f6c-4b4a-4d01-81e8-8ff0a937d07a@github.com>
 <Qi92DOk4kYykz5F2zFEiYAaq1N-xPztobdmsSa3PgMQ=.b8879da8-be21-4839-acd3-f6b1fe5dc410@github.com>
Message-ID: <e7vdNMZIuP1GMLeY-99cOLu9C8Jkd2g4xHA53a9-Oac=.84b82f50-5540-4f8b-b820-73b6ed87b712@github.com>

On Mon, 26 Jun 2023 07:09:11 GMT, Glavo <duke at openjdk.org> wrote:

> I deleted some incorrect comments.
> 
> The original author of these two classes misunderstood the behavior of `intBitsToFloat` and `longBitsToDouble`. These two methods never collapse NaN values to a "canonical" NaN value, so the comments is incorrect.

You'll need to go back through the discussion in the original PRs (there was more than one) as there was lengthy discussion this already.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612568000

From alanb at openjdk.org  Thu Jun 29 07:44:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 07:44:57 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v9]
In-Reply-To: <AvHTTEZ5U-D0TdohICA1ZRQkAzp10ODGtY0aXvL1jxI=.7ef08cc7-cf01-4b56-834b-f76100dbf0ed@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>
 <AvHTTEZ5U-D0TdohICA1ZRQkAzp10ODGtY0aXvL1jxI=.7ef08cc7-cf01-4b56-834b-f76100dbf0ed@github.com>
Message-ID: <mA0mnG4g-CryCx252XXc2SE-ZKke_t9wLL2vOiPN8ds=.7d78db29-c398-4ce7-9584-bf311343d442@github.com>

On Wed, 28 Jun 2023 19:32:44 GMT, Glavo <duke at openjdk.org> wrote:

> Can someone review this PR?

What issue are you running into at startup that require this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612568927

From alanb at openjdk.org  Thu Jun 29 07:55:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 07:55:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v30]
In-Reply-To: <Iid5cCoa8j0VeEGbKsDIpoqnzYtCPD4-5ur5fWXsaMA=.e5af8cce-ce61-4e40-8c43-fbdeb5809ff0@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <Iid5cCoa8j0VeEGbKsDIpoqnzYtCPD4-5ur5fWXsaMA=.e5af8cce-ce61-4e40-8c43-fbdeb5809ff0@github.com>
Message-ID: <UZl7Gj7vJeTarQyPplzWYo11LwMljh1LVnQhMToFq2Y=.157d485c-c504-4e9b-859d-a6b63dc7a40a@github.com>

On Tue, 27 Jun 2023 17:44:23 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused import, and fix comment

I've read through 26f3a6a5 (iteration 29) and it mostly looks okay.

It's good to see the UUID code removed from Long.

It's unfortunate that UUID is directly accessing HexDigits.DIGITS but at least its in the same package and the array is accessed more widely. If there were frozen arrays then this would be better. Have you measured using an accessor method to access the array elements rather than accessing the array directly?

Somewhat subjective but I find the new comment in Digits a bit confusing, particularly "In the byte[] encoded in LATIN1" as a byte[] is just bytes and I think you want to say a String encoding as LATIN1 in a byte[]. Maybe drop this and the reference to jdk.internal.util.ByteArray.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1612579949

From liach at openjdk.org  Thu Jun 29 07:59:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 07:59:55 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v9]
In-Reply-To: <mA0mnG4g-CryCx252XXc2SE-ZKke_t9wLL2vOiPN8ds=.7d78db29-c398-4ce7-9584-bf311343d442@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <dnj3gSaxA7S6U9SWI2EXis03Z3XSsfUGBW5XewJvlpM=.dbfd5808-e180-44c6-a0f7-9eb91ece66e1@github.com>
 <AvHTTEZ5U-D0TdohICA1ZRQkAzp10ODGtY0aXvL1jxI=.7ef08cc7-cf01-4b56-834b-f76100dbf0ed@github.com>
 <mA0mnG4g-CryCx252XXc2SE-ZKke_t9wLL2vOiPN8ds=.7d78db29-c398-4ce7-9584-bf311343d442@github.com>
Message-ID: <MbjALDcfg4t3sTQjg_gAwft5N6GodL-jpvf-JKmYP0I=.c407346c-7ce2-4978-bfbc-3daafd9fe4ab@github.com>

On Thu, 29 Jun 2023 07:42:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What issue are you running into at startup that require this change?

I wish to use this too before java.lang.invoke is ready, such as reading unaligned in the Classfile API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612586631

From erikj at openjdk.org  Thu Jun 29 08:00:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 08:00:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <Jo4ev4ByTzxMNpDvKGyYL9G8TzbpVerc1YXde4iu_5Q=.afe5e6d2-63a5-4956-9d5c-17675789a051@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

The patch is leaving exactly one newline at the end of the file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091

From duke at openjdk.org  Thu Jun 29 08:02:56 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 29 Jun 2023 08:02:56 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v6]
In-Reply-To: <e7vdNMZIuP1GMLeY-99cOLu9C8Jkd2g4xHA53a9-Oac=.84b82f50-5540-4f8b-b820-73b6ed87b712@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <pOvLWlwkhuJBmWjY3aG9T_vUK3IMuqLh3vxpYhdXXek=.8ad03f6c-4b4a-4d01-81e8-8ff0a937d07a@github.com>
 <Qi92DOk4kYykz5F2zFEiYAaq1N-xPztobdmsSa3PgMQ=.b8879da8-be21-4839-acd3-f6b1fe5dc410@github.com>
 <e7vdNMZIuP1GMLeY-99cOLu9C8Jkd2g4xHA53a9-Oac=.84b82f50-5540-4f8b-b820-73b6ed87b712@github.com>
Message-ID: <RWfoFJNDqlM40s-PoWBYZqU6DQlOiDt-L8OERLXwGEQ=.7d67c4f1-099d-477f-b094-ec40a587fecd@github.com>

On Thu, 29 Jun 2023 07:41:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> You'll need to go back through the discussion in the original PRs (there was more than one) as there was lengthy discussion this already.

https://github.com/openjdk/jdk/pull/11840#discussion_r1064489163

Are you referring to this discussion?

I understand the original reason for retaining it before, but this discussion is outdated for this PR.

`Unsafe` does not provide `getFloatUnaligned`/`getDoubleUnaligned` and `putFloatUnaligned`/`putDoubleUnaligned`, so we must convert floating point numbers to integers here. This problem is no longer hidden behind `VarHanle`, so we have to face it.

In addition, these comments are indeed wrong and may mislead users. I saw this mentioned in the previous discussion, but I don't know why the document was not cleaned up. I think it's time to clean it up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612589459

From forax at univ-mlv.fr  Thu Jun 29 08:03:46 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 29 Jun 2023 10:03:46 +0200 (CEST)
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1265852641.92738200.1688025826687.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, June 27, 2023 7:10:42 PM
> Subject: java.util.stream.Stream: API for user-extensible intermediate
> operations

> Hi core-libs-dev,

> Over the past 6+ months I've been thinking about, and tinkering with, how we'd
> be able to expose a user-facing API for extensible intermediate
> java.util.stream.Stream operations?a feature envisioned all the way back when
> Streams were created.

> I'm now at a point where I have a viable design and implementation, and so I'm
> turning to you for your feedback: on the direction taken; the API concepts;
> and, in particular, is there anything which I have overlooked/missed?

I think this API is overly generic and hard to reason about it, for users and IDEs. 

The main issue is that the same API is used for both stateless and stateful operations, which means that as a user, we have no idea if a call to stream.gather() is stateful or not. Which is a departure from the current API that cleanly separate stateless and staful operations. Here, we are left in the dark. In a sense, this API is too powerful, it can do too much thing, so as a user we can not reason about it. 

I like the idea of a Collector 2.0 i.e. using the Gatherer API at the end of the stream (not in the middle), but currently, the Gatherer API is not a Collector, so we now have two different APIs for doing partially the same job. I wonder if the Collector API can be retroffitted to act as a Gatherer API, avoiding to have to choose which one to use, a gatherer being the equivalent of a "flat-collector" + short-circuit. 

The idea of unsupportedCombiner() seems out of place, like a patch to be able to clobble different things together. I'm not sure to understand why it's needed for a Gatherer, and why it is not needed for Collectors ? 

So I would prefer that API to extends the current Collector API but not the intermediary operations. Yes, it's less powerful. 
It means that instead of using one stream with a collect like operation in the middle, users will have to use two streams, one after the other, but it makes the code easier to understand (also having two streams give users better control on which part should be in parallel). 

R?mi 

> (If you, like myself, prefer reading pre-rendered markdown, [
> https://cr.openjdk.org/~vklang/Gatherers.html |  click here ] )

> # Gathering the streams

> ## Introduction

> Java 8 introduced the `java.util.stream` API, which represents a lazily
> computed, potentially unbounded sequence of values (Streams was also the first
> designed-for-lambdas API in the JDK). Streams supports the ability to process
> the stream either sequentially or in parallel.

> A `Stream` pipeline consists of a source (collection, array, generator, etc),
> zero or more intermediate operations (`Stream` -> `Stream` transforms), and an
> eager terminal operation which produces a value or a side-effect.

> The Streams API come with a reasonably rich, but fixed set of built-in
> operations (mapping, filtering, reduction, sorting, etc), as well as an
> extensible terminal operation (`Stream::collect`) that enables the stream
> contents to be flexibly summarized in a variety of forms. The resulting API is
> rich enough that users have had good experience with streams, but there are
> repeated requests for "please add operation X to streams".

> In this document, we explore a corresponding extensible _intermediate_
> operation, called `Stream::gather`, which is able to address many of the
> requests we've gotten for additional operations.

> ## "Missing" intermediate operations

> Over the years, many new operations for streams have been proposed. Each of
> them may be useful in some situation, but many of them are too narrow to be
> included in the core `Stream` API. We'd like for people to be able to plug
> these operations in via an extension point, as with `Stream::collect`.

> Here are some examples of proposed intermediate operations that are not easily
> expressible as intermediate operations on `Stream` today.

> * **Folds**. Folding is a generalization of reduction. With reduction, the
> result type is the same as the element type, the combiner is associative, and
> the initial value is an identity for the combiner. For a fold, these
> conditions are not required, though we give up parallelizability.

> Example: `foldLeft("", (str,elem) -> str + " " + elem.toString())` over the
> values
> `[1,2,3]` yields `["1 2 3"]`.

> See https://bugs.openjdk.org/browse/JDK-8133680 &
> https://bugs.openjdk.org/browse/JDK-8292845

> * **Unfolds**. This takes an aggregate and decomposes it into elements. An
> `unfold` can reverse the operation of the above fold example using `Scanner`
> or `String::split`.

> Example: `unfold(e -> new Scanner(e), Scanner::hasNextInt, Scanner::nextInt)`
> `["1 2 3"]` yields `[1,2,3]`.

> See: https://bugs.openjdk.org/browse/JDK-8151408

> * **Barriers**. Usually all operations of a stream pipeline can run
> simultaneously as data is available. In some cases, we may wish to have a
> barrier that requires that the entirety of one operation is completed before
> providing any elements to the next operation.

> Example: `someStream.a(...).barrier(someEffect)...` would require that all
> effects from `a` are completed before executing `someEffect` or producing any
> downstream values.

> See: https://bugs.openjdk.org/browse/JDK-8294246

> * **Windowing**. Given a stream, we may wish to construct a stream which
> groups the original elements, either in overlapping or disjoint groups.

> Example: `fixedWindow(2)` over the values `[1,2,3,4,5]` yields
> `[[1,2],[3,4],[5]]`.
> Example: `slidingWindow(2)` over the values `[1,2,3]` yields
> `[[1,2],[2,3],[3,4]]`.

> See:
> https://stackoverflow.com/questions/34158634/how-to-transform-a-java-stream-into-a-sliding-window

> * **Prefix scans**. Prefix scans are a stream of incremental reductions.
> Perhaps surprisingly, some prefix scans are parallelizable, and we are exploring
> adding support for that beyond `Arrays.parallelPrefix()`.

> Example: `scan((sum, next) -> sum + next)` over values `[1,2,3,4]` yields
> `[1,3,6,10]`

> See:
> https://stackoverflow.com/questions/55265797/cumulative-sum-using-java-8-stream-api

> * **Duplicated elements**. The `distinct` operation will remove duplicates;
> sometimes we want only the elements that are duplicated.

> Example: `duplicates(Object::equals)` over values `[1,1,2,3,4]` yields `[1]`

> See:
> https://stackoverflow.com/questions/27677256/java-8-streams-to-find-the-duplicate-elements

> * **Running duplicate elimination**. Here, we want to eliminate adjacent
> repeated elements.

> Example: `collapseRuns(Object::equals)` over values `[1,1,2,3,3]` yields
> `[1,2,3]`

> These are just a few of the stream operations people have wished for?
> and while many operations are too specialized to include in the core library,
> all are things we'd like for people to be able to express with streams.

> ## Extending streams

> It was always desired for `java.util.stream.Stream` to have an extension point
> for intermediate operations; when the library was first built, this wish-list
> item was recorded: https://bugs.openjdk.org/browse/JDK-8132369. There were many
> reasons that this was not included in the initial version, the most important
> being that it was not at all obvious what the right API was.

> The set of intermediate operations on Streams carries the exact same trade-off
> as [CISC](Complex Instruction Set Computing) vs [RISC](Reduced Instruction Set
> Computing), namely: either you have to provide a rather sizeable set of
> specialized operations, or you provide a small set of general operations.

> For the **CISC**-strategy, the main drawback is that not all operations is
> equally useful, and having a large set of operations to choose from creates a
> barrier to effective usage by making the correct choice harder to identify.

> For the **RISC**-strategy, the main drawback is that it puts more effort on the
> user to encode more specialized operations over a set of generic operations,
> making code harder to read, and harder to maintain, for the user.

> However, one success story was `Collector`; this allowed us to extend _terminal_
> operations with a good balance of expressiveness, reuse, and API footprint. We
> would like to do the same for intermediate operations -- and we can draw some
> inspiration from `Collector` to get there.

> ## Requirements

> Breaking down operations into intermediate and terminal is a useful distinction,
> however,
> in reality there are many more characteristics we could use to describe
> operations,
> and relatively few operations use exactly the same subset of characteristics.
> The following is a curated set of characteristics of stream operations;
> if we want to enable generic, user-defineable, intermediate operations on
> streams,
> we probably have to provide for them all.

> | Ordinal | Feature | What this means in practice | Example operation(s) |
> |---------|--------------------------|-------------------------------------------------------------|-------------------------------------|
>| 1 | Intermediate operation | Add custom new operations to Stream pipelines |
> | *map*, *filter* |
>| 2 | Incremental operation | Evaluate the Stream pipeline depth-first | *map*,
> | *filter* |
>| 3 | Stateful operation | Remember information between processing elements |
> | *limit*, *foldLeft* |
>| 4 | N:M inputs-to-outputs | Encode a wide array of operations | *limit*,
> | *flatMap* |
>| 5 | Prefix consumption | An operation should consume only as much as needed |
> | *limit*, *takeWhile* |
>| 6 | Beginning-of-stream hook | Ability to have initialization logic |
> | *foldLeft*, *grouped* |
> | 7 | End-of-stream hook | Flush elements downstream | *sorted*, *grouped* |
>| 8 | Opt-in parallelizability | Speed up CPU-bound processing for parallelizable
> | operations | *reduce*, *map* |

> Now when we have a better idea of what we need to achieve, let's have a look at
> what our options are.

> ## Comparing existing operations

> Let's look at the operations we already have, to see if they would fit the bill
> as a generic extension point for intermediate `Stream`-operations.

> These are, in order, `Stream.map()`, `Stream.flatMap(?)` (`Stream.mapMulti(?)`
> is analogous), and `Collector` & `Stream.collect(?)`?and in the table below we
> see how they line up against our requirements.

>| Ordinal | Feature | Using Stream.map(?) | Using Stream.flatMap(?) | Using
> | Collector |
> |---------|--------------------------|---------------------------|---------------------------|-----------------|
> | 1 | Intermediate operation | Yes | Yes | No, terminal |
> | 2 | Incremental operation | Yes | Yes | No, terminal |
>| 3 | Stateful operation | Yes, via class or capture | Yes, via class or capture |
> | Yes |
> | 4 | N:M inputs-to-outputs | No, 1:1 | No, 1:M | No, N:1 |
> | 5 | Prefix consumption | No | No | No |
> | 6 | Beginning-of-stream hook | No | No | Yes |
> | 7 | End-of-stream hook | No | No | Yes |
> | 8 | Opt-in parallelizability | No, always on | No, always on | No, always on |

> Looking at the options above, none of them are going to, as-is, fit the bill as
> an extension point for generic intermediate `Stream` operations, but one of them
> has more promise than the others: `Collector`. Obvious needed upgrades are
> supporting short-circuiting and incremental generation of output; let's see what
> that looks like in practice.

> ## Collector 2.0

> Let's start with a clone of `Collector<T,A,R>` called `Gatherer<T,A,R>`:

> ```java
> /** @param <T> the element type
> * @param <A> the (mutable) intermediate accumulation type
> * @param <R> the (probably immutable) final accumulation type
> */
> interface Gatherer<T,A,R> {
> Supplier<A> supplier();
> BiConsumer<A, T> accumulator();
> BinaryOperator<A> combiner();
> Function<A, R> finisher();
> }
> ```

> Now, we need to make it output 0...M elements instead of strictly 1. In order
> to do that, we need a way to programmatically output elements from the
> `accumulator` to make it incremental (and has the added benefit that it would be
> able to run depth-first). Adding an additional argument, a downstream handle,
> to `accumulator` and `finisher` allows us to push elements downstream both for
> each input, and at the end of stream. As there exists no suitable pre-existing
> interface, we'll define a new interface named `Integrator` and rename
> `accumulator`
> to the more fitting `integrator`.
> Our `finisher` will also not have a useful return value, so we'll make it
> `void`:

> ```java
> /** @param <T> the element type
> * @param <A> the (mutable) intermediate accumulation type
> * @param <R> the (probably immutable) final accumulation type
> */
> interface Gatherer<T,A,R> {
> interface Integrator<A,T,R> {
> void integrate(A state, T element, Consumer<? super R> downstream);
> }
> Supplier<A> supplier();
> Integrator<A, T, R> integrator();
> BinaryOperator<A> combiner();
> BiConsumer<A, Consumer<? super> R> finisher();
> }
> ```

> Next, we need to tackle short-circuiting and add an upstream signal from each
> invocation of the `integrator` so we can detect when the integration does not
> want any more elements. We do this by returning a boolean from `integrate`:

> ```java
> /** @param <T> the element type
> * @param <A> the (mutable) intermediate accumulation type
> * @param <R> the (probably immutable) final accumulation type
> */
> interface Gatherer<T,A,R> {
> interface Integrator<A,T,R> {
> boolean integrate(A state, T element, Consumer<? super R> downstream);
> }
> Supplier<A> supplier();
> Integrator<A, T, R> integrator();
> BinaryOperator<A> combiner();
> BiConsumer<A, Consumer<? super> R> finisher();
> }
> ```

> Transitively supporting short-circuiting, i.e. that a downstream handle does
> not want to receive any more elements, requires us to make the same change as
> we did for `integrate`?return a `boolean` instead of `void`, and since the
> only built-in candidate would be `Predicate`, which is not supposed to have
> side-effects, let's introduce our own type `Sink`:

> ```java
> /** @param <T> the element type
> * @param <A> the (mutable) intermediate accumulation type
> * @param <R> the (probably immutable) final accumulation type
> */
> interface Gatherer<T,A,R> {
> interface Sink<R> {
> boolean flush(R element);
> }
> interface Integrator<A,T,R> {
> boolean integrate(A state, T element, Sink<? super R> downstream);
> }
> Supplier<A> supplier();
> Integrator<A, T, R> integrator();
> BinaryOperator<A> combiner();
> BiConsumer<A, Sink<? super R>> finisher();
> }
> ```

> Finally, we need to address parallelism. To opt-in to parallelism we can make
> the combiner optional -- we call it only for parallel executions, and if it is
> not present, execution is constrained to sequential.

> To demonstrate how all of the above fits together, we implement `fixedWindow(N)`
> where `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.

> ```java
> /**
> * Gathers elements into fixed-size windows. The last window can contain fewer
> elements.
> * @param windowSize the size of the windows
> * @return a new gatherer which gathers elements into fixed-size windows
> * @param <T> the type of elements this Gatherer gathers
> */
> public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
> if (windowSize < 1)
> throw new IllegalArgumentException("'windowSize' must be greater than zero");
> else {
> Supplier<ArrayList<T>> supplier =
> () -> new ArrayList<T>(windowSize);

> Integrator<ArrayList<T>, T, List<T>> integrator =
> (openWindow, element, downstream) -> {
> if (openWindow.add(element) && openWindow.size() >= windowSize) {
> var closedWindow = List.copyOf(openWindow);
> openWindow.clear();
> return downstream.flush(closedWindow);
> } else
> return true;
> };

> // This combiner signals that we opt-out of parallelisation
> BinaryOperator<ArrayList<T>> combiner =
> Gatherer.unsupportedCombiner();

> BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher =
> (openWindow, downstream) -> {
> if(!openWindow.isEmpty()) {
> downstream.flush(List.copyOf(openWindow));
> openWindow.clear();
> }
> };

> return Gatherer.of(supplier, integrator, combiner, finisher);
> }
> }
> ```

> Or by implementing the `Gatherer` interface directly like so:

> ```java
> /**
> * Gathers elements into fixed-size windows. The last window can contain fewer
> elements.
> * @param windowSize the size of the windows
> * @return a new gatherer which gathers elements into fixed-size windows
> * @param <T> the type of elements this Gatherer gathers
> */
> public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
> if (windowSize < 1)
> throw new IllegalArgumentException("'windowSize' must be greater than zero");
> class FixedWindowGatherer implements Gatherer<T,ArrayList<T>,List<T>> {
> @Override
> public Supplier<ArrayList<T>> initializer() {
> return () -> new ArrayList<>(windowSize);
> }

> @Override
> public Integrator<ArrayList<T>, T, List<T>> integrator() {
> return (openWindow, element, downstream) -> {
> if (openWindow.add(element) && openWindow.size() >= windowSize) {
> var closedWindow = List.copyOf(openWindow);
> openWindow.clear();
> return downstream.flush(closedWindow);
> } else
> return true;
> };
> }

> @Override
> public BinaryOperator<ArrayList<T>> combiner() {
> return Gatherer.unsupportedCombiner();
> }

> @Override
> public BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher() {
> return (openWindow, downstream) -> {
> if(!openWindow.isEmpty()) {
> downstream.flush(List.copyOf(openWindow));
> openWindow.clear();
> }
> };
> }
> }
> return new FixedWindowGatherer();
> }
> ```

> Compared to Collector, it would look like the following:

> | Ordinal | Feature | `Collector<T,A,R>` | `Gatherer<T,A,R>` |
> |---------|--------------------------|-----------------------------------|---------------------------------------|
> | 1 | Beginning-of-stream hook | `A supply()` | `A supply()` |
> | 2 | Per element | `void accept(A, T)` | `boolean integrate(A, T, Sink<R>)` |
> | 3 | End-of-stream hook | `R apply(A)` | `void accept(A, Sink<R>)` |
> | 4 | Parallelizability | `A apply(A, A)` | `A apply(A, A)` |

> To integrate it with `java.util.stream.Stream` we add the following method to
> it: `Stream<R> gather(Gatherer<T,?,R> gatherer)`

> Now we can use our `fixedWindow` Gatherer:

> ```java
> jshell> Stream.iterate(0, i -> i + 1).limit(10).gather(fixedWindow(2)).toList();
> $1 ==> [[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]]
> ```

> Gatherer now provides all features:

> | Ordinal | Feature | Using Gatherer | Explanation |
> |---------|--------------------------|-------------------------|----------------------------------------------------------------------------------------|
>| 1 | Intermediate operation | Yes | A Gatherer's output is the following
> | operation's input |
>| 2 | Incremental operation | Yes | A Gatherer can produce elements in response to
> | consuming elements |
>| 3 | Stateful operation | Yes | A Gatherer supplies its own state, which can be
> | Void/null if stateless |
>| 4 | N:M inputs-to-outputs | Yes | A Gatherer can consume and produce any number
> | of elements |
>| 5 | Prefix consumption | Yes | A Gatherer can signal that it is done by
> | returning `false` from its `integrate`-method |
>| 6 | Beginning-of-stream hook | Yes | A Gatherer can run logic when creating its
> | initial state |
>| 7 | End-of-stream hook | Yes | A Gatherer's `finisher` is invoked at the end of
> | input |
> | 8 | Opt-in parallelizability | Yes | A Gatherer's `combiner` is optional |

> ## Summary

> None of the current candidates for a user-extensible API for generic
> intermediate stream operations fit the set of requirements, but `Collector`
> can form an excellent basis for a new construct, called `Gatherer`,
> which after a limited set of modifications checks all the boxes:

>| Ordinal | Feature | Using Stream.map(?) | Using Stream.flatMap(?) | Using
> | Collector | Using Gatherer |
> |---------|--------------------------|---------------------------|---------------------------|-----------------|----------------|
> | 1 | Intermediate operation | Yes | Yes | No, terminal | Yes |
> | 2 | Incremental operation | Yes | Yes | No, terminal | Yes |
>| 3 | Stateful operation | Yes, via class or capture | Yes, via class or capture |
> | Yes | Yes |
> | 4 | N:M inputs-to-outputs | No, 1:1 | No, 1:M | No, N:1 | Yes |
> | 5 | Prefix consumption | No | No | No | Yes |
> | 6 | Beginning-of-stream hook | No | No | Yes | Yes |
> | 7 | End-of-stream hook | No | No | Yes | Yes |
>| 8 | Opt-in parallelizability | No, always on | No, always on | No, always on |
> | Yes |

> As it turned out, we were a short hop away from a generic, stand-alone,
> reusable, parallelizable, API for intermediate operations all along!

> ## But wait ? there's more

> While the aforementioned solution contains the bare-minimum to meet our
> requirements,
> the following will provide some significant quality-of-life improvements.

> ### Compositionality

> The astute reader may have noticed that by adding the `gather(Gatherer)`-method
> on `Stream`,
> one can in-effect **compose** `Gatherer`s together:

> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Stream<Long> stream =
> Stream.of(1).gather(someGatherer).gather(someOtherGatherer);
> ```

> As it turns out, it is possible to define a `default Gatherer
> andThen(Gatherer)`-method on `Gatherer` which composes `Gatherer`s:

> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Gatherer<Integer,?,Long> gatherer = someGatherer.andThen(someOtherGatherer);
> ```

> This makes it possible to both de-couple operations from their use-sites,
> as well as create more sophisticated `Gatherer`s from simple ones.

> But that's not all?by introducing a `default Collector
> collect(Collector)`-method
> it is also possible to compose a `Gatherer` with a `Collector`,
> and the result is another `Collector`:

> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Collector<Long,?,List<Long>>
> someGatherer.andThen(someOtherGatherer).collect(Collectors.toList());
> ```

> All of this together, it is now possible to build `Stream`-processing:
> "source-to-destination" using `Stream.gather(?).gather(?).gather(?)`;
> "intermediaries-first" using `gatherer.andThen(?).andThen(?);` and,
> "destination-to-source" using `gatherer.collect(otherGatherer.collect(?))`.

> ### Familiarity

> Since `Gatherer` is an evolution of `Collector` there's a clear on-ramp
> for any and all Java developers who are already familiar with `Collector`.

> ### Reusability

> `Gatherer`s, by virtue of being stand-alone, reusable, intermediaries,
> paired with compositionality and opt-in parallelization, allows for
> transformations
> to be created once and maintained in a single place, no matter if it is going to
> be
> used as a `Collector`, a `Gatherer`, or a `Stream`.

> ### Optimizability

> `Collector` has the notion of `Characteristics`, a `Set` of flags which
> describes them.
> This information can then be used by the underlying machinery which uses them
> to optimize their evaluation. The same approach can be used for `Gatherer`s.

> ### Summary 2.0

> Taking all of the above into consideration, we end up with a definition like the
> following:

> ```java
> /** @param <T> the element type
> * @param <A> the (mutable) intermediate accumulation type
> * @param <R> the (probably immutable) final accumulation type
> */
> interface Gatherer<T,A,R> {

> interface Sink<R> {
> boolean flush(R element);
> }
> interface Integrator<A,T,R> {
> boolean integrate(A state, T element, Sink<? super R> downstream);
> }

> enum Characteristics {
> GREEDY, // Never short-circuits
> SIZE_PRESERVING, // Emits exactly once per input element
> STATELESS; // No need to initialize or combine state
> }

> Supplier<A> supplier();
> Integrator<A, T, R> integrator();
> BinaryOperator<A> combiner();
> BiConsumer<A, Sink<? super R>> finisher();
> Set<Characteristics> characteristics();

> default <AA, RR> Gatherer<T,?,RR> andThen(Gatherer<R,AA,RR> that) {
> // Gatherers is analoguous to Collectors
> return Gatherers.Composite.of(this, that);
> }

> default <RR> Collector<T,?,RR> collect(Collector<R, ?, RR> collector) {
> // Gatherers is analoguous to Collectors
> return Gatherers.GathererCollector.of(this, collector);
> }
> }
> ```

> ## Appetizers

> The following examples showcase how `Gatherer` can be used to implement a
> diverse set
> of pre-existing, and future, intermediate operations for `Stream`s.

> ### How to implement `map(mapper)`

> ```java
> public final static <T,R> Gatherer<T, ?, R> map(Function<? super T, ? extends R>
> mapper) {
> return Gatherer.of(
> () -> (Void)null,
> (nothing, element, downstream) ->
> downstream.flush(mapper.apply(element)),
> (l,r) -> l,
> (nothing, downstream) -> {}
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(map(i -> i + 1)).toList()
> $1 ==> [2, 3, 4, 5]
> ```

> ### How to implement `flatMap(mapper)`

> ```java
> public final static <T,R> Gatherer<T, ?, R> flatMap(Function<? super T, ?
> extends Stream<R>> mapper) {
> return Gatherer.of(
> () -> (Void)null,
> (nothing, element, downstream) -> {
> try(Stream<? extends R> s = mapper.apply(element)) {
> return s == null || s.sequential().allMatch(downstream::flush);
> }
> },
> (l,r) -> l,
> (nothing, downstream) -> {}
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(flatMap(i -> Stream.of(i + 1))).toList()
> $1 ==> [2, 3, 4, 5]
> ```

> ### How to implement `takeWhile(predicate)`

> ```java
> public final static <T> Gatherer<T, ?, T> takeWhile(Predicate<? super T>
> predicate) {
> return Gatherer.of(
> () -> (Void)null,
> (nothing, element, downstream) ->
> predicate.test(element) && downstream.flush(element),
> (l, r) -> l,
> (nothing, downstream) -> {}
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(takeWhile(i -> i < 3)).toList()
> $1 ==> [1, 2]
> ```

> ### How to implement `limit(N)`

> ```java
> public static <M> Gatherer<M, ?, M> limit(long limit) {
> if (limit < 0)
> throw new IllegalArgumentException("'limit' has to be non-negative");

> class At { long n = 0; }
> return Gatherer.of(
> At::new,
> (at, element, downstream) ->
> at.n < limit && downstream.flush(element) && ++at.n < limit,
> Gatherer.unsupportedCombiner(),
> (at, downstream) -> {}
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(limit(2)).toList()
> $1 ==> [1, 2]
> ```

> ### How to implement prefix `scanLeft`

> ```java
> public static <T,R> Gatherer<T,?,R> scanLeft(R initial, BiFunction<R,T,R>
> scanner) {
> class State { R current = initial; }
> return Gatherer.of(
> State::new,
> (state, element, downstream) ->
> downstream.flush(state.current = scanner.apply(state.current, element)),
> Gatherer.unsupportedCombiner(),
> (state, downstream) -> {}
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(scanLeft("'", (acc, elem) -> acc + elem +
> "'")).toList()
> $1 ==> ['1', '1'2', '1'2'3', '1'2'3'4']
> ```

> ### How to implement `fold(initial, folder)`

> ```java
> public static <T> Gatherer<T,?,T> fold(T initial, BinaryOperator<T> folder) {
> class State { T current = initial; }
> return Gatherer.of(
> State::new,
> (state, element, downstream) -> {
> state.current = folder.apply(state.current, element);
> return true;
> },
> (l, r) -> {
> l.current = folder.apply(l.current, r.current);
> return l;
> },
> (state, downstream) -> downstream.flush(state.current)
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(fold(0, (acc, elem) -> acc + elem)).toList()
> $1 ==> [10]
> ```

> ### How to implement `foldLeft(initial, folder)`

> ```java
> public static <T,R> Gatherer<T,?,R> foldLeft(R initial, BiFunction<R,T,R>
> folder) {
> class State { R current = initial; }
> return Gatherer.of(
> State::new,
> (state, element, downstream) -> {
> state.current = folder.apply(state.current, element);
> return true;
> },
> Gatherer.unsupportedCombiner(),
> (state, downstream) -> downstream.flush(state.current)
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,3,4).gather(foldLeft(0L, (acc, elem) -> acc +
> elem)).toList()
> $1 ==> [10]
> ```

> ### How to implement `deduplicateAdjacent()`

> ```java
> public static <T> Gatherer<T,?,T> deduplicateAdjacent() {
> class State { T prev; boolean hasPrev; }
> return Gatherer.of(
> State::new,
> (state, element, downstream) -> {
> if (!state.hasPrev) {
> state.hasPrev = true;
> state.prev = element;
> return downstream.flush(element);
> } else if (!Objects.equals(state.prev, element)) {
> state.prev = element;
> return downstream.flush(element);
> } else {
> return true; // skip duplicate
> }
> },
> Gatherer.unsupportedCombiner(),
> (state, downstream) -> {}
> );
> }
> ```

> ```java
> jshell> Stream.of(1,2,2,3,2,4).gather(deduplicateAdjacent()).toList()
> $1 ==> [1, 2, 3, 2, 4]
> ```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/b6dd30ad/attachment-0001.htm>

From alanb at openjdk.org  Thu Jun 29 08:31:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 08:31:00 GMT
Subject: RFR: 8281658: Add a security category to the java -XshowSettings
 option [v8]
In-Reply-To: <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
References: <dvukLYc1qCoouLuWNvs-6fbowx67skWbnkpdN703B_8=.e1024311-8595-41dc-833e-561f74763372@github.com>
 <Do1PCxXWlOkJ92jocEgyrtJsJZ2lQkJXgFDEFd0mxAc=.f4957955-4d6b-4066-8b94-50e47a7e96f8@github.com>
Message-ID: <rsK3bo2OtxGtMNdH4oNR3c-acbpFl9ki1mBzG4_x8wY=.5251d1ac-f83f-4b78-82b6-5dec965186c9@github.com>

On Tue, 27 Jun 2023 15:06:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> New functionality in the -XshowSettings menu to display relevant information about JDK security configuration
>
> Sean Coffey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Avoid sharing INDENT variables
>  - Merge branch 'master' into 8281658-showsettings-security
>  - Don't allow bad subcommand values for security component
>  - restore more informative help message
>  - Split long properties for ; also
>  - Pass PrintStream to security helper
>  - Refactor out security code to helper class
>  - Print aliases. Order Provider type/service output.
>  - Incorporate review comments from Roger and tweak some code
>  - Merge branch 'master' into 8281658-showsettings-security
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/6dc03296...7e6f5090

I looked through the current version (7e6f5090) and you've got it to a good place, the launcher changes look fine.

The changes make me wonder if `-XshowSetting:aardvark` should be an error rather than default to print all settings. Something we should look at again.  Same thing for `-XshowSettings:system` on non-Linux, probably should have been a bit more discussion when that was added as its more about the container environment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14394#issuecomment-1612623972

From uschindler at openjdk.org  Thu Jun 29 08:42:56 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Thu, 29 Jun 2023 08:42:56 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v6]
In-Reply-To: <RWfoFJNDqlM40s-PoWBYZqU6DQlOiDt-L8OERLXwGEQ=.7d67c4f1-099d-477f-b094-ec40a587fecd@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <pOvLWlwkhuJBmWjY3aG9T_vUK3IMuqLh3vxpYhdXXek=.8ad03f6c-4b4a-4d01-81e8-8ff0a937d07a@github.com>
 <Qi92DOk4kYykz5F2zFEiYAaq1N-xPztobdmsSa3PgMQ=.b8879da8-be21-4839-acd3-f6b1fe5dc410@github.com>
 <e7vdNMZIuP1GMLeY-99cOLu9C8Jkd2g4xHA53a9-Oac=.84b82f50-5540-4f8b-b820-73b6ed87b712@github.com>
 <RWfoFJNDqlM40s-PoWBYZqU6DQlOiDt-L8OERLXwGEQ=.7d67c4f1-099d-477f-b094-ec40a587fecd@github.com>
Message-ID: <8Fb0Jvg2ohOU6kCrHal0Lngm-JkRq1HO-nqUVfaMsP8=.f4c6e0d2-9f0c-4505-973b-6b59eb3c3a3b@github.com>

On Thu, 29 Jun 2023 07:59:42 GMT, Glavo <duke at openjdk.org> wrote:

> I understand the original reason for retaining it before, but this discussion is outdated for this PR.
> 
> `Unsafe` does not provide `getFloatUnaligned`/`getDoubleUnaligned` and `putFloatUnaligned`/`putDoubleUnaligned`, so we must convert floating point numbers to integers here. This problem is no longer hidden behind `VarHanle`, so we have to face it.
> 
> In addition, these comments are indeed wrong and may mislead users. I saw this mentioned in the previous discussion, but I don't know why the document was not cleaned up. I think it's time to clean it up.

I was involved in the original discussion. The problem that leads to the misunderstanding is the asymetry. It is only important to make sure that stuff writen to files needs to have normalized NaN. So basically, RandomAccessFile and others should use Float.toIntBits when writing and not raw int bits.

The other way round in reality does not matter at all, because when reading from a file the bits can be kept as is, because the JVM later knows how to handle them. There is also no 'Float.rawIntBitsToFloat()'. Actually behind the scenes the `Float.intBitsToFloat()` method already takes care to convert the int bits, so it works with both raw and normalized floats.

In my opinion, this PR makes sense, iff you want to use the class on early startup. Back at the time of original PR, using VarHandle (like Apache Lucene does) was the most elegant way to do this. It only affected RandomAccessFile and ObjectInput/OutputStream, so having a clean VarHandle implementation was perfectly fine and not critical for startup times.

I am fine with this, just make sure to remove outdated comments or correct them. The whole thing should be handled like: if you write floats/doubles make sure to give the option to call to normalize them or not. For writing to files this is a must.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1612640215

From duke at openjdk.org  Thu Jun 29 08:46:32 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 08:46:32 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v31]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <F7M975AUFDou6NEossq8y5qAGkDp9zqCYEyc8km3MEw=.7458fcf1-32df-4d04-a882-31292f31c996@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  revert HexDigits.DIGITS private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/26f3a6a5..0a7f2cc4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=29-30

  Stats: 42 lines in 2 files changed: 17 ins; 18 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Thu Jun 29 08:51:58 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 08:51:58 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v32]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <Hk8odTr9LatwZMXxoelMrgH8xxT8lu8J1XKX6JRRkcY=.de469548-87e5-439c-8848-9fcd7d75f569@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  code format

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/0a7f2cc4..93e74b6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=30-31

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From duke at openjdk.org  Thu Jun 29 08:52:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 08:52:00 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v31]
In-Reply-To: <F7M975AUFDou6NEossq8y5qAGkDp9zqCYEyc8km3MEw=.7458fcf1-32df-4d04-a882-31292f31c996@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <F7M975AUFDou6NEossq8y5qAGkDp9zqCYEyc8km3MEw=.7458fcf1-32df-4d04-a882-31292f31c996@github.com>
Message-ID: <IPfGSNHM-tBWxfCQV0I-IwfEshH0VUY1pl3eEORd1Uc=.6776822c-d20e-41e7-92b1-95bb472a7815@github.com>

On Thu, 29 Jun 2023 08:46:32 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert HexDigits.DIGITS private

> HexDigits.DIGITS



> I've read through [26f3a6a](https://github.com/openjdk/jdk/commit/26f3a6a5317718235bc3506f0a3e851001f43404) (iteration 29) and it mostly looks okay.
> 
> It's good to see the UUID code removed from Long.
> 
> It's unfortunate that UUID is directly accessing HexDigits.DIGITS but at least its in the same package and the array is accessed more widely. If there were frozen arrays then this would be better. Have you measured using an accessor method to access the array elements rather than accessing the array directly?
> 
> Somewhat subjective but I find the new comment in Digits a bit confusing, particularly "In the byte[] encoded in LATIN1" as a byte[] is just bytes and I think you want to say a String encoding as LATIN1 in a byte[]. Maybe drop this and the reference to jdk.internal.util.ByteArray.

Good suggestion, it has been modified and submitted. now UUID#toString codeSize is 203, less than default FreqInlineSize 325,  It can be inline, and the performance is better than the previous version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1612648221

From lkorinth at openjdk.org  Thu Jun 29 08:58:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 08:58:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <z1LaNlMKfruphxc495xDHe2Ou64psUrXMobtiqqnqqk=.cdf515c9-2243-42ba-bea6-d24967ce3634@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.
>
> It also seems far too large and disruptive.

Do you still think it is too disruptive after Erik's explanation?  I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457

From alanb at openjdk.org  Thu Jun 29 09:09:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 09:09:10 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v32]
In-Reply-To: <Hk8odTr9LatwZMXxoelMrgH8xxT8lu8J1XKX6JRRkcY=.de469548-87e5-439c-8848-9fcd7d75f569@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <Hk8odTr9LatwZMXxoelMrgH8xxT8lu8J1XKX6JRRkcY=.de469548-87e5-439c-8848-9fcd7d75f569@github.com>
Message-ID: <2ai0vAFCHOYainDEqTE3jBKMRkaCQe6Ncxc0o6rhgtU=.9d3f2863-791f-4777-91ac-ab08a18a3f26@github.com>

On Thu, 29 Jun 2023 08:51:58 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code format

I think you've got this to a good place with version 93e74b6c. It might be helpful if the Digit.digts methods mentioned the endianness in the comment otherwise okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14578#pullrequestreview-1504877593

From viktor.klang at oracle.com  Thu Jun 29 09:09:22 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 29 Jun 2023 09:09:22 +0000
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <1265852641.92738200.1688025826687.JavaMail.zimbra@univ-eiffel.fr>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1265852641.92738200.1688025826687.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB5774FEB66809009BCA5FD914FF25A@MW4PR10MB5774.namprd10.prod.outlook.com>



________________________________
From: Remi Forax <forax at univ-mlv.fr>
Sent: Thursday, 29 June 2023 10:03
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Re: java.util.stream.Stream: API for user-extensible intermediate operations



________________________________
From: "Viktor Klang" <viktor.klang at oracle.com>
To: "core-libs-dev" <core-libs-dev at openjdk.org>
Sent: Tuesday, June 27, 2023 7:10:42 PM
Subject: java.util.stream.Stream: API for user-extensible intermediate operations
Hi core-libs-dev,

Over the past 6+ months I've been thinking about, and tinkering with, how we'd be able to expose a user-facing API for extensible intermediate java.util.stream.Stream operations?a feature envisioned all the way back when Streams were created.

I'm now at a point where I have a viable design and implementation, and so I'm turning to you for your feedback: on the direction taken; the API concepts; and, in particular, is there anything which I have overlooked/missed?

>I think this API is overly generic and hard to reason about it, for users and IDEs.

The API is for all intents and purposes Collector with a boolean return type for the accumulator and an added downstream handle parameter added to the accumulator and the finisher.

>The main issue is that the same API is used for both stateless and stateful operations, which means that as a user, we have no idea if a call to stream.gather() is stateful or not.

How is this different from any of the other pre-existing Stream operations?

>Which is a departure from the current API that cleanly separate stateless and staful operations. Here, we are left in the dark. In a sense, this API is too powerful, it can do too much thing, so as a user we can not reason about it.

A Gatherer encodes it input and output types, in what sense would that not be enough to reason about it?

>I like the idea of a Collector 2.0 i.e. using the Gatherer API at the end of the stream (not in the middle), but currently, the Gatherer API is not a Collector, so we now have two different APIs for doing partially the same job. I wonder if the Collector API can be retroffitted to act as a Gatherer API, avoiding to have to choose which one to use, a gatherer being the equivalent of a "flat-collector" + short-circuit.

Collector serves a very important role of being able to get information out of a Stream and deliver that information in a certain shape, a Gatherer does not provide any facility for this.

>The idea of unsupportedCombiner() seems out of place, like a patch to be able to clobble different things together. I'm not sure to understand why it's needed for a Gatherer, and why it is not needed for Collectors ?

Nothing prevents us from treating a `null` combiner the same way. My primary reason for making it a dedicated thing was to be able to differentiate a possible bug (user passing in a null reference inadvertently) from explicitly stating that a combiner does not exist from this operation.

unsupportedCombiner() as an artifact can be completely hidden if desired, as Gatherer.of() can have permutations without specifying a combiner, and the default method of Gatherer.combiner() could return unsupportedCombiner(). I opted not to do this initially, because I felt like being explicit about not having a combiner means that it is a concious decision by the implementor of the Gatherer.


>So I would prefer that API to extends the current Collector API but not the intermediary operations. Yes, it's less powerful.
It means that instead of using one stream with a collect like operation in the middle, users will have to use two streams, one after the other, but it makes the code easier to understand (also having two streams give users better control on which part should be in parallel).

That would be something completely different from the goal of providing user-extensible intermediate operations, which is something which this proposal is explicitly trying to address.

Cheers,
?

>R?mi


(If you, like myself, prefer reading pre-rendered markdown, click here<https://cr.openjdk.org/~vklang/Gatherers.html>)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/88722009/attachment-0001.htm>

From asemenov at openjdk.org  Thu Jun 29 09:11:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Jun 2023 09:11:05 GMT
Subject: Integrated: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <RJfR256QMKuXBAiw1oWhHWImDH-oLic1q__QwUdR6OU=.fa227014-c5f4-4466-9677-a6061cf39c4a@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

This pull request has now been integrated.

Changeset: 98a954ee
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98a954eebc4f97dd16cb89bd4f1122952c8482ca
Stats:     20 lines in 6 files changed: 14 ins; 0 del; 6 mod

8308286: Fix clang warnings in linux code

Reviewed-by: avu, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/14033

From liach at openjdk.org  Thu Jun 29 09:28:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 09:28:09 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v32]
In-Reply-To: <Hk8odTr9LatwZMXxoelMrgH8xxT8lu8J1XKX6JRRkcY=.de469548-87e5-439c-8848-9fcd7d75f569@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <Hk8odTr9LatwZMXxoelMrgH8xxT8lu8J1XKX6JRRkcY=.de469548-87e5-439c-8848-9fcd7d75f569@github.com>
Message-ID: <y3JT5guDaSm40gcxwFOoTuXBRZccM8nPgyNvrc2G9N0=.f85ea7c6-3f79-418d-b4ac-e9b4f6cb57b3@github.com>

On Thu, 29 Jun 2023 08:51:58 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code format

I think ByteArray can be safely used here: UUID is not used by anything in java.base and shouldn't be initialized on VM startup.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/14578#pullrequestreview-1504908654

From viktor.klang at oracle.com  Thu Jun 29 09:49:50 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 29 Jun 2023 09:49:50 +0000
Subject: [External] : Re: java.util.stream.Stream: API for user-extensible
 intermediate operations
In-Reply-To: <CAE+3fjbkkg=DKjMmb+is1TLbDe0XPRGeQ+vPQ64eG6Afbv9yNg@mail.gmail.com>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAE+3fjbkkg=DKjMmb+is1TLbDe0XPRGeQ+vPQ64eG6Afbv9yNg@mail.gmail.com>
Message-ID: <MW4PR10MB5774EA3F0457CF0C4D0CE74AFF25A@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi Tagir!

Thanks for your input?comments inline.

________________________________
From: Tagir Valeev <amaembo at gmail.com>
Sent: Wednesday, 28 June 2023 22:15
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: [External] : Re: java.util.stream.Stream: API for user-extensible intermediate operations

Hello!

Interesting read, thanks. I'm the author of the StreamEx library,
which actually enhances Stream API, and I use it during my daily job,
so I have some thoughts about extending Stream API as well. Below are
some of them.

First, there are many useful operations that can be trivially defined
in terms of existing operations. For example,
  mapPartial(Function<? super T, ? extends Optional<? extends R>> mapper)
It's essentially map(mapper).flatMap(Optional::stream), though it's
much more performant to express it as
  map(value -> mapper.apply(value).orElse(null)).filter(Objects::nonNull)
It might be desired to encapsulate such implementations in static
methods, and here .chain() or .transform() method would be helpful,
see https://bugs.openjdk.org/browse/JDK-8140283.

Implementing such a partial map as a Gatherer would likely be more performant than a map + filter.


public static <T,R> Gatherer<T,?,R> mapPartial(Function<? super T, ? extends Optional<? extends R>> mapper) {
    return Gatherer.of(
                () -> (Void)null,
                (nothing, element, downstream) -> {
                    var out = mapper.apply(element);
                    return out.isEmpty() || downstream.flush(out.get());
                },
                (l,r) -> l,
                (nothing, downstream) -> {}
            );
}


There are also some operations that cannot be expressed via existing
'normal' operations, and could be implemented taking spliterator() of
the original stream.
This is somewhat limited, especially taking into account how
WrappingSpliterator handles tryAdvance and trySplit. Stream API would
certainly benefit
if it can be more transparent and provide better ways to extend it.

The behavior of Stream.spliterator() is unfortunately a side-effect of having push-style Streaming,
and that is not something that this proposal is trying to address.

One problematic place is how to provide a reasonable default
implementation for new methods like 'gather'. There are many
third-party implementations of Stream interface in the wild. Many of
them
just delegate most of the operations to JDK stream, adding some custom
logic. It should be expected that calling 'gather' on them will work
according to the spec.

This is an interesting question, and having a default implementation
which doesn't throw UOE might be tricky since the aforementioned challenges with Stream.spliterator().
But perhaps it would be possible to arrive at something which by default does the right thing.

Another thing that bothers me is parallel stream support. Not every
custom operation that you may imagine could be efficiently implemented
for parallel streams. But for some operations this is certainly
possible. It's unclear whether the proposed Gatherer interface is
flexible enough to provide good parallelization for operations. I have
a couple of exercises:

<snip>

I see that Brian already explained some of the design implications of Spliterator regarding this so I'll just add:

There are many possible interaction between left-and-right segments of a Spliterator, and some operations might need to recursively recompute themselves if they detect that their results would have been different knowing what data was adjecent to them. While it would be interesting to explore a potential model which can perform such recomputation of result (and output!) at the combination stage, in this proposal I opted to keep as true to Collector as possible and not make combiner something like:

(LeftAccumulator, LeftOutput, RightAccumulator, RightOutput) -> (CombinedAccumulator, CombinedOutput)


Many combining collectors (mapping, filtering,
flatMapping, partitioningBy) can be adapted to produce a
short-circuiting collector if the downstream collector is
short-circuiting. All of these collectors can parallelize nicely. I
needed to hack the collect() terminal operation to support this stuff
properly.

The good news is that there's no real difference between the parallelizability of Gatherer and Collector. ?

With best regards,
Tagir Valeev.

Cheers,
?

On Tue, Jun 27, 2023 at 7:11?PM Viktor Klang <viktor.klang at oracle.com> wrote:
>
> Hi core-libs-dev,
>
> Over the past 6+ months I've been thinking about, and tinkering with, how we'd be able to expose a user-facing API for extensible intermediate java.util.stream.Stream operations?a feature envisioned all the way back when Streams were created.
>
> I'm now at a point where I have a viable design and implementation, and so I'm turning to you for your feedback: on the direction taken; the API concepts; and, in particular, is there anything which I have overlooked/missed?
>
> (If you, like myself, prefer reading pre-rendered markdown, click here)
>
>
>
>
> # Gathering the streams
>
> ## Introduction
>
> Java 8 introduced the `java.util.stream` API, which represents a lazily
> computed, potentially unbounded sequence of values (Streams was also the first
> designed-for-lambdas API in the JDK). Streams supports the ability to process
> the stream either sequentially or in parallel.
>
> A `Stream` pipeline consists of a source (collection, array, generator, etc),
> zero or more intermediate operations (`Stream` -> `Stream` transforms), and an
> eager terminal operation which produces a value or a side-effect.
>
> The Streams API come with a reasonably rich, but fixed set of built-in
> operations (mapping, filtering, reduction, sorting, etc), as well as an
> extensible terminal operation (`Stream::collect`) that enables the stream
> contents to be flexibly summarized in a variety of forms.  The resulting API is
> rich enough that users have had good experience with streams, but there are
> repeated requests for "please add operation X to streams".
>
> In this document, we explore a corresponding extensible _intermediate_
> operation, called `Stream::gather`, which is able to address many of the
> requests we've gotten for additional operations.
>
> ## "Missing" intermediate operations
>
> Over the years, many new operations for streams have been proposed.  Each of
> them may be useful in some situation, but many of them are too narrow to be
> included in the core `Stream` API.  We'd like for people to be able to plug
> these operations in via an extension point, as with `Stream::collect`.
>
> Here are some examples of proposed intermediate operations that are not easily
> expressible as intermediate operations on `Stream` today.
>
> * **Folds**.  Folding is a generalization of reduction.  With reduction, the
>   result type is the same as the element type, the combiner is associative, and
>   the initial value is an identity for the combiner.   For a fold, these
>   conditions are not required, though we give up parallelizability.
>
>   Example: `foldLeft("", (str,elem) -> str + " " + elem.toString())` over the values
>   `[1,2,3]` yields `["1 2 3"]`.
>
>   See https://bugs.openjdk.org/browse/JDK-8133680 & https://bugs.openjdk.org/browse/JDK-8292845
>
> * **Unfolds**.  This takes an aggregate and decomposes it into elements.  An
>   `unfold` can reverse the operation of the above fold example using `Scanner`
>   or `String::split`.
>
>   Example: `unfold(e -> new Scanner(e), Scanner::hasNextInt, Scanner::nextInt)`
>   `["1 2 3"]` yields `[1,2,3]`.
>
>   See: https://bugs.openjdk.org/browse/JDK-8151408
>
> * **Barriers**.  Usually all operations of a stream pipeline can run
>   simultaneously as data is available.  In some cases, we may wish to have a
>   barrier that requires that the entirety of one operation is completed before
>   providing any elements to the next operation.
>
>   Example: `someStream.a(...).barrier(someEffect)...` would require that all
>   effects from `a` are completed before executing `someEffect` or producing any
>   downstream values.
>
>   See: https://bugs.openjdk.org/browse/JDK-8294246
>
> * **Windowing**.  Given a stream, we may wish to construct a stream which
>   groups the original elements, either in overlapping or disjoint groups.
>
>   Example: `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
>   Example: `slidingWindow(2)` over the values `[1,2,3]` yields `[[1,2],[2,3],[3,4]]`.
>
>   See: https://urldefense.com/v3/__https://stackoverflow.com/questions/34158634/how-to-transform-a-java-stream-into-a-sliding-window__;!!ACWV5N9M2RV99hQ!NglYDFc8WmZolFj2DNYbSCWpnWAzx8gJB1TkHmfysGvzzngpOYqhrx0zUPoW7QEtc89fJoXQ-k8cuoff6Q$
>
> * **Prefix scans**. Prefix scans are a stream of incremental reductions.
>   Perhaps surprisingly, some prefix scans are parallelizable, and we are exploring adding support for that beyond `Arrays.parallelPrefix()`.
>
>   Example: `scan((sum, next) -> sum + next)` over  values `[1,2,3,4]` yields `[1,3,6,10]`
>
>   See: https://urldefense.com/v3/__https://stackoverflow.com/questions/55265797/cumulative-sum-using-java-8-stream-api__;!!ACWV5N9M2RV99hQ!NglYDFc8WmZolFj2DNYbSCWpnWAzx8gJB1TkHmfysGvzzngpOYqhrx0zUPoW7QEtc89fJoXQ-k-slfctaw$
>
> * **Duplicated elements**.  The `distinct` operation will remove duplicates; sometimes we want only the elements that are duplicated.
>
>   Example: `duplicates(Object::equals)` over values `[1,1,2,3,4]` yields `[1]`
>
>   See: https://urldefense.com/v3/__https://stackoverflow.com/questions/27677256/java-8-streams-to-find-the-duplicate-elements__;!!ACWV5N9M2RV99hQ!NglYDFc8WmZolFj2DNYbSCWpnWAzx8gJB1TkHmfysGvzzngpOYqhrx0zUPoW7QEtc89fJoXQ-k-2zsbPqQ$
>
> * **Running duplicate elimination**.  Here, we want to eliminate adjacent repeated elements.
>
>   Example: `collapseRuns(Object::equals)` over values `[1,1,2,3,3]` yields `[1,2,3]`
>
> These are just a few of the stream operations people have wished for?
> and while many operations are too specialized to include in the core library,
> all are things we'd like for people to be able to express with streams.
>
> ## Extending streams
>
> It was always desired for `java.util.stream.Stream` to have an extension point
> for intermediate operations; when the library was first built, this wish-list
> item was recorded: https://bugs.openjdk.org/browse/JDK-8132369.  There were many
> reasons that this was not included in the initial version, the most important
> being that it was not at all obvious what the right API was.
>
> The set of intermediate operations on Streams carries the exact same trade-off
> as [CISC](Complex Instruction Set Computing) vs [RISC](Reduced Instruction Set
> Computing), namely: either you have to provide a rather sizeable set of
> specialized operations, or you provide a small set of general operations.
>
> For the **CISC**-strategy, the main drawback is that not all operations is
> equally useful, and having a large set of operations to choose from creates a
> barrier to effective usage by making the correct choice harder to identify.
>
> For the **RISC**-strategy, the main drawback is that it puts more effort on the
> user to encode more specialized operations over a set of generic operations,
> making code harder to read, and harder to maintain, for the user.
>
> However, one success story was `Collector`; this allowed us to extend _terminal_
> operations with a good balance of expressiveness, reuse, and API footprint.  We
> would like to do the same for intermediate operations -- and we can draw some
> inspiration from `Collector` to get there.
>
> ## Requirements
>
> Breaking down operations into intermediate and terminal is a useful distinction, however,
> in reality there are many more characteristics we could use to describe operations,
> and relatively few operations use exactly the same subset of characteristics.
> The following is a curated set of characteristics of stream operations;
> if we want to enable generic, user-defineable, intermediate operations on streams,
> we probably have to provide for them all.
>
> | Ordinal | Feature                  | What this means in practice                                 | Example operation(s)                |
> |---------|--------------------------|-------------------------------------------------------------|-------------------------------------|
> |    1    | Intermediate operation   | Add custom new operations to Stream pipelines               | *map*, *filter*                     |
> |    2    | Incremental operation    | Evaluate the Stream pipeline depth-first                    | *map*, *filter*                     |
> |    3    | Stateful operation       | Remember information between processing elements            | *limit*, *foldLeft*                 |
> |    4    | N:M inputs-to-outputs    | Encode a wide array of operations                           | *limit*, *flatMap*                  |
> |    5    | Prefix consumption       | An operation should consume only as much as needed          | *limit*, *takeWhile*                |
> |    6    | Beginning-of-stream hook | Ability to have initialization logic                        | *foldLeft*, *grouped*               |
> |    7    | End-of-stream hook       | Flush elements downstream                                   | *sorted*, *grouped*                 |
> |    8    | Opt-in parallelizability | Speed up CPU-bound processing for parallelizable operations | *reduce*, *map*                     |
>
> Now when we have a better idea of what we need to achieve, let's have a look at
> what our options are.
>
> ## Comparing existing operations
>
> Let's look at the operations we already have, to see if they would fit the bill
> as a generic extension point for intermediate `Stream`-operations.
>
> These are, in order, `Stream.map()`, `Stream.flatMap(?)` (`Stream.mapMulti(?)`
> is analogous), and `Collector` & `Stream.collect(?)`?and in the table below we
> see how they line up against our requirements.
>
> | Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector |
> |---------|--------------------------|---------------------------|---------------------------|-----------------|
> |    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    |
> |    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    |
> |    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             |
> |    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         |
> |    5    | Prefix consumption       | No                        | No                        | No              |
> |    6    | Beginning-of-stream hook | No                        | No                        | Yes             |
> |    7    | End-of-stream hook       | No                        | No                        | Yes             |
> |    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   |
>
> Looking at the options above, none of them are going to, as-is, fit the bill as
> an extension point for generic intermediate `Stream` operations, but one of them
> has more promise than the others: `Collector`.  Obvious needed upgrades are
> supporting short-circuiting and incremental generation of output; let's see what
> that looks like in practice.
>
> ## Collector 2.0
>
> Let's start with a clone of `Collector<T,A,R>` called `Gatherer<T,A,R>`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     Supplier<A> supplier();
>     BiConsumer<A, T> accumulator();
>     BinaryOperator<A> combiner();
>     Function<A, R> finisher();
> }
> ```
>
> Now, we need to make it output 0...M elements instead of strictly 1.  In order
> to do that, we need a way to programmatically output elements from the
> `accumulator` to make it incremental (and has the added benefit that it would be
> able to run depth-first).  Adding an additional argument, a downstream handle,
> to `accumulator` and `finisher` allows us to push elements downstream both for
> each input, and at the end of stream. As there exists no suitable pre-existing
> interface, we'll define a new interface named `Integrator` and rename `accumulator`
> to the more fitting `integrator`.
> Our `finisher` will also not have a useful return value, so we'll make it `void`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     interface Integrator<A,T,R> {
>         void integrate(A state, T element, Consumer<? super R> downstream);
>     }
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Consumer<? super> R> finisher();
> }
> ```
>
> Next, we need to tackle short-circuiting and add an upstream signal from each
> invocation of the `integrator` so we can detect when the integration does not
> want any more elements. We do this by returning a boolean from `integrate`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     interface Integrator<A,T,R> {
>         boolean integrate(A state, T element, Consumer<? super R> downstream);
>     }
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Consumer<? super> R> finisher();
> }
> ```
>
> Transitively supporting short-circuiting, i.e. that a downstream handle does
> not want to receive any more elements, requires us to make the same change as
> we did for `integrate`?return a `boolean` instead of `void`, and since the
> only built-in candidate would be `Predicate`, which is not supposed to have
> side-effects, let's introduce our own type `Sink`:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>     interface Sink<R> {
>         boolean flush(R element);
>     }
>     interface Integrator<A,T,R> {
>         boolean integrate(A state, T element, Sink<? super R> downstream);
>     }
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Sink<? super R>> finisher();
> }
> ```
>
> Finally, we need to address parallelism.  To opt-in to parallelism we can make
> the combiner optional -- we call it only for parallel executions, and if it is
> not present, execution is constrained to sequential.
>
> To demonstrate how all of the above fits together, we implement `fixedWindow(N)`
> where `fixedWindow(2)` over the values `[1,2,3,4,5]` yields `[[1,2],[3,4],[5]]`.
>
> ```java
>     /**
>      * Gathers elements into fixed-size windows. The last window can contain fewer elements.
>      * @param windowSize the size of the windows
>      * @return a new gatherer which gathers elements into fixed-size windows
>      * @param <T> the type of elements this Gatherer gathers
>      */
>     public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
>         if (windowSize < 1)
>             throw new IllegalArgumentException("'windowSize' must be greater than zero");
>         else {
>             Supplier<ArrayList<T>> supplier =
>                 () ->  new ArrayList<T>(windowSize);
>
>             Integrator<ArrayList<T>, T, List<T>> integrator =
>                 (openWindow, element, downstream) -> {
>                     if (openWindow.add(element) && openWindow.size() >= windowSize) {
>                         var closedWindow = List.copyOf(openWindow);
>                         openWindow.clear();
>                         return downstream.flush(closedWindow);
>                     } else
>                         return true;
>                 };
>
>             // This combiner signals that we opt-out of parallelisation
>             BinaryOperator<ArrayList<T>> combiner =
>                 Gatherer.unsupportedCombiner();
>
>             BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher =
>                 (openWindow, downstream) -> {
>                     if(!openWindow.isEmpty()) {
>                         downstream.flush(List.copyOf(openWindow));
>                         openWindow.clear();
>                     }
>                 };
>
>             return Gatherer.of(supplier, integrator, combiner, finisher);
>         }
>     }
> ```
>
> Or by implementing the `Gatherer` interface directly like so:
>
> ```java
>     /**
>      * Gathers elements into fixed-size windows. The last window can contain fewer elements.
>      * @param windowSize the size of the windows
>      * @return a new gatherer which gathers elements into fixed-size windows
>      * @param <T> the type of elements this Gatherer gathers
>      */
>     public static <T> Gatherer<T, ?, List<T>> fixedWindow(int windowSize) {
>         if (windowSize < 1)
>             throw new IllegalArgumentException("'windowSize' must be greater than zero");
>
>         class FixedWindowGatherer implements Gatherer<T,ArrayList<T>,List<T>> {
>             @Override
>             public Supplier<ArrayList<T>> initializer() {
>                 return () -> new ArrayList<>(windowSize);
>             }
>
>             @Override
>             public Integrator<ArrayList<T>, T, List<T>> integrator() {
>                 return (openWindow, element, downstream) -> {
>                     if (openWindow.add(element) && openWindow.size() >= windowSize) {
>                         var closedWindow = List.copyOf(openWindow);
>                         openWindow.clear();
>                         return downstream.flush(closedWindow);
>                     } else
>                         return true;
>                 };
>             }
>
>             @Override
>             public BinaryOperator<ArrayList<T>> combiner() {
>                 return Gatherer.unsupportedCombiner();
>             }
>
>             @Override
>             public BiConsumer<ArrayList<T>, Sink<? super List<T>>> finisher() {
>                 return (openWindow, downstream) -> {
>                     if(!openWindow.isEmpty()) {
>                         downstream.flush(List.copyOf(openWindow));
>                         openWindow.clear();
>                     }
>                 };
>             }
>         }
>         return new FixedWindowGatherer();
>     }
> ```
>
> Compared to Collector, it would look like the following:
>
> | Ordinal | Feature                  | `Collector<T,A,R>`                | `Gatherer<T,A,R>`                     |
> |---------|--------------------------|-----------------------------------|---------------------------------------|
> |    1    | Beginning-of-stream hook | `A supply()`                      | `A supply()`                          |
> |    2    | Per element              | `void accept(A, T)`               | `boolean integrate(A, T, Sink<R>)`    |
> |    3    | End-of-stream hook       | `R apply(A)`                      | `void accept(A, Sink<R>)`             |
> |    4    | Parallelizability        | `A apply(A, A)`                   | `A apply(A, A)`                       |
>
> To integrate it with `java.util.stream.Stream` we add the following method to
> it: `Stream<R> gather(Gatherer<T,?,R> gatherer)`
>
> Now we can use our `fixedWindow` Gatherer:
>
> ```java
> jshell> Stream.iterate(0, i -> i + 1).limit(10).gather(fixedWindow(2)).toList();
> $1 ==> [[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]]
> ```
>
> Gatherer now provides all features:
>
> | Ordinal | Feature                  | Using Gatherer          | Explanation                                                                            |
> |---------|--------------------------|-------------------------|----------------------------------------------------------------------------------------|
> |    1    | Intermediate operation   | Yes                     | A Gatherer's output is the following operation's input                                 |
> |    2    | Incremental operation    | Yes                     | A Gatherer can produce elements in response to consuming elements                      |
> |    3    | Stateful operation       | Yes                     | A Gatherer supplies its own state, which can be Void/null if stateless                 |
> |    4    | N:M inputs-to-outputs    | Yes                     | A Gatherer can consume and produce any number of elements                              |
> |    5    | Prefix consumption       | Yes                     | A Gatherer can signal that it is done by returning `false` from its `integrate`-method |
> |    6    | Beginning-of-stream hook | Yes                     | A Gatherer can run logic when creating its initial state                               |
> |    7    | End-of-stream hook       | Yes                     | A Gatherer's `finisher` is invoked at the end of input                                 |
> |    8    | Opt-in parallelizability | Yes                     | A Gatherer's `combiner` is optional                                                    |
>
> ## Summary
>
> None of the current candidates for a user-extensible API for generic
> intermediate stream operations fit the set of requirements, but `Collector`
> can form an excellent basis for a new construct, called `Gatherer`,
> which after a limited set of modifications checks all the boxes:
>
> | Ordinal | Feature                  | Using Stream.map(?)       | Using Stream.flatMap(?)   | Using Collector | Using Gatherer |
> |---------|--------------------------|---------------------------|---------------------------|-----------------|----------------|
> |    1    | Intermediate operation   | Yes                       | Yes                       | No, terminal    | Yes            |
> |    2    | Incremental operation    | Yes                       | Yes                       | No, terminal    | Yes            |
> |    3    | Stateful operation       | Yes, via class or capture | Yes, via class or capture | Yes             | Yes            |
> |    4    | N:M inputs-to-outputs    | No, 1:1                   | No, 1:M                   | No, N:1         | Yes            |
> |    5    | Prefix consumption       | No                        | No                        | No              | Yes            |
> |    6    | Beginning-of-stream hook | No                        | No                        | Yes             | Yes            |
> |    7    | End-of-stream hook       | No                        | No                        | Yes             | Yes            |
> |    8    | Opt-in parallelizability | No, always on             | No, always on             | No, always on   | Yes            |
>
> As it turned out, we were a short hop away from a generic, stand-alone,
> reusable, parallelizable, API for intermediate operations all along!
>
> ## But wait ? there's more
>
> While the aforementioned solution contains the bare-minimum to meet our requirements,
> the following will provide some significant quality-of-life improvements.
>
> ### Compositionality
>
> The astute reader may have noticed that by adding the `gather(Gatherer)`-method on `Stream`,
> one can in-effect **compose** `Gatherer`s together:
>
> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Stream<Long> stream = Stream.of(1).gather(someGatherer).gather(someOtherGatherer);
> ```
>
> As it turns out, it is possible to define a `default Gatherer andThen(Gatherer)`-method on `Gatherer` which composes `Gatherer`s:
>
> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Gatherer<Integer,?,Long> gatherer = someGatherer.andThen(someOtherGatherer);
> ```
>
> This makes it possible to both de-couple operations from their use-sites,
> as well as create more sophisticated `Gatherer`s from simple ones.
>
> But that's not all?by introducing a `default Collector collect(Collector)`-method
> it is also possible to compose a `Gatherer` with a `Collector`,
> and the result is another `Collector`:
>
> ```java
> Gatherer<Integer,?,String> someGatherer = ?;
> Gatherer<String,?,Long> someOtherGatherer = ?;
> Collector<Long,?,List<Long>> someGatherer.andThen(someOtherGatherer).collect(Collectors.toList());
> ```
>
> All of this together, it is now possible to build `Stream`-processing:
> "source-to-destination" using `Stream.gather(?).gather(?).gather(?)`;
> "intermediaries-first" using `gatherer.andThen(?).andThen(?);` and,
> "destination-to-source" using `gatherer.collect(otherGatherer.collect(?))`.
>
> ### Familiarity
>
> Since `Gatherer` is an evolution of `Collector` there's a clear on-ramp
> for any and all Java developers who are already familiar with `Collector`.
>
> ### Reusability
>
> `Gatherer`s, by virtue of being stand-alone, reusable, intermediaries,
> paired with compositionality and opt-in parallelization, allows for transformations
> to be created once and maintained in a single place, no matter if it is going to be
> used as a `Collector`, a `Gatherer`, or a `Stream`.
>
> ### Optimizability
>
> `Collector` has the notion of `Characteristics`, a `Set` of flags which describes them.
> This information can then be used by the underlying machinery which uses them
> to optimize their evaluation. The same approach can be used for `Gatherer`s.
>
> ### Summary 2.0
>
> Taking all of the above into consideration, we end up with a definition like the following:
>
> ```java
> /** @param <T> the element type
>  *  @param <A> the (mutable) intermediate accumulation type
>  *  @param <R> the (probably immutable) final accumulation type
>  */
> interface Gatherer<T,A,R> {
>
>     interface Sink<R> {
>         boolean flush(R element);
>     }
>
>     interface Integrator<A,T,R> {
>         boolean integrate(A state, T element, Sink<? super R> downstream);
>     }
>
>     enum Characteristics {
>         GREEDY,          // Never short-circuits
>         SIZE_PRESERVING, // Emits exactly once per input element
>         STATELESS;       // No need to initialize or combine state
>     }
>
>     Supplier<A> supplier();
>     Integrator<A, T, R> integrator();
>     BinaryOperator<A> combiner();
>     BiConsumer<A, Sink<? super R>> finisher();
>     Set<Characteristics> characteristics();
>
>     default <AA, RR> Gatherer<T,?,RR> andThen(Gatherer<R,AA,RR> that) {
>         // Gatherers is analoguous to Collectors
>         return Gatherers.Composite.of(this, that);
>     }
>
>     default <RR> Collector<T,?,RR> collect(Collector<R, ?, RR> collector) {
>         // Gatherers is analoguous to Collectors
>         return Gatherers.GathererCollector.of(this, collector);
>     }
> }
> ```
>
> ## Appetizers
>
> The following examples showcase how `Gatherer` can be used to implement a diverse set
> of pre-existing, and future, intermediate operations for `Stream`s.
>
> ### How to implement `map(mapper)`
>
> ```java
> public final static <T,R> Gatherer<T, ?, R> map(Function<? super T, ? extends R> mapper) {
>     return Gatherer.of(
>         () -> (Void)null,
>         (nothing, element, downstream) ->
>             downstream.flush(mapper.apply(element)),
>         (l,r) -> l,
>         (nothing, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(map(i -> i + 1)).toList()
> $1 ==> [2, 3, 4, 5]
> ```
>
> ### How to implement `flatMap(mapper)`
>
> ```java
> public final static <T,R> Gatherer<T, ?, R> flatMap(Function<? super T, ? extends Stream<R>> mapper) {
>     return Gatherer.of(
>         () -> (Void)null,
>         (nothing, element, downstream) -> {
>             try(Stream<? extends R> s = mapper.apply(element)) {
>                 return s == null || s.sequential().allMatch(downstream::flush);
>             }
>         },
>         (l,r) -> l,
>         (nothing, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(flatMap(i -> Stream.of(i + 1))).toList()
> $1 ==> [2, 3, 4, 5]
> ```
>
> ### How to implement `takeWhile(predicate)`
>
> ```java
> public final static <T> Gatherer<T, ?, T> takeWhile(Predicate<? super T> predicate) {
>     return Gatherer.of(
>         () -> (Void)null,
>         (nothing, element, downstream) ->
>             predicate.test(element) && downstream.flush(element),
>         (l, r) -> l,
>         (nothing, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(takeWhile(i -> i < 3)).toList()
> $1 ==> [1, 2]
> ```
>
> ### How to implement `limit(N)`
>
> ```java
> public static <M> Gatherer<M, ?, M> limit(long limit) {
>     if (limit < 0)
>         throw new IllegalArgumentException("'limit' has to be non-negative");
>
>     class At { long n = 0; }
>     return Gatherer.of(
>             At::new,
>             (at, element, downstream) ->
>                 at.n < limit && downstream.flush(element) && ++at.n < limit,
>             Gatherer.unsupportedCombiner(),
>             (at, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(limit(2)).toList()
> $1 ==> [1, 2]
> ```
>
> ### How to implement prefix `scanLeft`
>
> ```java
> public static <T,R> Gatherer<T,?,R> scanLeft(R initial, BiFunction<R,T,R> scanner) {
>     class State { R current = initial; }
>     return Gatherer.of(
>             State::new,
>             (state, element, downstream) ->
>                 downstream.flush(state.current = scanner.apply(state.current, element)),
>             Gatherer.unsupportedCombiner(),
>             (state, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(scanLeft("'", (acc, elem) -> acc + elem + "'")).toList()
> $1 ==> ['1', '1'2', '1'2'3', '1'2'3'4']
> ```
>
> ### How to implement `fold(initial, folder)`
>
> ```java
> public static <T> Gatherer<T,?,T> fold(T initial, BinaryOperator<T> folder) {
>     class State { T current = initial; }
>     return Gatherer.of(
>         State::new,
>         (state, element, downstream) -> {
>             state.current = folder.apply(state.current, element);
>             return true;
>         },
>         (l, r) -> {
>             l.current = folder.apply(l.current, r.current);
>             return l;
>         },
>         (state, downstream) -> downstream.flush(state.current)
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(fold(0, (acc, elem) -> acc + elem)).toList()
> $1 ==> [10]
> ```
>
> ### How to implement `foldLeft(initial, folder)`
>
> ```java
> public static <T,R> Gatherer<T,?,R> foldLeft(R initial, BiFunction<R,T,R> folder) {
>     class State { R current = initial; }
>     return Gatherer.of(
>         State::new,
>         (state, element, downstream) -> {
>             state.current = folder.apply(state.current, element);
>             return true;
>         },
>         Gatherer.unsupportedCombiner(),
>         (state, downstream) -> downstream.flush(state.current)
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,3,4).gather(foldLeft(0L, (acc, elem) -> acc + elem)).toList()
> $1 ==> [10]
> ```
>
> ### How to implement `deduplicateAdjacent()`
>
> ```java
> public static <T> Gatherer<T,?,T> deduplicateAdjacent() {
>     class State { T prev; boolean hasPrev; }
>     return Gatherer.of(
>         State::new,
>         (state, element, downstream) -> {
>             if (!state.hasPrev) {
>                 state.hasPrev = true;
>                 state.prev = element;
>                 return downstream.flush(element);
>             } else if (!Objects.equals(state.prev, element)) {
>                 state.prev = element;
>                 return downstream.flush(element);
>             } else {
>                 return true; // skip duplicate
>             }
>         },
>         Gatherer.unsupportedCombiner(),
>         (state, downstream) -> {}
>     );
> }
> ```
>
> ```java
> jshell> Stream.of(1,2,2,3,2,4).gather(deduplicateAdjacent()).toList()
> $1 ==> [1, 2, 3, 2, 4]
> ```
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/98d50942/attachment-0001.htm>

From stsypanov at openjdk.org  Thu Jun 29 10:10:53 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 29 Jun 2023 10:10:53 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>
Message-ID: <XM0KGQy4UjkPbdXTCg1ij0awIv4TDSMWa51Fuub4wnc=.d8b68f8b-0842-44b4-a405-10394b501451@github.com>

On Wed, 28 Jun 2023 20:02:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Double-checked locking should rely on local variable to avoid racy reads from volatile field.
>
> Looks ok; was this a tool detected race?

@RogerRiggs no tool, just fell into the sources while debugging my application

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1612772226

From coleenp at openjdk.org  Thu Jun 29 12:03:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:03:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Why do we care about this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234

From forax at univ-mlv.fr  Thu Jun 29 12:13:53 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 29 Jun 2023 14:13:53 +0200 (CEST)
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <MW4PR10MB5774FEB66809009BCA5FD914FF25A@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1265852641.92738200.1688025826687.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774FEB66809009BCA5FD914FF25A@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <1268634283.92998237.1688040833988.JavaMail.zimbra@univ-eiffel.fr>

> From: "Viktor Klang" <viktor.klang at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Thursday, June 29, 2023 11:09:22 AM
> Subject: Re: java.util.stream.Stream: API for user-extensible intermediate
> operations

> From: Remi Forax <forax at univ-mlv.fr>
> Sent: Thursday, 29 June 2023 10:03
> To: Viktor Klang <viktor.klang at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.org>
> Subject: [External] : Re: java.util.stream.Stream: API for user-extensible
> intermediate operations

>> From: "Viktor Klang" <viktor.klang at oracle.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Tuesday, June 27, 2023 7:10:42 PM
>> Subject: java.util.stream.Stream: API for user-extensible intermediate
>> operations

>> Hi core-libs-dev,

>> Over the past 6+ months I've been thinking about, and tinkering with, how we'd
>> be able to expose a user-facing API for extensible intermediate
>> java.util.stream.Stream operations?a feature envisioned all the way back when
>> Streams were created.

>> I'm now at a point where I have a viable design and implementation, and so I'm
>> turning to you for your feedback: on the direction taken; the API concepts;
>> and, in particular, is there anything which I have overlooked/missed?

>>I think this API is overly generic and hard to reason about it, for users and
> >IDEs.

> The API is for all intents and purposes Collector with a boolean return type for
> the accumulator and an added downstream handle parameter added to the
> accumulator and the finisher.

>>The main issue is that the same API is used for both stateless and stateful
>>operations, which means that as a user, we have no idea if a call to
> >stream.gather() is stateful or not.

> How is this different from any of the other pre-existing Stream operations?

Most of the operation are stateless, only a handful of well known operations are stateful, all other stateful operations are done by collectors. 
But stream.gather() allows both stateless and stateful gatherer. 
I believe that instead of having an intermediary operation that can be stateless or stateful, it's better to have a Collector that starts a new stream. 

Instead of 
stream.gather(Gatherers.foo()) 

A collector/gatherer can propagate the elements into a new stream 
stream.collect(Gatherers.foo(stream -> ...)) 
or 
stream.collect(Gatherers.foo(), stream -> ...) 

This allows a better control on the parallelization (both streams are independant) and a clear path to retrofit the Collectors as Gatherers (instead of having two too similar APIs side by side). 

>>Which is a departure from the current API that cleanly separate stateless and
>>staful operations. Here, we are left in the dark. In a sense, this API is too
> >powerful, it can do too much thing, so as a user we can not reason about it.

> A Gatherer encodes it input and output types, in what sense would that not be
> enough to reason about it ?

The initial idea of the API is to have almost all intermediary operations to be stateless so by default, we know that the complexity of the stream is linear, it will parallelize quite well, etc. 
Once you have an intermediary operation like a gatherer, all this "good" property are null and void. 

>>I like the idea of a Collector 2.0 i.e. using the Gatherer API at the end of the
>>stream (not in the middle), but currently, the Gatherer API is not a Collector,
>>so we now have two different APIs for doing partially the same job. I wonder if
>>the Collector API can be retroffitted to act as a Gatherer API, avoiding to
>>have to choose which one to use, a gatherer being the equivalent of a
> >"flat-collector" + short-circuit.

> Collector serves a very important role of being able to get information out of a
> Stream and deliver that information in a certain shape, a Gatherer does not
> provide any facility for this.

A collector can get information out of a Stream into a new one , at that point you have something quite similar to a Gatherer. 

>>The idea of unsupportedCombiner() seems out of place, like a patch to be able to
>>clobble different things together. I'm not sure to understand why it's needed
> >for a Gatherer, and why it is not needed for Collectors ?

> Nothing prevents us from treating a `null` combiner the same way. My primary
> reason for making it a dedicated thing was to be able to differentiate a
> possible bug (user passing in a null reference inadvertently) from explicitly
> stating that a combiner does not exist from this operation.

> unsupportedCombiner() as an artifact can be completely hidden if desired, as
> Gatherer.of() can have permutations without specifying a combiner, and the
> default method of Gatherer.combiner() could return unsupportedCombiner() . I
> opted not to do this initially, because I felt like being explicit about not
> having a combiner means that it is a concious decision by the implementor of
> the Gatherer.

My question is more, why do we need this unsupportedCombiner on a Gatherer and not on a Collector ? 

>>So I would prefer that API to extends the current Collector API but not the
> >intermediary operations. Yes, it's less powerful.
> It means that instead of using one stream with a collect like operation in the
> middle, users will have to use two streams, one after the other, but it makes
> the code easier to understand (also having two streams give users better
> control on which part should be in parallel).

> That would be something completely different from the goal of providing
> user-extensible intermediate operations, which is something which this proposal
> is explicitly trying to address.

User-extensible intermediate operations or a gatherer as a better collector have similar semantics, so it's not a completely different. 

> Cheers,
> ?

regards, 
R?mi 

> >R?mi

>> (If you, like myself, prefer reading pre-rendered markdown, [
>> https://cr.openjdk.org/~vklang/Gatherers.html |
>> click here ] )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/a9853a4a/attachment-0001.htm>

From dholmes at openjdk.org  Thu Jun 29 12:14:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:14:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398

From dholmes at openjdk.org  Thu Jun 29 12:21:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:21:55 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <9CkadtQawvo0NV_vgNtYSNRXiKak6vr9NgGMejHnjzs=.1ece2c0e-63ce-4008-975d-183f15aeb710@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

I don't see any race here. The addition of the local serves no purpose AFAICS - we don't even save any volatile reads.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1613058223

From rgiulietti at openjdk.org  Thu Jun 29 12:27:54 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 29 Jun 2023 12:27:54 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <3Df73YJmudWZSS5ZVu7Ty5MpVuVj49z30FTQwfntADY=.2d5354c4-0d0a-4c83-a938-9f8f1fb83500@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

The role of the local `keySet` seems pretty useless. It doesn't save neither volatile reads nor writes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1613067347

From duke at openjdk.org  Thu Jun 29 12:27:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 29 Jun 2023 12:27:55 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <XM0KGQy4UjkPbdXTCg1ij0awIv4TDSMWa51Fuub4wnc=.d8b68f8b-0842-44b4-a405-10394b501451@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <1zA3pC1c0MINzje9OrP7pTcuM8td7-iS63LFMa-eXhQ=.8e58fbab-739e-4359-adc0-9e9de96dc0ab@github.com>
 <XM0KGQy4UjkPbdXTCg1ij0awIv4TDSMWa51Fuub4wnc=.d8b68f8b-0842-44b4-a405-10394b501451@github.com>
Message-ID: <iK0qc3U5ZqTX1eDPzJe_YvQqiOtwfRttf0ZgZIIpgy4=.83179d33-0083-48b5-94f8-e482fb9b9ddc@github.com>

On Thu, 29 Jun 2023 10:08:27 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Looks ok; was this a tool detected race?
>
> @RogerRiggs no tool, just fell into the sources while debugging my application

@stsypanov I don't see that there's any issue with the existing code as the volatile field is only written at most once as guarded by the synchronized-block. Best case this patch avoids an extra volatile read (presuming it isn't optimized away).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1613070489

From duke at openjdk.org  Thu Jun 29 12:35:58 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 29 Jun 2023 12:35:58 GMT
Subject: RFR: JDK-8308047
 java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java timed
 out and also had jcmd pipe errors [v2]
In-Reply-To: <pEn4o8BSl7LHk8ksVIT6V1RqPJhOW0TD70_406vuPus=.c9ed5157-7daf-436e-8e1f-e40f1eb7ff6b@github.com>
References: <A78syunWbbBQydnm8O4Cs_AN3opsYHltF-Du1zhoBu8=.aaaf8328-7583-4f38-acb6-3202898808d7@github.com>
 <uIyUn6KFpnNm8zAO4CEV86oCubAjaShUfogpA3RhhZA=.efb1a4d9-1243-41e1-9858-9ef76c3b2c27@github.com>
 <pEn4o8BSl7LHk8ksVIT6V1RqPJhOW0TD70_406vuPus=.c9ed5157-7daf-436e-8e1f-e40f1eb7ff6b@github.com>
Message-ID: <lb6dSONsg_q4CBlkWP7Vr5j2zddM4-AkYwuNRzrqlkc=.849b102b-0b46-46f3-897c-fc07abf85432@github.com>

On Fri, 9 Jun 2023 16:53:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decresing the number of iterations proportional to the increase in the max memory size
>
> This looks okay to me and I assume it tested on with all GCs/configurations. If it comes back then maybe an alternative way to test this would be a timed loop of submit+task. If the cancel policy isn't working then it would throw OOME very quickly with a 64Mb heap.

@AlanBateman Let me know if you're able to sponsor this one ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14389#issuecomment-1613089748

From liach at openjdk.org  Thu Jun 29 12:36:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 12:36:04 GMT
Subject: Integrated: 8310848: Convert ClassDesc and MethodTypeDesc to be stored
 in static final fields
In-Reply-To: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
References: <lEu1EAd1znvgmBFXB1v7nyeV_jm8UnGEkJKIjCf---Y=.dba6dea8-ad89-46f9-95c6-98e80e3b5629@github.com>
Message-ID: <CKTHgwyK_hpXlkZRSYRQTfaX1I1T4ud6_ycRjukjzMQ=.cd602e71-4a1c-48d0-9bbc-4041a03cfed0@github.com>

On Sun, 25 Jun 2023 02:57:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> This would encourage Classfile API users to use the descriptors as constants, which can improve performance by avoiding repeated validation and reusing cached descriptor strings for MethodTypeDesc. This patch updates usages in the main codebase and benchmarks; tests are left untouched.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000378.html

This pull request has now been integrated.

Changeset: 07734f6d
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07734f6dde2b29574b6ef98eeb9e007d8801a3ea
Stats:     131 lines in 6 files changed: 39 ins; 19 del; 73 mod

8310848: Convert ClassDesc and MethodTypeDesc to be stored in static final fields

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/14640

From lkorinth at openjdk.org  Thu Jun 29 12:38:57 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 12:38:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
Message-ID: <vkPgWAbLJRXEPOQ0alkrWJ7Gv7jLDEF3ak1ipe9xxZw=.5b93f57d-7ddb-42fb-b41b-76f4e3193d78@github.com>

On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Why do we care about this?

I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me.

And it does not look good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390

From coleenp at openjdk.org  Thu Jun 29 12:42:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:42:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

You could fix your emacs functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245

From lkorinth at openjdk.org  Thu Jun 29 13:08:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 13:08:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
Message-ID: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>

On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

My changes look like this in the diff output

 }
-

Removal of the last newline would look like this:

-}
+}
\ No newline at end of file

(both with `git diff` and `git diff --unified`) 

I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641

From brian.goetz at oracle.com  Thu Jun 29 13:11:51 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 29 Jun 2023 09:11:51 -0400
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <1268634283.92998237.1688040833988.JavaMail.zimbra@univ-eiffel.fr>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1265852641.92738200.1688025826687.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774FEB66809009BCA5FD914FF25A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1268634283.92998237.1688040833988.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <260b958d-cde2-a9f0-13eb-fd15f722f223@oracle.com>

Please be mindful of the request Viktor made: for feedback on the 
approach and the API concepts.? It should be pretty clear that low-level 
details like "unsupportedCombiner" are many levels down below "approach 
and concepts".? (And, you know the rule: when you bikeshed on a 
low-level detail when asked for high-level comments, you've forfeited 
the right to have further opinions about the concepts.)

In any case, I think your high-level comments seem to be: you prefer a 
direction where, rather than creating new possibly-stateful, 
possibly-not-parallel ops, instead beef up Collector and let people 
start a new stream.

On 6/29/2023 8:13 AM, forax at univ-mlv.fr wrote:
>
>
>     >The idea of unsupportedCombiner() seems out of place, like a
>     patch to be able to clobble different things together. I'm not
>     sure to understand why it's needed for a Gatherer, and why it is
>     not needed for Collectors ?
>
>     Nothing prevents us from treating a `null` combiner the same way.
>     My primary reason for making it a dedicated thing was to be able
>     to differentiate a possible bug (user passing in a null reference
>     inadvertently) from explicitly stating that a combiner does not
>     exist from this operation.
>
>     /unsupportedCombiner()/ as an artifact can be completely hidden if
>     desired, as /Gatherer.of()/ can have permutations without
>     specifying a combiner, and the /default method/ of
>     Gatherer.combiner() could return /unsupportedCombiner()/. I opted
>     not to do this initially, because I felt like being explicit about
>     not having a combiner means that it is a concious decision by the
>     implementor of the Gatherer.
>
>
> My question is more, why do we need this unsupportedCombiner on a 
> Gatherer and not on a Collector ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/0b4fa00f/attachment.htm>

From duke at openjdk.org  Thu Jun 29 13:13:33 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 13:13:33 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v33]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <A18WpCO_Pj9qsF5NSJVv8oTltdVkicPfopFXvmEgVEM=.2c31cb52-91af-46e1-aaf9-8903a515c939@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with one additional commit since the last revision:

  code format & comments add endianness

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/93e74b6c..d8ee124e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=31-32

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From liach at openjdk.org  Thu Jun 29 13:14:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 13:14:57 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type)
Message-ID: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>

`LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.

See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.

This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.

-------------

Commit messages:
 - oops, CorpusTest used this internal API
 - Remove implementation detail writeTo from LocalVariable(Type)

Changes: https://git.openjdk.org/jdk/pull/14705/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311085
  Stats: 90 lines in 6 files changed: 37 ins; 49 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14705/head:pull/14705

PR: https://git.openjdk.org/jdk/pull/14705

From liach at openjdk.org  Thu Jun 29 13:15:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 13:15:11 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries
Message-ID: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>

5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).

This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.

This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html

-------------

Commit messages:
 - Add typeSymbol API for a few constant pool entries

Changes: https://git.openjdk.org/jdk/pull/14706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311084
  Stats: 46 lines in 7 files changed: 44 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14706/head:pull/14706

PR: https://git.openjdk.org/jdk/pull/14706

From dfuchs at openjdk.org  Thu Jun 29 13:17:59 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 29 Jun 2023 13:17:59 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <CBJBV1pHp_p1jvuPhoQfC9_Cdx3CzBKdMOyWsS9_31I=.45795ee2-9937-40c6-876f-440865ede9b9@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

The new code makes it more visible that 1. keySet is expected to be volatile and 2. that there is no path were code could be reordered leading to the 'wrong' value of keySet being returned. So maybe there's no race, but the new code make it more obvious.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1613165837

From jiefu at openjdk.org  Thu Jun 29 13:20:15 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 29 Jun 2023 13:20:15 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v33]
In-Reply-To: <A18WpCO_Pj9qsF5NSJVv8oTltdVkicPfopFXvmEgVEM=.2c31cb52-91af-46e1-aaf9-8903a515c939@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <A18WpCO_Pj9qsF5NSJVv8oTltdVkicPfopFXvmEgVEM=.2c31cb52-91af-46e1-aaf9-8903a515c939@github.com>
Message-ID: <zDHu06n6y44aqkJzVXj4QjHuSHp-qAXHPpSTstOY9Lc=.29124d22-7967-48f8-aa72-edc0173eeb96@github.com>

On Thu, 29 Jun 2023 13:13:33 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code format & comments add endianness

src/java.base/share/classes/java/util/HexDigits.java line 106:

> 104: 
> 105:     /**
> 106:      * Combine two hex shorts into a int based on BigEndian

'a int' --> 'an int' ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1246607599

From viktor.klang at oracle.com  Thu Jun 29 13:24:59 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 29 Jun 2023 13:24:59 +0000
Subject: java.util.stream.Stream: API for user-extensible intermediate
 operations
In-Reply-To: <1268634283.92998237.1688040833988.JavaMail.zimbra@univ-eiffel.fr>
References: <MW4PR10MB57743AC55FB89F5AFC98A168FF27A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1265852641.92738200.1688025826687.JavaMail.zimbra@univ-eiffel.fr>
 <MW4PR10MB5774FEB66809009BCA5FD914FF25A@MW4PR10MB5774.namprd10.prod.outlook.com>
 <1268634283.92998237.1688040833988.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <MW4PR10MB577498CB9D9BF804306A3335FF25A@MW4PR10MB5774.namprd10.prod.outlook.com>



Over the past 6+ months I've been thinking about, and tinkering with, how we'd be able to expose a user-facing API for extensible intermediate java.util.stream.Stream operations?a feature envisioned all the way back when Streams were created.

I'm now at a point where I have a viable design and implementation, and so I'm turning to you for your feedback: on the direction taken; the API concepts; and, in particular, is there anything which I have overlooked/missed?

>I think this API is overly generic and hard to reason about it, for users and IDEs.

The API is for all intents and purposes Collector with a boolean return type for the accumulator and an added downstream handle parameter added to the accumulator and the finisher.

>The main issue is that the same API is used for both stateless and stateful operations, which means that as a user, we have no idea if a call to stream.gather() is stateful or not.

How is this different from any of the other pre-existing Stream operations?

Most of the operation are stateless, only a handful of well known operations are stateful, all other stateful operations are done by collectors.
But stream.gather() allows both stateless and stateful gatherer.
I believe that instead of having an intermediary operation that can be stateless or stateful, it's better to have a Collector that starts a new stream.

Instead of
  stream.gather(Gatherers.foo())

A collector/gatherer can propagate the elements into a new stream
  stream.collect(Gatherers.foo(stream -> ...))
 or
  stream.collect(Gatherers.foo(), stream -> ...)

This allows a better control on the parallelization (both streams are independant) and a clear path to retrofit the Collectors as Gatherers (instead of having two too similar APIs side by side).

There is no difference in how parallelization would be possible to occur?parallel Stream already runs multi-stage parallel evaluation when stateful stages exist in the same pipeline.



>Which is a departure from the current API that cleanly separate stateless and staful operations. Here, we are left in the dark. In a sense, this API is too powerful, it can do too much thing, so as a user we can not reason about it.

A Gatherer encodes it input and output types, in what sense would that not be enough to reason about it ?

The initial idea of the API is to have almost all intermediary operations to be stateless so by default, we know that the complexity of the stream is linear,  it will parallelize quite well, etc.
Once you have an intermediary operation like a gatherer, all this "good" property are null and void.

There are quite a few stateful operations on streams since a long time?the slicing operations, the distinct operations, the sorting operations, the limit operation, the while-operations etc. My bet is that most developers using streams will not know from a glance which ones of those are to be considered stateful and has an impact on evaluation?and personally I think that is a great thing, as it is an implementation detail.



>I like the idea of a Collector 2.0 i.e. using the Gatherer API at the end of the stream (not in the middle), but currently, the Gatherer API is not a Collector, so we now have two different APIs for doing partially the same job. I wonder if the Collector API can be retroffitted to act as a Gatherer API, avoiding to have to choose which one to use, a gatherer being the equivalent of a "flat-collector" + short-circuit.

Collector serves a very important role of being able to get information out of a Stream and deliver that information in a certain shape, a Gatherer does not provide any facility for this.
A collector can get information out of a Stream into a new one, at that point you have something quite similar to a Gatherer.
It sounds like you're describing Gatherer?it's a Collector like construct which can output into a new stream.


>The idea of unsupportedCombiner() seems out of place, like a patch to be able to clobble different things together. I'm not sure to understand why it's needed for a Gatherer, and why it is not needed for Collectors ?

Nothing prevents us from treating a `null` combiner the same way. My primary reason for making it a dedicated thing was to be able to differentiate a possible bug (user passing in a null reference inadvertently) from explicitly stating that a combiner does not exist from this operation.

unsupportedCombiner() as an artifact can be completely hidden if desired, as Gatherer.of() can have permutations without specifying a combiner, and the default method of Gatherer.combiner() could return unsupportedCombiner(). I opted not to do this initially, because I felt like being explicit about not having a combiner means that it is a concious decision by the implementor of the Gatherer.
My question is more, why do we need this unsupportedCombiner on a Gatherer and not on a Collector ?
We can definitely investigate adding that to Collector as well, but it is outside of the scope of this proposal as it deals with intermediate, not terminal, operations.



>So I would prefer that API to extends the current Collector API but not the intermediary operations. Yes, it's less powerful.
It means that instead of using one stream with a collect like operation in the middle, users will have to use two streams, one after the other, but it makes the code easier to understand (also having two streams give users better control on which part should be in parallel).

That would be something completely different from the goal of providing user-extensible intermediate operations, which is something which this proposal is explicitly trying to address.
User-extensible intermediate operations or a gatherer as a better collector have similar semantics, so it's not a completely different.
The difference in semantics between Gatherer and Collector is outlined in the initial post of this document. With that said, I think your position has been made clear?you prefer augmenting the terminal operation rather than introducing an intermediate operation.

Cheers,
?

regards,
R?mi

>R?mi


(If you, like myself, prefer reading pre-rendered markdown, click here<https://cr.openjdk.org/~vklang/Gatherers.html>)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/2145281e/attachment-0001.htm>

From duke at openjdk.org  Thu Jun 29 13:26:18 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 13:26:18 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

??? has updated the pull request incrementally with two additional commits since the last revision:

 - fix comments typo
 - Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14578/files
  - new: https://git.openjdk.org/jdk/pull/14578/files/d8ee124e..aea4e042

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14578&range=32-33

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14578.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14578/head:pull/14578

PR: https://git.openjdk.org/jdk/pull/14578

From briangoetz at openjdk.org  Thu Jun 29 13:28:57 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 29 Jun 2023 13:28:57 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries
In-Reply-To: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
References: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
Message-ID: <ndv_sZQLyovjkHrqKuDgMR8-jtjHaJO7vQmeudnl4Kw=.cb4a6810-bbcf-46f9-9ae6-017dc541d293@github.com>

On Thu, 29 Jun 2023 09:59:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
> 
> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
> 
> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html

Marked as reviewed by briangoetz (Reviewer).

src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantDynamicEntry.java line 49:

> 47:     default ClassDesc typeSymbol() {
> 48:         return Util.fieldTypeSymbol(nameAndType());
> 49:     }

Usage of Util::fieldTypeSymbol in asSymbol() can be replaced with typeSymbol()

src/java.base/share/classes/jdk/internal/classfile/constantpool/InvokeDynamicEntry.java line 46:

> 44:     default MethodTypeDesc typeSymbol() {
> 45:         return Util.methodTypeSymbol(nameAndType());
> 46:     }

Similar comment as with CondyEntry -- reduce usage of Util::methodTypeSymbol in this class

-------------

PR Review: https://git.openjdk.org/jdk/pull/14706#pullrequestreview-1505281261
PR Review Comment: https://git.openjdk.org/jdk/pull/14706#discussion_r1246610565
PR Review Comment: https://git.openjdk.org/jdk/pull/14706#discussion_r1246616224

From briangoetz at openjdk.org  Thu Jun 29 13:28:58 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 29 Jun 2023 13:28:58 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries
In-Reply-To: <ndv_sZQLyovjkHrqKuDgMR8-jtjHaJO7vQmeudnl4Kw=.cb4a6810-bbcf-46f9-9ae6-017dc541d293@github.com>
References: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
 <ndv_sZQLyovjkHrqKuDgMR8-jtjHaJO7vQmeudnl4Kw=.cb4a6810-bbcf-46f9-9ae6-017dc541d293@github.com>
Message-ID: <HMq24IZVFST-KXVfVWvs0WcK5j_WAXM0SvZkdwZL5s4=.6ab8d797-3e68-426c-9a3a-4c7f281f1c48@github.com>

On Thu, 29 Jun 2023 13:23:51 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
>> 
>> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
>> 
>> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html
>
> src/java.base/share/classes/jdk/internal/classfile/constantpool/InvokeDynamicEntry.java line 46:
> 
>> 44:     default MethodTypeDesc typeSymbol() {
>> 45:         return Util.methodTypeSymbol(nameAndType());
>> 46:     }
> 
> Similar comment as with CondyEntry -- reduce usage of Util::methodTypeSymbol in this class

(Would like to do the same in various ::count methods, but unfortunately MemberRefEntry is too general; would have to rejigger the various XxxRefEntry types.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14706#discussion_r1246619062

From duke at openjdk.org  Thu Jun 29 13:41:21 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 13:41:21 GMT
Subject: Integrated: JDK-8310502 : Optimization for j.l.Long.fastUUID()
In-Reply-To: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
Message-ID: <4skBYeScXfoQLGlKyRClcDqBRwoS9LuC70dDlNdHwww=.69b58fa3-6aea-427e-9b29-e3850a33f158@github.com>

On Wed, 21 Jun 2023 07:28:54 GMT, ??? <duke at openjdk.org> wrote:

> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
> 
> The following are the test results of JMH: 
> 
> Benchmark                     Mode  Cnt      Score      Error   Units
> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms

This pull request has now been integrated.

Changeset: 20f7d05e
Author:    shaojin.wensj <shaojin.wensj at alibaba-inc.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20f7d05ef238074143b01deb66a99217b2af47d8
Stats:     137 lines in 5 files changed: 94 ins; 41 del; 2 mod

8310502: Optimization for j.l.Long.fastUUID()

Reviewed-by: liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14578

From briangoetz at openjdk.org  Thu Jun 29 13:43:56 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Thu, 29 Jun 2023 13:43:56 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type)
In-Reply-To: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
Message-ID: <PWUfbQy8c9mvmxdMI1i8eMgyVhum3WFgM2A4VkC1X3A=.3cb86b9a-0619-4baa-8432-1113aa545232@github.com>

On Thu, 29 Jun 2023 09:59:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
> 
> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 280:

> 278:                             b.writeIndex(l.name());
> 279:                             b.writeIndex(l.type());
> 280:                             b.writeU2(l.slot());

This idiom is repeated four times; seems like it can be factored somewhere into a helper?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14705#discussion_r1246639165

From rriggs at openjdk.org  Thu Jun 29 13:49:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 13:49:24 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>
Message-ID: <khRV0W3WP67ls17pUpB3xH5oihM16kzV45W1r0wsqUA=.a96b4ba7-f98a-4bc0-b855-733ea14c91ec@github.com>

On Thu, 29 Jun 2023 13:26:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix comments typo
>  - Update full name

Changes requested by rriggs (Reviewer).

src/java.base/share/classes/java/util/HexDigits.java line 108:

> 106:      * Combine two hex shorts into one int based on big endian
> 107:      */
> 108:     static int digit(int b0, int b1) {

The method name `digit` is not very informative.
As it is package private it should be more descriptive and describe the parameters and result.
Perhaps `packDigits` or `encodeAndPackHexDigits`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14578#pullrequestreview-1505333183
PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1246644155

From alanb at openjdk.org  Thu Jun 29 13:49:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 13:49:25 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>
Message-ID: <Ac1aPsBCrf6ClW5UBBz2B7Czh495rAwgVSkbMUCxekY=.d5279a5f-59c1-45c3-9f34-3be6afcae9d6@github.com>

On Thu, 29 Jun 2023 13:26:18 GMT, ??? <duke at openjdk.org> wrote:

>> By optimizing the implementation of java.lang.Long#fastUUID, the performance of the java.util.UUID#toString method can be significantly improved.
>> 
>> The following are the test results of JMH: 
>> 
>> Benchmark                     Mode  Cnt      Score      Error   Units
>> UUIDUtilsBenchmark.new       thrpt    5  92676.550 ?  292.213  ops/ms
>> UUIDUtilsBenchmark.original  thrpt    5  37040.165 ? 1023.532  ops/ms
>
> ??? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix comments typo
>  - Update full name

@DamonFool  In the future, please wait at least 24 hours before sponsoring changes like this. There have been 33 revisions of this change, many of the people that have commented, potential reviewers are in many time zones and need to have time to see a chance to look at changes before they are integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1613211409

From liach at openjdk.org  Thu Jun 29 13:53:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 29 Jun 2023 13:53:54 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type)
In-Reply-To: <PWUfbQy8c9mvmxdMI1i8eMgyVhum3WFgM2A4VkC1X3A=.3cb86b9a-0619-4baa-8432-1113aa545232@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
 <PWUfbQy8c9mvmxdMI1i8eMgyVhum3WFgM2A4VkC1X3A=.3cb86b9a-0619-4baa-8432-1113aa545232@github.com>
Message-ID: <ShDVdF-ap2mtdiWkhmh3YNQ3kH7J2MgP4HrmZwXhHRM=.009712a8-4e19-4d20-a1f0-0c0a2d066e90@github.com>

On Thu, 29 Jun 2023 13:41:17 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
>> 
>> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 280:
> 
>> 278:                             b.writeIndex(l.name());
>> 279:                             b.writeIndex(l.type());
>> 280:                             b.writeU2(l.slot());
> 
> This idiom is repeated four times; seems like it can be factored somewhere into a helper?

Good idea. The same routine is used in attribute mapper for the two tables, which could be factored as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14705#discussion_r1246652541

From jiefu at openjdk.org  Thu Jun 29 13:55:19 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 29 Jun 2023 13:55:19 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <Ac1aPsBCrf6ClW5UBBz2B7Czh495rAwgVSkbMUCxekY=.d5279a5f-59c1-45c3-9f34-3be6afcae9d6@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>
 <Ac1aPsBCrf6ClW5UBBz2B7Czh495rAwgVSkbMUCxekY=.d5279a5f-59c1-45c3-9f34-3be6afcae9d6@github.com>
Message-ID: <sqqpR1iz-zPF0zwBy2cxR-b4Nf22_z2c8bgO8dDxgIA=.2d0f2dd8-9fd9-46a6-96ba-22fd7e8f15b9@github.com>

On Thu, 29 Jun 2023 13:45:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> @DamonFool In the future, please wait at least 24 hours before sponsoring changes like this. There have been 33 revisions of this change, many of the people that have commented, potential reviewers are in many time zones and need to have time to see a chance to look at changes before they are integrated.

Okay, got it and will do so in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14578#issuecomment-1613221653

From brian.goetz at oracle.com  Thu Jun 29 13:56:48 2023
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 29 Jun 2023 09:56:48 -0400
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type)
In-Reply-To: <ShDVdF-ap2mtdiWkhmh3YNQ3kH7J2MgP4HrmZwXhHRM=.009712a8-4e19-4d20-a1f0-0c0a2d066e90@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
 <PWUfbQy8c9mvmxdMI1i8eMgyVhum3WFgM2A4VkC1X3A=.3cb86b9a-0619-4baa-8432-1113aa545232@github.com>
 <ShDVdF-ap2mtdiWkhmh3YNQ3kH7J2MgP4HrmZwXhHRM=.009712a8-4e19-4d20-a1f0-0c0a2d066e90@github.com>
Message-ID: <83e32121-f4e8-cfc1-a466-04fb0228c4d3@oracle.com>

It is irritating that one is a type descriptor and one is a signature, 
but we can launder that by observing that both are Utf8Entry.

On 6/29/2023 9:53 AM, Chen Liang wrote:
> On Thu, 29 Jun 2023 13:41:17 GMT, Brian Goetz<briangoetz at openjdk.org>  wrote:
>
>>> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
>>>
>>> Seehttps://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html  for context.
>>>
>>> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.
>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 280:
>>
>>> 278:                             b.writeIndex(l.name());
>>> 279:                             b.writeIndex(l.type());
>>> 280:                             b.writeU2(l.slot());
>> This idiom is repeated four times; seems like it can be factored somewhere into a helper?
> Good idea. The same routine is used in attribute mapper for the two tables, which could be factored as well.
>
> -------------
>
> PR Review Comment:https://git.openjdk.org/jdk/pull/14705#discussion_r1246652541
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230629/bea6b896/attachment.htm>

From rriggs at openjdk.org  Thu Jun 29 13:58:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 13:58:55 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <65iOV8kCbGeb64W8nBn41INqfaz3Lz8gkMf01Z5ChRA=.10c44948-8594-4676-a937-60f39bf4350d@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

Given all the comments, I don't think this is ready to integrate.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1505356736

From lkorinth at openjdk.org  Thu Jun 29 14:12:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 14:12:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
Message-ID: <pfRQFPE48dsB4zX-Rf7hnkzlyMzdctcY-veiO1KeN70=.bffbbead-ef44-461c-8362-21418c7db00e@github.com>

On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You could fix your emacs functions.

It is a *very nice* feature of global-whitespace-cleanup-mode

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347

From shade at openjdk.org  Thu Jun 29 14:42:54 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 29 Jun 2023 14:42:54 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <A7ktTadqMkvN346a252Bq7Yf7V0tMsUE8yLGPpu5u28=.3ca18a93-c68b-4ee4-b399-26bced2b9265@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

Yeah, current code looks like a correct volatile-bearing-DCL. `keySet` is safely published already. Introducing local variable gains us nothing here performance-wise. Arguably, readability is worse. So I would avoid doing this change.

We could have explored if we could drop `volatile` from `keySet`, but it does not look safe, given `HashMap` is not safely constructed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1613304173

From duke at openjdk.org  Thu Jun 29 14:47:57 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 29 Jun 2023 14:47:57 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v2]
In-Reply-To: <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>
Message-ID: <Od90HsXDaopTWBs9lbx58dnTKPiI0qfxeC8TxdY1Gi8=.819e9458-06d7-419f-ba36-8e2363f876fa@github.com>

On Wed, 28 Jun 2023 22:19:04 GMT, ??? <duke at openjdk.org> wrote:

>> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
>> 
>> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
>> 
>> # Benchmark Result
>> 
>> 
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
>> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
>> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
>> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
>> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
>> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
>> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
>> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
>> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
>> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
>> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  8.279 ? 0.184  us/op (+45.92%)
>> +Integers.toStringSmall     500  avgt   15  7.2...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   postpone the division

Can we cache results for small integers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1613311871

From duke at openjdk.org  Thu Jun 29 14:56:57 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 29 Jun 2023 14:56:57 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v2]
In-Reply-To: <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>
Message-ID: <BMFIOVASsyIWdvBDNOYFBxwuEJJGKud2lwXV6q84U6o=.02b6edc4-ac50-42be-b8c7-75ea19bec10d@github.com>

On Wed, 28 Jun 2023 22:19:04 GMT, ??? <duke at openjdk.org> wrote:

>> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
>> 
>> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
>> 
>> # Benchmark Result
>> 
>> 
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
>> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
>> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
>> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
>> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
>> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
>> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
>> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
>> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
>> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
>> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  8.279 ? 0.184  us/op (+45.92%)
>> +Integers.toStringSmall     500  avgt   15  7.2...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   postpone the division

src/java.base/share/classes/java/lang/Integer.java line 464:

> 462:         }
> 463: 
> 464:         if (i == Integer.MIN_VALUE) {

The more common practice is to negate positive numbers. In this way, we can remove this branch and maintain the same style as the other methods in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1246736800

From jlaskey at openjdk.org  Thu Jun 29 15:25:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 29 Jun 2023 15:25:04 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be
 shared
Message-ID: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>

java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example.

-------------

Commit messages:
 - unneeded SuppressWarning
 - Wrong cast
 - Move jdk.internal.referencedkey to jdk.internal.util
 - Merge branch 'master' into 8310913
 - Update MethodType to use ReferencedKeySet
 - Initial commit for ReferencedKeyMap and ReferencedKeySet

Changes: https://git.openjdk.org/jdk/pull/14684/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14684&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310913
  Stats: 1391 lines in 12 files changed: 773 ins; 612 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14684.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14684/head:pull/14684

PR: https://git.openjdk.org/jdk/pull/14684

From coleenp at openjdk.org  Thu Jun 29 15:46:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 15:46:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <DR0fysIfEikX8EG5J7RlPyej6GFMsw-_WkeuS7pM6HM=.36fca2c0-54a4-4563-b40a-c626bc7e1587@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that.  That's a nice feature.  I object to this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709

From rriggs at openjdk.org  Thu Jun 29 15:53:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 15:53:09 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <pTMvEIx5UPajYBUi4pCgN6CsyzVd6tlJhqcla4D3nV4=.c8aa7c9d-4bbe-482e-8b96-1423950105eb@github.com>

On Fri, 23 Jun 2023 17:27:00 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

LGTM; I assume the comment about aarch64 perf was a 10% improvement.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14630#pullrequestreview-1505622321

From naoto at openjdk.org  Thu Jun 29 16:12:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 16:12:55 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <TKEKvdWZ8MAezAqTh_TbKmYUzd8gqMUqOyoJ74kLgSY=.a539b2cb-83fb-4caa-b846-f4fa8a3131bb@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

Retrieving the approval, per the discussion.

-------------

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14692#pullrequestreview-1505656637

From naoto at openjdk.org  Thu Jun 29 16:18:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 16:18:04 GMT
Subject: Integrated: 8310232: java.time.Clock$TickClock.millis() fails in
 runtime when tick is 1 microsecond
In-Reply-To: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
References: <fxC6Qdj5_BnJ_hQGdTxOBX2nWhxMh89wWlaF5KXIRGY=.7aea1f3b-01f9-44f9-b9e7-d2926ed01e0c@github.com>
Message-ID: <LAGkgkK9CXhcCdkT7qmcj6PRBdrXCGx9eTqsZv8j7yY=.0f476cfb-e076-48cd-881c-dbb6b0e1ef02@github.com>

On Mon, 26 Jun 2023 17:31:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `/ by zero` exception with tick durations less than a millisecond.

This pull request has now been integrated.

Changeset: a995aa6c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a995aa6cd1cd89c2ca6db72b060177eaf7065377
Stats:     11 lines in 2 files changed: 8 ins; 0 del; 3 mod

8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

Reviewed-by: iris, rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14657

From asotona at openjdk.org  Thu Jun 29 16:34:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 29 Jun 2023 16:34:29 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v6]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <nGXlPVyTSblsi739gd_20d8wWS_SDroAygGJ1qv84iE=.f2955e08-c830-4865-9eea-01731cc48a1a@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use 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 222 commits:

 - throwing ConstantPoolException for invalid BSM entry index
 - Merge branch 'master' into JDK-8294969-javap
 - fixed JavapTask
 - Merge branch 'master' into JDK-8294969-javap
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - ... and 212 more: https://git.openjdk.org/jdk/compare/07734f6d...adf79feb

-------------

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=05
  Stats: 3643 lines in 23 files changed: 839 ins; 1716 del; 1088 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From lkorinth at openjdk.org  Thu Jun 29 16:55:05 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <azIQJToZ2tpGJTsICHpL96zs9mmHI3fW-laYwy3H-Xk=.99615245-24f9-4b95-b66d-eaba04c8318c@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This was not liked, I will close it.

I will possibly do it under another PR for the GC code.

Thanks for reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703

From lkorinth at openjdk.org  Thu Jun 29 16:55:06 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:06 GMT
Subject: Withdrawn: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <Hsf1WhdMKL5I-3HmOkCZQJWI3MPIHPnFUpo_oMkZj6I=.1ca1f233-3eb8-4d1e-ae3e-eb19729dc1c9@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14698

From naoto at openjdk.org  Thu Jun 29 17:11:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 17:11:55 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared
In-Reply-To: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
Message-ID: <Gz1KWS_Jg4eJXAJvwmgaQZPk4ClRLisQwDihNA6fD2A=.16c11c6a-af4e-4e28-b8df-78f8c3b46927@github.com>

On Tue, 27 Jun 2023 19:07:12 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example.

Looks fine to me. Good to see this class is being shared, as this can be used for refactoring the locale-related caches (https://github.com/openjdk/jdk/pull/14404).

src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 84:

> 82:  * Warning: This class is part of PreviewFeature.Feature.STRING_TEMPLATES.
> 83:  *          Do not rely on its availability.
> 84:  */

Now that this is shared by other components, do we still need this warning?

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1505739194
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1246903833

From jlaskey at openjdk.org  Thu Jun 29 17:25:56 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 29 Jun 2023 17:25:56 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared
In-Reply-To: <Gz1KWS_Jg4eJXAJvwmgaQZPk4ClRLisQwDihNA6fD2A=.16c11c6a-af4e-4e28-b8df-78f8c3b46927@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <Gz1KWS_Jg4eJXAJvwmgaQZPk4ClRLisQwDihNA6fD2A=.16c11c6a-af4e-4e28-b8df-78f8c3b46927@github.com>
Message-ID: <6oRRGcA5Y7yEVCrb3foax-P8tWg2aKFF0YwzIZdKGL0=.f13c23c8-47e1-4d03-98f4-4ce40c8b9cc7@github.com>

On Thu, 29 Jun 2023 16:58:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example.
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeyMap.java line 84:
> 
>> 82:  * Warning: This class is part of PreviewFeature.Feature.STRING_TEMPLATES.
>> 83:  *          Do not rely on its availability.
>> 84:  */
> 
> Now that this is shared by other components, do we still need this warning?

True that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1246927991

From duke at openjdk.org  Thu Jun 29 18:10:24 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 29 Jun 2023 18:10:24 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v2]
In-Reply-To: <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <FknPUXL6l5AKyo2u-Ak1bNo_F04921YCZ9LO_cjVzk0=.c6d6084b-c4f2-4f80-9451-7a5c905d4e3e@github.com>
Message-ID: <EwTgbyPcePjS7U88fcl64LXFveTXp31_MsTW52VVhmk=.c65208f7-2e25-413c-abc9-229aa072e6cd@github.com>

On Wed, 28 Jun 2023 22:19:04 GMT, ??? <duke at openjdk.org> wrote:

>> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
>> 
>> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
>> 
>> # Benchmark Result
>> 
>> 
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
>> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
>> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
>> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
>> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
>> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
>> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
>> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
>> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
>> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
>> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
>> +Integers.toStringBig       500  avgt   15  8.279 ? 0.184  us/op (+45.92%)
>> +Integers.toStringSmall     500  avgt   15  7.2...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   postpone the division

> ```diff
> 9.51
> ```

caching tinyInt result string is a good idea, it can improve performance, but it is expensive, i am not sure whether it should be added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1613582797

From alanb at openjdk.org  Thu Jun 29 18:10:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 18:10:27 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v5]
In-Reply-To: <dUdXGUZH0GjnqHJZDIMaMPrOZwcXrep3CWw7C36ZA1c=.b253fcfe-7127-4dc8-8910-59956f75e03d@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <dUdXGUZH0GjnqHJZDIMaMPrOZwcXrep3CWw7C36ZA1c=.b253fcfe-7127-4dc8-8910-59956f75e03d@github.com>
Message-ID: <N3REMZ1mATo4iot7hw4T9P2CTORfcwrTfAS7tt0qReA=.052a7265-e96f-4e01-8da7-62ffdd72ceb0@github.com>

On Fri, 23 Jun 2023 12:10:33 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>> 
>> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.
>
> Oliver Kopp has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into fix-8240567
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Merge remote-tracking branch 'upstream/master' into fix-8240567
>  - Remove "final" at "enabled" - not part of the point of this PR
>  - Remove comments
>  - 8240567: MethodTooLargeException thrown while creating a jlink image
>    
>    Co-authored-by: Christoph Schwentker <siedlerkiller at gmail.com>

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 694:

> 692:             List<ModuleInfo> currentModuleInfos = null;
> 693:             for (int index = 0; index < moduleInfos.size(); index++) {
> 694:                 if (index % 50 == 0) {

The size of the generated moduleDescriptors is a function of the number of modules, the number of packages in the modules, number of exports, ...   I think your approach is okay for now,  meaning pick some threshold that you are confident will result in a method size < 64k. If the number of modules generate a chained methods to popular the array. It might be clearer to readers to use one threshold rather than two.

The other limit that we will need to think about is the constant pool. That may be future work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1246940571

From jlu at openjdk.org  Thu Jun 29 18:17:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 Jun 2023 18:17:52 GMT
Subject: RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible and
 unimplemented functionality
Message-ID: <c5Tn7PWZHbcxFWiTotcm9K-08xyu0ctxbuhvgFxIzXE=.af1dbece-46ad-4ce0-9437-d225e898a7a7@github.com>

Please review this PR, which clarifies the parameter description of ChoiceFormat.setChoices().

`ChoiceFormat.setChoices(double[] limits, String[] formats)` claims that `formats` can either be "Format objects or Strings". It also claims that "When formatting with object Y, if the object is a NumberFormat, then ((NumberFormat) Y).format(X) is called. Otherwise Y.toString() is called".

This is not true as `formats` is an array of Strings. Thus, the second claim is impossible and unimplemented in the method itself.

The unimplemented specification should be removed from the parameter description.

-------------

Commit messages:
 - Remove impossible claim from param description

Changes: https://git.openjdk.org/jdk/pull/14715/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14715&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6960866
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14715.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14715/head:pull/14715

PR: https://git.openjdk.org/jdk/pull/14715

From jlaskey at openjdk.org  Thu Jun 29 18:24:33 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 29 Jun 2023 18:24:33 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v2]
In-Reply-To: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
Message-ID: <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>

> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove warning tied to String Templates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14684/files
  - new: https://git.openjdk.org/jdk/pull/14684/files/a7217b66..ed467b64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14684&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14684&range=00-01

  Stats: 15 lines in 5 files changed: 0 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14684.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14684/head:pull/14684

PR: https://git.openjdk.org/jdk/pull/14684

From ryan at iernst.net  Thu Jun 29 18:30:35 2023
From: ryan at iernst.net (Ryan Ernst)
Date: Thu, 29 Jun 2023 11:30:35 -0700
Subject: List extending Collection/SequencedCollection
In-Reply-To: <591c1b08-a05c-5347-5965-c750aec10aa2@oracle.com>
References: <CA+DiXd7WgO2fuNJ=OAwUVutjBhk_1uN38uZ77=6-hNW6jCgyTg@mail.gmail.com>
 <591c1b08-a05c-5347-5965-c750aec10aa2@oracle.com>
Message-ID: <CA+DiXd64Gm4TWHo5sno3j68_QKbTf1FvRE8N7X5H4RkKpR=F=w@mail.gmail.com>

Thanks for replying, Joe. First, let me reiterate, we fully admit
there was a bug in painless, we stopped short in walking the class
hierarchy. There is no bug in the SequencedCollection hierarchy. But I
do think there is an inconsistency.

> The two definition are semantically equivalent
> ...
> The JDK 22 javadoc for List shows:
>> All Superinterfaces:
>>     Collection<E>, Iterable<E>, SequencedCollection<E>

While that is true, in practice the reflection API does not give the
same collapsed view that javadocs do. Calling getInterfaces() on a
class only returns direct super interfaces, so
List.class.getInterfaces() no longer returns Collection.class in JDK
21.

The inconsistency I see is that SortedSet.class.getInterfaces() *does*
still return Set.class. Was that intentional? It seems like either
SortedSet does not need to extend Set directly, or List should still
extend Collection directly. And doing the latter would provide an
extra layer of "compatibility" for applications that may look at
direct super interfaces, and be surprised that Collection disappeared
across JDK versions for List.

On Wed, Jun 28, 2023 at 6:31?PM Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>
> Hello,
>
> What is Painless doing that would fail under
>
>      List extends SequencedCollection ...
>
> but work under
>
>      List extends SequencedCollection, Collection ...
>
> The two definition are semantically equivalent since SequencedCollection
> itself extends Collection.
>
> The JDK 22 javadoc for List shows:
>
> > All Superinterfaces:
> >     Collection<E>, Iterable<E>, SequencedCollection<E>
>
> There are certainly implementation artifacts concerning the details of
> how a type was declared that exposed via core reflection (for the
> javax.lang.model API during annotation processing at compile time), but
> it is a bug for third party programs to rely on such details.
>
> HTH,
>
> -Joe
>
> On 6/27/2023 7:37 AM, Ryan Ernst wrote:
> > Hi core-libs-dev,
> >
> > I know various threads have existed over the past few months on
> > SequencedCollection and its implications on compatibility. I wanted to
> > raise this semi-related issue we noticed recently after beginning
> > testing against Java 21.
> >
> > Elasticsearch began testing against Java 21, and noticed a series of
> > failures in Painless (our builtin scripting language, which
> > dynamically compiles to bytecode). Most tests that used List failed to
> > compile, with several unknown methods (eg add). Painless builds a
> > hierarchy of classes it knows about for method resolution. This
> > hierarchy didn't know anything about SequencedCollection since we
> > currently compile against Java 17. Now, this was ultimately a bug in
> > Painless, because we knew there could be cases where we encounter
> > unknown classes in the hierarchy (eg a class which is not blessed to
> > be visible in the language). However, I think the reason we found that
> > bug (List extending from SequencedCollection) might still cause issues
> > for some.
> >
> > While debugging the issue, something that struck me as interesting in
> > the SequencedCollection hierarchy is the difference between List and
> > SortedSet. Both of these classes were made to be compatible with
> > sequenced classes by adding the new classes as super interfaces,
> > SequencedCollection and SequencedSet, respectively. However, while
> > SortedSet was *added* as a super interface, List had its super
> > interface Collection *replaced* by SequencedCollection.
> >
> > I don't know enough about the rampdown process to know if this is
> > still fixable in Java 21. It is probably an extreme edge case that
> > doesn't matter, since eg instanceof Collection will still work in
> > existing code. But for consistency, it would seem better to maintain
> > Collection as a direct super interface of List. Is there any reason
> > such a change doesn't fit with the collections architecture going
> > forward?

From valeriep at openjdk.org  Thu Jun 29 18:39:25 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 29 Jun 2023 18:39:25 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2]
In-Reply-To: <velqdRuSajS8ikM1rXwxMiZvQHuIJRZjYt9nq5v1Qo8=.ef4ed20e-97a9-43c4-a905-b28cb1bb5ac5@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <velqdRuSajS8ikM1rXwxMiZvQHuIJRZjYt9nq5v1Qo8=.ef4ed20e-97a9-43c4-a905-b28cb1bb5ac5@github.com>
Message-ID: <4Lw2xFrG5_EPnoF5oxXORg8ELEx566K79KYGzKNd_Vw=.fd93c479-26dc-4e86-ad18-e51ffbfac727@github.com>

On Mon, 26 Jun 2023 22:52:18 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Hi,
>> 
>> I need a code review for moving the contents of the jdk.crypto.ec module into java.base.  This moves the SunEC JCE Provider (Elliptic Curve) into java.base.  EC has always been separate from the base module/pkg because of its dependence on a native library.  That library was removed in JDK 16.  An empty jdk.crypto.ec module will remain for compatibility, but marked as deprecated with the intent to be removed in a future release.
>> 
>> There should be no compatibility risk for application using EC through JCE. There are no public API changes to EC, XEC, and EdDSA classes .  Applications that unwisely accessing internal EC classes will need to use the java.base module.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update for review:  changed test, removed commented out code in module, fixed switch statement, added --limit-modules

src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 235:

> 233:             provider = p;
> 234:         }
> 235:         return provider;

Why changing it to return 'provider', is this change intentional? IIRC, the general pattern is to return the local reference instead of a volatile variable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1246975681

From duke at openjdk.org  Thu Jun 29 19:15:15 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 29 Jun 2023 19:15:15 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
Message-ID: <iIvGjaTL2vUxFcMJGCBQ8SrnhLyeDZ3KFiUPybZ_09c=.fa426633-7dc3-4f1a-96e0-bb8a35ddd1b9@github.com>

> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
> 
> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
> 
> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix threshold

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14408/files
  - new: https://git.openjdk.org/jdk/pull/14408/files/a084ca54..b61c1dc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14408&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14408/head:pull/14408

PR: https://git.openjdk.org/jdk/pull/14408

From naoto at openjdk.org  Thu Jun 29 19:28:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 19:28:05 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v4]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <_8ueUfakl3XtyZ-dDW36gd-fUokkoChbmBDqHvkSNDg=.ee46d7e2-8a11-4190-984e-31bb506d856a@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Use ReferencedKeyMap in place for LocaleObjectCache
 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Addressing review comments
 - Addressing comments (test grouping, synchronization), minor optimization on loop lookup
 - minor comment fix
 - equals/hash fix, constructor simplification
 - Removed Key
 - minor fixup
 - Use WeakHashMap
 - ... and 4 more: https://git.openjdk.org/jdk/compare/8c52462a...870ec1fe

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/ac6ea421..870ec1fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=02-03

  Stats: 39769 lines in 1438 files changed: 16937 ins; 14906 del; 7926 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From ascarpino at openjdk.org  Thu Jun 29 19:58:56 2023
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 29 Jun 2023 19:58:56 GMT
Subject: RFR: JDK-8308398 Move SunEC crypto provider into java.base [v2]
In-Reply-To: <4Lw2xFrG5_EPnoF5oxXORg8ELEx566K79KYGzKNd_Vw=.fd93c479-26dc-4e86-ad18-e51ffbfac727@github.com>
References: <6lzoh0vmMyKVEF9wFGW-axNSgbgKmMKTclBro12Pa40=.001e679b-3108-46d9-8922-29d8e551abbc@github.com>
 <velqdRuSajS8ikM1rXwxMiZvQHuIJRZjYt9nq5v1Qo8=.ef4ed20e-97a9-43c4-a905-b28cb1bb5ac5@github.com>
 <4Lw2xFrG5_EPnoF5oxXORg8ELEx566K79KYGzKNd_Vw=.fd93c479-26dc-4e86-ad18-e51ffbfac727@github.com>
Message-ID: <TSdRsEX8s8M8qCV8AhQTPgHUADmSOqTINDGXCj4ii4I=.0f4636c2-7ff6-498a-8e8d-528aca01d98b@github.com>

On Thu, 29 Jun 2023 18:36:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update for review:  changed test, removed commented out code in module, fixed switch statement, added --limit-modules
>
> src/java.base/share/classes/sun/security/jca/ProviderConfig.java line 235:
> 
>> 233:             provider = p;
>> 234:         }
>> 235:         return provider;
> 
> Why changing it to return 'provider', is this change intentional? IIRC, the general pattern is to return the local reference instead of a volatile variable.

Ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14457#discussion_r1247106719

From darcy at openjdk.org  Thu Jun 29 20:20:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 29 Jun 2023 20:20:56 GMT
Subject: RFR: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
Message-ID: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>

Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

-------------

Commit messages:
 - JDK-8311115: Type in java.lang.reflect.AccessFlag.METHOD_PARAMETER

Changes: https://git.openjdk.org/jdk/pull/14717/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14717&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311115
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14717.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14717/head:pull/14717

PR: https://git.openjdk.org/jdk/pull/14717

From jlaskey at openjdk.org  Thu Jun 29 20:29:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 29 Jun 2023 20:29:55 GMT
Subject: RFR: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
References: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
Message-ID: <0KSY9iJeUhLx0yvjG1xvj-KrkHvQ9KrPIptD4nsyOuk=.fb26ee46-2456-4b49-8168-571a050923e1@github.com>

On Thu, 29 Jun 2023 20:14:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14717#pullrequestreview-1506071878

From bpb at openjdk.org  Thu Jun 29 20:29:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Jun 2023 20:29:54 GMT
Subject: RFR: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
References: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
Message-ID: <M1KNG7ggJm-RZrGoLC9faCa9sad4SWGE7XobXgAwa00=.0e9871de-614f-4d3c-8bb3-8c72b2afdd91@github.com>

On Thu, 29 Jun 2023 20:14:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14717#pullrequestreview-1506071560

From darcy at openjdk.org  Thu Jun 29 20:38:02 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 29 Jun 2023 20:38:02 GMT
Subject: Integrated: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
References: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
Message-ID: <3zSR7UMFKqH9xS6JrJoR9m15Wp2tH-0Y1P9KSA1HgB0=.08d984d2-c03a-4a7f-86be-85d0084f4c2b@github.com>

On Thu, 29 Jun 2023 20:14:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

This pull request has now been integrated.

Changeset: d9796626
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d97966266e343671693825d2211a34fa45dd271d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311115: Type in java.lang.reflect.AccessFlag.METHOD_PARAMETER

Reviewed-by: bpb, jlaskey, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14717

From mchung at openjdk.org  Thu Jun 29 20:38:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 29 Jun 2023 20:38:01 GMT
Subject: RFR: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
References: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
Message-ID: <fLGYll9ZwPWMaXy9W8vEBFFI6lu8Xvlm_yKtsXE3IUg=.78794436-75c5-4156-b1fd-02b9fcd0f37c@github.com>

On Thu, 29 Jun 2023 20:14:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14717#pullrequestreview-1506076269

From darcy at openjdk.org  Thu Jun 29 20:44:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 29 Jun 2023 20:44:20 GMT
Subject: [jdk21] RFR: 8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
Message-ID: <8NAY9rme5Dj2VQxcP-cW7T08kWH7fjRdZSxBl4MFJNc=.5bec01f7-9630-45dd-bc1d-83af1b1534ca@github.com>

Make the docs in JDK 21 better too.

-------------

Commit messages:
 - Backport d97966266e343671693825d2211a34fa45dd271d

Changes: https://git.openjdk.org/jdk21/pull/82/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311115
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk21/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/82/head:pull/82

PR: https://git.openjdk.org/jdk21/pull/82

From prappo at openjdk.org  Thu Jun 29 20:49:00 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 29 Jun 2023 20:49:00 GMT
Subject: [jdk21] RFR: 8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <8NAY9rme5Dj2VQxcP-cW7T08kWH7fjRdZSxBl4MFJNc=.5bec01f7-9630-45dd-bc1d-83af1b1534ca@github.com>
References: <8NAY9rme5Dj2VQxcP-cW7T08kWH7fjRdZSxBl4MFJNc=.5bec01f7-9630-45dd-bc1d-83af1b1534ca@github.com>
Message-ID: <TT_hpzRm-cqQwe4OT5nRP5n8K-1xB4SqH0Jl57hqp9Y=.41a22915-6013-4e52-93c1-b0b09dfe93bd@github.com>

On Thu, 29 Jun 2023 20:37:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the docs in JDK 21 better too.

Marked as reviewed by prappo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/82#pullrequestreview-1506105696

From darcy at openjdk.org  Thu Jun 29 20:56:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 29 Jun 2023 20:56:04 GMT
Subject: [jdk21] Integrated: 8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <8NAY9rme5Dj2VQxcP-cW7T08kWH7fjRdZSxBl4MFJNc=.5bec01f7-9630-45dd-bc1d-83af1b1534ca@github.com>
References: <8NAY9rme5Dj2VQxcP-cW7T08kWH7fjRdZSxBl4MFJNc=.5bec01f7-9630-45dd-bc1d-83af1b1534ca@github.com>
Message-ID: <1CkN_YPKrnOIvSIeHrqH7pxHlgWPA6AOg1O4WwWkss8=.8d50b445-6fab-4917-9f8a-085c16c3ed4d@github.com>

On Thu, 29 Jun 2023 20:37:09 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the docs in JDK 21 better too.

This pull request has now been integrated.

Changeset: 60db329e
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/60db329e4cd2a9fe7f7f23e0ddde3356bab8ba51
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8311115: Type in java.lang.reflect.AccessFlag.METHOD_PARAMETER

Reviewed-by: prappo
Backport-of: d97966266e343671693825d2211a34fa45dd271d

-------------

PR: https://git.openjdk.org/jdk21/pull/82

From stsypanov at openjdk.org  Thu Jun 29 21:01:56 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 29 Jun 2023 21:01:56 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <3Df73YJmudWZSS5ZVu7Ty5MpVuVj49z30FTQwfntADY=.2d5354c4-0d0a-4c83-a938-9f8f1fb83500@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <3Df73YJmudWZSS5ZVu7Ty5MpVuVj49z30FTQwfntADY=.2d5354c4-0d0a-4c83-a938-9f8f1fb83500@github.com>
Message-ID: <8ki_yyK89OWdwbkkcvs1iliT2PLt0PdYTOyHxIwwR3Y=.3005151e-0f5c-465f-907f-0d433b5e8903@github.com>

On Thu, 29 Jun 2023 12:23:11 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Double-checked locking should rely on local variable to avoid racy reads from volatile field.
>
> The role of the local `keySet` seems pretty useless. It doesn't save neither volatile reads nor writes.

@rgiulietti `keySet` is volatile, so providing it has already been initialized, in original code we read from it twice when doing null-check and returning the value. With local variable we read from the field only once, don't we?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1613802472

From rriggs at openjdk.org  Thu Jun 29 21:01:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 21:01:58 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v2]
In-Reply-To: <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
Message-ID: <_0O8C2nA4rV6Tn4ajCtWy_v_IEelaXOIT_z2onyGMBQ=.d09e3fc4-3ed1-4353-ae4b-d2ba62330913@github.com>

On Thu, 29 Jun 2023 18:24:33 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove warning tied to String Templates

LGTM

src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 65:

> 63:  * replacing the value in the map entry instead of deleting the old entry and
> 64:  * adding a new entry, otherwise replaced entries may end up with a strongly
> 65:  * referenced key. {@link HashMap} and {@link ConcurrentHashMap} are known

Can this requirement be backed up with an assert checking for known ok HashMaps?
It could catch mistakes (in debug builds).

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1506118119
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1247166790

From rriggs at openjdk.org  Thu Jun 29 21:09:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 21:09:02 GMT
Subject: Integrated: 8310241: OffsetDateTime compareTo redundant computation
In-Reply-To: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
References: <ixxWUjI69SpY3sctCaomsoMRZwfUhDtSiK2ztZHUlFM=.d4bc8f49-1bbb-4056-b1c1-328833567136@github.com>
Message-ID: <zUZtzkheEEgSU1GpXWjqiOUamfBGRLoS_SrbupJbdog=.414f9b95-588e-42e8-8295-2a793e84be25@github.com>

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. 
> If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`.
> However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.
> The code is refactored in `compareTo` to do the comparison of `LocalDateTime` exactly once, if it is needed.
> 
> This case is NOT covered by an existing test in test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java

This pull request has now been integrated.

Changeset: 11fd34e1
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11fd34e196b29d2f2fd276c36f59a3c3b3ce7280
Stats:     9 lines in 2 files changed: 7 ins; 0 del; 2 mod

8310241: OffsetDateTime compareTo redundant computation

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14618

From mchung at openjdk.org  Thu Jun 29 21:14:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 29 Jun 2023 21:14:01 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <iIvGjaTL2vUxFcMJGCBQ8SrnhLyeDZ3KFiUPybZ_09c=.fa426633-7dc3-4f1a-96e0-bb8a35ddd1b9@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <iIvGjaTL2vUxFcMJGCBQ8SrnhLyeDZ3KFiUPybZ_09c=.fa426633-7dc3-4f1a-96e0-bb8a35ddd1b9@github.com>
Message-ID: <f3Bdij8FEdZ0lfAOHGA_ODAHVqA8nrsHFTd7UDj1e64=.95fbdbb8-ed1f-4c4e-b9d3-45423a73985d@github.com>

On Thu, 29 Jun 2023 19:15:15 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image".
>> 
>> Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods
>> 
>> This is a follow-up to https://github.com/openjdk/jdk/pull/10704. GitHub did not allow me to re-open the PR, because I did a force-push to have one commit.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix threshold

Thanks for fixing this.   The approach looks okay.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 669:

> 667:          */
> 668:         private void genModuleDescriptorsMethod(ClassBuilder clb) {
> 669:             if (moduleInfos.size() <= 75) {

The plugin can take an optional argument to configure the max number of module infos to split in case it hits the limit in a future case.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 683:

> 681:                                         minfo.descriptor(),
> 682:                                         minfo.packages(),
> 683:                                         index).build();

Formatting nit: align the parameters with the first one as the original code does.  Same applies to line 751-753

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 691:

> 689:             }
> 690: 
> 691:             List<List<ModuleInfo>> splitModuleInfos = new ArrayList<>();

Please add the comments to describe what this does.   Pseudo code may also help.   It'd be helpful to explain the reason why the Sub method stores and restores what local variables.

I also wonder if you consider `moduleDescriptors` does this:

    ArrayList<Object> localVars = new ArrayList<>();
    moduleDescriptorsSub0(moduleInfos, localVars);
    .... // add new local variables to localVars
    moduleDescriptorsSub1(moduleInfos, localVars);
    .... // add new local variables to localVars
    :
    :


The same `localVars` array list is used and just add the new local variables defined from each batch (no need to create a new ArrayList and stores local variables every time)

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 701:

> 699:             }
> 700: 
> 701:             final String helperMethodNamePrefix = "moduleDescriptorsSub";

Perhaps a shorter name.   Also, prefer to drop the final modifier from these local variables (which adds noise).

Suggestion:

            String helperMethodNamePrefix = "sub";

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 731:

> 729: 
> 730:             final int[] globalCount = {0};
> 731:             for (final int[] index = {0}; index[0] < splitModuleInfos.size(); index[0]++) {

Suggestion:

            for (int n = 0, count = 0; n < splitModuleInfos.size(); count += splitModuleInfos.get(n).size(), n++) {
                int index = n;          // the index of which ModuleInfo being processed in the current batch
                int start = count;   // the start index to the return ModuleDescriptor array for the current batch


I prefer to avoid using the array to workaround the final variable used within lambda.   Free feel to rename these variables and comment to make it clear.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java line 737:

> 735:                         ACC_PUBLIC,
> 736:                         cob -> {
> 737:                             List<ModuleInfo> moduleInfosPackage = splitModuleInfos.get(index[0]);

It's not a package.   Maybe `currentBatch`?

Suggestion:

                            List<ModuleInfo> currentBatch = splitModuleInfos.get(index[0]);

test/jdk/tools/jlink/JLink100Modules.java line 40:

> 38:  * @library ../lib
> 39:  * @modules java.base/jdk.internal.jimage
> 40:  *          jdk.jdeps/com.sun.tools.classfile

I guess you copied this from other jlink tests.   Do you know why jlink tests need `com.sun.tools.classfile`?

test/jdk/tools/jlink/JLink100Modules.java line 47:

> 45:  *          jdk.compiler
> 46:  * @build tests.*
> 47:  * @run main/othervm -verbose:gc -Xmx1g -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal JLink100Modules

This patch does not change the bytecode if it's less than 75 modules.  You want to apply `-XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal`  flags also to a custom image with the new bytecodes.   So this test should include an execution of `JLink100ModulesTest`  from `out-jlink` image with these flags.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14408#pullrequestreview-1506071351
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247152818
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247153724
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247170257
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247178553
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247176136
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247176887
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247137347
PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247143921

From mchung at openjdk.org  Thu Jun 29 21:14:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 29 Jun 2023 21:14:03 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v6]
In-Reply-To: <f3Bdij8FEdZ0lfAOHGA_ODAHVqA8nrsHFTd7UDj1e64=.95fbdbb8-ed1f-4c4e-b9d3-45423a73985d@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <iIvGjaTL2vUxFcMJGCBQ8SrnhLyeDZ3KFiUPybZ_09c=.fa426633-7dc3-4f1a-96e0-bb8a35ddd1b9@github.com>
 <f3Bdij8FEdZ0lfAOHGA_ODAHVqA8nrsHFTd7UDj1e64=.95fbdbb8-ed1f-4c4e-b9d3-45423a73985d@github.com>
Message-ID: <nfdX43HGHnn1CSf0utYYRU_zUbMa6tgifigVYK8p42Q=.61874210-9c67-4c97-8eb9-8e57a2a8a133@github.com>

On Thu, 29 Jun 2023 20:34:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix threshold
>
> test/jdk/tools/jlink/JLink100Modules.java line 47:
> 
>> 45:  *          jdk.compiler
>> 46:  * @build tests.*
>> 47:  * @run main/othervm -verbose:gc -Xmx1g -Xlog:init=debug -XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal JLink100Modules
> 
> This patch does not change the bytecode if it's less than 75 modules.  You want to apply `-XX:+UnlockDiagnosticVMOptions -XX:+BytecodeVerificationLocal`  flags also to a custom image with the new bytecodes.   So this test should include an execution of `JLink100ModulesTest`  from `out-jlink` image with these flags.

BTW,  is `-verbose:gc` leftover from debugging?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247144580

From jlaskey at openjdk.org  Thu Jun 29 21:18:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 29 Jun 2023 21:18:55 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v2]
In-Reply-To: <_0O8C2nA4rV6Tn4ajCtWy_v_IEelaXOIT_z2onyGMBQ=.d09e3fc4-3ed1-4353-ae4b-d2ba62330913@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
 <_0O8C2nA4rV6Tn4ajCtWy_v_IEelaXOIT_z2onyGMBQ=.d09e3fc4-3ed1-4353-ae4b-d2ba62330913@github.com>
Message-ID: <0zO16xbEbPluGdgjvb7y7DP3IZe89znBmGgJmBVbjPA=.cbb6795f-0168-45e2-a2c2-fe95108d7a44@github.com>

On Thu, 29 Jun 2023 20:54:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove warning tied to String Templates
>
> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 65:
> 
>> 63:  * replacing the value in the map entry instead of deleting the old entry and
>> 64:  * adding a new entry, otherwise replaced entries may end up with a strongly
>> 65:  * referenced key. {@link HashMap} and {@link ConcurrentHashMap} are known
> 
> Can this requirement be backed up with an assert checking for known ok HashMaps?
> It could catch mistakes (in debug builds).

It's known to be safe for HashMap and ConcurrentHashMap. Most others should fine but need some thought experiments to work it out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1247184193

From prappo at openjdk.org  Thu Jun 29 21:25:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 29 Jun 2023 21:25:05 GMT
Subject: RFR: 8311122: Fix typos in java.base
Message-ID: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>

Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

-------------

Commit messages:
 - Fix copyright years
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14718/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311122
  Stats: 23 lines in 13 files changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/14718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14718/head:pull/14718

PR: https://git.openjdk.org/jdk/pull/14718

From darcy at openjdk.org  Thu Jun 29 21:31:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 29 Jun 2023 21:31:53 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
Message-ID: <wvQcG_zFAg66GVy9gWT3gcJbQX4SU9_g5maqjKpV7co=.288978f6-7876-4e35-8a6a-551846bd9df3@github.com>

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

Looks fine, but please give some time for others reviewers before pushing.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506159651

From prappo at openjdk.org  Thu Jun 29 21:38:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 29 Jun 2023 21:38:53 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <wvQcG_zFAg66GVy9gWT3gcJbQX4SU9_g5maqjKpV7co=.288978f6-7876-4e35-8a6a-551846bd9df3@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
 <wvQcG_zFAg66GVy9gWT3gcJbQX4SU9_g5maqjKpV7co=.288978f6-7876-4e35-8a6a-551846bd9df3@github.com>
Message-ID: <KN5lo7lyHEzvOHnbAXgfmy87ERtEjCp3VHJjBy6FC3k=.ce96d1fe-e2ce-4ee7-814b-4a33b02f8dfe@github.com>

On Thu, 29 Jun 2023 21:28:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looks fine, but please give some time for others reviewers before pushing.

Absolutely!

Also, this PR contains a code change (a typo in an error message), which, technically speaking, disqualifies the bug from being "noreg-doc" and requires an appropriate test run. I'll let the PR sit for at least a couple of days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14718#issuecomment-1613838292

From naoto at openjdk.org  Thu Jun 29 21:57:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 21:57:51 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
Message-ID: <B9qPsHCWdbUGcs0aZYmfbMkvK1aEk3i8SaFOaVEk4yE=.cfff6ce0-adef-4f0a-9d29-300569e39bd4@github.com>

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506183994

From mchung at openjdk.org  Thu Jun 29 21:57:52 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 29 Jun 2023 21:57:52 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
Message-ID: <zh1wCIhD8fOUoKh4cJ9M9l4DJZrKjI2bBTddfjAtqpc=.92807fc4-cf48-4dbd-9672-33681f960810@github.com>

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506186255

From iris at openjdk.org  Thu Jun 29 22:02:53 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 29 Jun 2023 22:02:53 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
Message-ID: <zgDECXWXITURVw08P28QqbENCbFFOncNbhUSBUhRVbQ=.43e4fdc6-a018-4ba4-b972-03883adb226e@github.com>

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506190678

From naoto at openjdk.org  Thu Jun 29 22:33:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 22:33:53 GMT
Subject: RFR: 6960866: [Fmt-Ch] ChoiceFormat claims impossible and
 unimplemented functionality
In-Reply-To: <c5Tn7PWZHbcxFWiTotcm9K-08xyu0ctxbuhvgFxIzXE=.af1dbece-46ad-4ce0-9437-d225e898a7a7@github.com>
References: <c5Tn7PWZHbcxFWiTotcm9K-08xyu0ctxbuhvgFxIzXE=.af1dbece-46ad-4ce0-9437-d225e898a7a7@github.com>
Message-ID: <JLk4I_a_BpP66jaIRexKZoVBAVxEeOaLZMzfp8tqzP4=.ee844411-2e9a-4623-a986-d51ec1a3553f@github.com>

On Thu, 29 Jun 2023 18:02:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which clarifies the parameter description of ChoiceFormat.setChoices().
> 
> `ChoiceFormat.setChoices(double[] limits, String[] formats)` claims that `formats` can either be "Format objects or Strings". It also claims that "When formatting with object Y, if the object is a NumberFormat, then ((NumberFormat) Y).format(X) is called. Otherwise Y.toString() is called".
> 
> This is not true as `formats` is an array of Strings. Thus, the second claim is impossible and unimplemented in the method itself.
> 
> The unimplemented specification should be removed from the parameter description.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14715#pullrequestreview-1506215477

From dl at openjdk.org  Thu Jun 29 22:44:14 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 29 Jun 2023 22:44:14 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v2]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <OpnOW59Li-qsKAJbnSj0RhziC3TYhpIBC0JBmS-8EfI=.d908f0a7-93e0-4849-b30e-565ba16768f2@github.com>

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

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 two additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8301341
 - Use Thread.isVirtual to distinguish spin vs immediate block cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/c36bbe0e..eec7e491

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=00-01

  Stats: 83867 lines in 2037 files changed: 53853 ins; 19941 del; 10073 mod
  Patch: https://git.openjdk.org/jdk/pull/14317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14317/head:pull/14317

PR: https://git.openjdk.org/jdk/pull/14317

From duke at openjdk.org  Thu Jun 29 22:50:56 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 29 Jun 2023 22:50:56 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v5]
In-Reply-To: <N3REMZ1mATo4iot7hw4T9P2CTORfcwrTfAS7tt0qReA=.052a7265-e96f-4e01-8da7-62ffdd72ceb0@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <dUdXGUZH0GjnqHJZDIMaMPrOZwcXrep3CWw7C36ZA1c=.b253fcfe-7127-4dc8-8910-59956f75e03d@github.com>
 <N3REMZ1mATo4iot7hw4T9P2CTORfcwrTfAS7tt0qReA=.052a7265-e96f-4e01-8da7-62ffdd72ceb0@github.com>
Message-ID: <g3zZTSClQzIJhGpkg1B79bgv5Dara3QjpFG39z0vY1I=.54eae365-5d93-4a1d-a4c3-784760847919@github.com>

On Thu, 29 Jun 2023 17:37:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The size of the generated moduleDescriptors is a function of the number of modules, the number of packages in the modules, number of exports, ... I think your approach is okay for now, meaning pick some threshold that you are confident will result in a method size < 64k.

I am very confident with 50 as 1) we tried out with a real life application using a high variation of dependencies (covering Apache libraries, Google libraries, and Oracle's JavaFX) and 2) it is half of the value of the number of modules where it broke at our software.

> It might be clearer to readers to use one threshold rather than two.

Above, the 75 was chosen, to avoid that anything in the JDK distribution is split (number was 73 to be precise, but I did want to have a "round" number). 

To be consistent, I adapted the lower split to 75. I tried it out with our app, and the app still works.

> The other limit that we will need to think about is the constant pool. That may be future work.

I am leaning towards "future work" here. Nevertheless, could you outline how that limit might be reached? It IMHO cannot be the numbmer of helper functions. The current "limit" leads to 32,000 (constant pool limit; leaving the other 32k to other things) x 75 (number of module descriptors covered) = 2.4 million module descriptors. In that case we might hit the call stack limit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14408#discussion_r1247239060

From prappo at openjdk.org  Thu Jun 29 22:51:53 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 29 Jun 2023 22:51:53 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
Message-ID: <0jb07mulxVcJZ5t67l5gSkc44PcceBie-3FAjli-Xj4=.a88f9a10-f954-4770-aebe-6d9f8836563d@github.com>

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

Our CI tests are fine with this change. That said, I'll wait for security-dev to complete the review, and then wait for a few more days so that others could also inspect the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14718#issuecomment-1613893129

From dl at openjdk.org  Thu Jun 29 22:53:10 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 29 Jun 2023 22:53:10 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v3]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <_Tpu8XvjPhvjVA165CRDGuI_rc167JJfpVmIDxnb5rI=.ff79d326-e9fd-4b76-9b15-4567e8f3b247@github.com>

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Overhaul LTQ and SQ to use common blocking and matching mechanics

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/eec7e491..67a145a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=01-02

  Stats: 1655 lines in 3 files changed: 307 ins; 947 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/14317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14317/head:pull/14317

PR: https://git.openjdk.org/jdk/pull/14317

From naoto at openjdk.org  Thu Jun 29 23:36:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 Jun 2023 23:36:01 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v4]
In-Reply-To: <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
Message-ID: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>

On Wed, 28 Jun 2023 20:49:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors Currency tests to use JUnit.
>> 
>> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
>> 
>> - Tests are no longer dependent on each other (order of execution does not matter)
>> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
>> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
>> 
>> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unusued JUnit imports from ValidateISO4217.java

test/jdk/java/util/Currency/CurrencyNameProviderTest.java line 43:

> 41: import static org.junit.jupiter.api.Assertions.assertThrows;
> 42: 
> 43: public class CurrencyNameProviderTest {

Since this is not a generic CurrencyNameProvider test, but specific to the default impl of CNP.getDisplayName(), the class name could be more specific.

test/jdk/java/util/Currency/CurrencyTest.java line 81:

> 79:         }
> 80: 
> 81:         // Calling getInstance() with an illegal name should throw an IAE

illegal name -> invalid currency code

test/jdk/java/util/Currency/CurrencyTest.java line 241:

> 239:                 Arguments.of("JOD", 3), Arguments.of("KWD", 3),
> 240:                 Arguments.of("LYD", 3), Arguments.of("OMR", 3),
> 241:                 Arguments.of("TND", 3), Arguments.of("TRL", 0), // Turkish Lira

The turkish lira comment should apply to both TRL and TRY

test/jdk/java/util/Currency/CurrencyTest.java line 321:

> 319:         Currency currency2 = Currency.getInstance(currencyCode);
> 320:         assertEquals(currency1, currency2, "Didn't get same instance for same currency code");
> 321:         assertEquals(currency1.getCurrencyCode(), currencyCode, "Currency code changed");

Error message more like "wrong currency code", than "changed"

test/jdk/java/util/Currency/MinorUndefinedCodes.java line 27:

> 25:  * @test
> 26:  * @bug 4512215 4818420 4819436 8310923
> 27:  * @summary Test some minor undefined currencies.

It'd be more readable something like "currencies without minor units." The class name can also be renamed to something like NoMinorUnitCurrenciesTest

test/jdk/java/util/Currency/ValidateISO4217.java line 82:

> 80:     // Codes derived from ISO4217 golden-data file
> 81:     private static final List<Arguments> ISO4217Codes = new ArrayList<Arguments>();
> 82:     // Additional codes not from the ISO4217 golden-data file

Are these from the golden file?

test/jdk/java/util/Currency/ValidateISO4217.java line 96:

> 94:         setUpISO4217Codes();
> 95:         setUpAdditionalCodes();
> 96:         finishTestCurrencies();

The method name `finish` is kind of confusing. I'd explicitly describe what the method does, i.e, setup `other` currencies.

test/jdk/java/util/Currency/ValidateISO4217.java line 192:

> 190:                 /* Defined neither in ISO 4217 nor ISO 3166 list */
> 191:                 {"XK", "EUR", "978", "2"},      // Kosovo
> 192:         };

I'd prefer this array to be placed as static in the class, not within the method.

test/jdk/java/util/Currency/ValidateISO4217.java line 214:

> 212:                         + "PTE-ROL-RUR-SDD-SIT-SLL-SKK-SRG-STD-TMM-TPE-TRL-VEF-UYI-USN-USS-VEB-VED-"
> 213:                         + "XAG-XAU-XBA-XBB-XBC-XBD-XDR-XFO-XFU-XPD-XPT-XSU-XTS-XUA-XXX-"
> 214:                         + "YUM-ZMK-ZWD-ZWN-ZWR";

Ditto as `extraCodes`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247234295
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247239767
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247238613
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247237567
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247247681
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247255026
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247253772
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247254253
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247254528

From mchung at openjdk.org  Thu Jun 29 23:48:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 29 Jun 2023 23:48:59 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock for
 non-parallel capable loader
Message-ID: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>

8254566: Clarify the spec of ClassLoader::getClassLoadingLock for non-parallel capable loader

-------------

Commit messages:
 - 8254566: Clarify the spec of ClassLoader::loadClass about the lock acquired by non-parallel capable loader

Changes: https://git.openjdk.org/jdk/pull/14720/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14720&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254566
  Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14720/head:pull/14720

PR: https://git.openjdk.org/jdk/pull/14720

From dholmes at openjdk.org  Fri Jun 30 00:09:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 00:09:54 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock
 for non-parallel capable loader
In-Reply-To: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
References: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
Message-ID: <zI_1OPUAdY_viUvV2c3pKVscnllsP2sypwX8ApkpSzE=.e06fc53f-fd57-43a3-9519-e37667b263b4@github.com>

On Thu, 29 Jun 2023 23:39:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The spec of `ClassLoader::getClassLoadingLock` is unclear that this method is intended for parallel-capable class loader implementations to provide an alternate implementation.   For non-parallel-capable class loaders, this method should return this `ClassLoader` object.   The javadoc uses "the default implementation" which could be interpreted that non-parallel-capable class loaders can also override this implementation, which is not the intent.  See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html.

Looks good. One change requested on terminology.

Thanks

src/java.base/share/classes/java/lang/ClassLoader.java line 656:

> 654:      * @apiNote
> 655:      * This method allows parallel capable class loaders to implement
> 656:      * finer-grained locking scheme such that multiple threads may load classes

s/scheme/schemes/

src/java.base/share/classes/java/lang/ClassLoader.java line 658:

> 656:      * finer-grained locking scheme such that multiple threads may load classes
> 657:      * concurrently without deadlocks.  For non-parallel-capable class loaders,
> 658:      * the {@code ClassLoader} object is held during the class loading operations.

s/is held/is synchronized on/  - as that is the terminology loadClass uses.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14720#pullrequestreview-1506269248
PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1247270508
PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1247271118

From mchung at openjdk.org  Fri Jun 30 00:22:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Jun 2023 00:22:13 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock
 for non-parallel capable loader [v2]
In-Reply-To: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
References: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
Message-ID: <STxV-xgSUOmpuk33CMdTeglUGa_rGcfl7NIvM4U7VCA=.210aa95f-cf85-4c44-a66f-4b195f08e059@github.com>

> The spec of `ClassLoader::getClassLoadingLock` is unclear that this method is intended for parallel-capable class loader implementations to provide an alternate implementation.   For non-parallel-capable class loaders, this method should return this `ClassLoader` object.   The javadoc uses "the default implementation" which could be interpreted that non-parallel-capable class loaders can also override this implementation, which is not the intent.  See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14720/files
  - new: https://git.openjdk.org/jdk/pull/14720/files/e87f4b45..e9607f4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14720&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14720&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14720/head:pull/14720

PR: https://git.openjdk.org/jdk/pull/14720

From mchung at openjdk.org  Fri Jun 30 00:22:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Jun 2023 00:22:14 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock
 for non-parallel capable loader [v2]
In-Reply-To: <zI_1OPUAdY_viUvV2c3pKVscnllsP2sypwX8ApkpSzE=.e06fc53f-fd57-43a3-9519-e37667b263b4@github.com>
References: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
 <zI_1OPUAdY_viUvV2c3pKVscnllsP2sypwX8ApkpSzE=.e06fc53f-fd57-43a3-9519-e37667b263b4@github.com>
Message-ID: <XH8SSPCwfY7L0ZzcO37XJXawC7GybkksXOT1XTuPwKY=.643d28a0-1c0c-40f9-9397-ad89d18e88a0@github.com>

On Fri, 30 Jun 2023 00:06:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comment
>
> src/java.base/share/classes/java/lang/ClassLoader.java line 658:
> 
>> 656:      * finer-grained locking scheme such that multiple threads may load classes
>> 657:      * concurrently without deadlocks.  For non-parallel-capable class loaders,
>> 658:      * the {@code ClassLoader} object is held during the class loading operations.
> 
> s/is held/is synchronized on/  - as that is the terminology loadClass uses.

Updated per your suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14720#discussion_r1247275274

From liach at openjdk.org  Fri Jun 30 00:32:07 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 00:32:07 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type) [v2]
In-Reply-To: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
Message-ID: <RakeuMuIxsMJRA2NsPWDj78Pbm5NUeS4ci26hjS4ZNE=.f1e8ff02-e2a7-466b-895c-a4cf8fcdb0f9@github.com>

> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
> 
> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Share the local var writing logic in a helper class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14705/files
  - new: https://git.openjdk.org/jdk/pull/14705/files/544cde06..7d9a87e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14705&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14705&range=00-01

  Stats: 90 lines in 3 files changed: 58 ins; 24 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14705/head:pull/14705

PR: https://git.openjdk.org/jdk/pull/14705

From liach at openjdk.org  Fri Jun 30 00:51:42 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 00:51:42 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type) [v3]
In-Reply-To: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
Message-ID: <7ubzbHS_BqvgHxklY3aRqbDUlntOcUNlRDALOKHXwcU=.bbdb193a-e9e3-4047-84c0-9659915e3b69@github.com>

> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
> 
> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix line ending, update corpus test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14705/files
  - new: https://git.openjdk.org/jdk/pull/14705/files/7d9a87e2..a2e604eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14705&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14705&range=01-02

  Stats: 78 lines in 2 files changed: 1 ins; 2 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/14705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14705/head:pull/14705

PR: https://git.openjdk.org/jdk/pull/14705

From duke at openjdk.org  Fri Jun 30 01:03:30 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 01:03:30 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v3]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <-Qm0w4W1IQ1-wVX5WkR7UrXkh9rLm8rM8yhPXpQMt6s=.0d5bfe89-993f-44b2-94bd-c3d1eaa376ee@github.com>

> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
> 
> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
> 
> # Benchmark Result
> 
> 
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.Integers.toString*"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * cpu : aliyun yitian 710 (aarch64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt   Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  12.081 ? 0.377  us/op
> -Integers.toStringSmall     500  avgt   15   7.119 ? 0.177  us/op
> -Integers.toStringTiny      500  avgt   15   6.323 ? 0.239  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR commit-id 3355d211)
> +Integers.toStringBig       500  avgt   15  8.279 ? 0.184  us/op (+45.92%)
> +Integers.toStringSmall     500  avgt   15  7.232 ? 0.239  us/op (-1.52%)
> +Integers.toStringTiny      500  avgt   15  6.850 ? 0.185  us/op (-7.69%)...

??? has updated the pull request incrementally with one additional commit since the last revision:

  improve based on getChars

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/3355d211..62b499d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=01-02

  Stats: 192 lines in 1 file changed: 37 ins; 150 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From dholmes at openjdk.org  Fri Jun 30 01:15:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:15:53 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock
 for non-parallel capable loader [v2]
In-Reply-To: <STxV-xgSUOmpuk33CMdTeglUGa_rGcfl7NIvM4U7VCA=.210aa95f-cf85-4c44-a66f-4b195f08e059@github.com>
References: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
 <STxV-xgSUOmpuk33CMdTeglUGa_rGcfl7NIvM4U7VCA=.210aa95f-cf85-4c44-a66f-4b195f08e059@github.com>
Message-ID: <c8KFFV5k4ERVfUoL8RHTbWp8DK5xjDsRWczQvQRz0Tk=.fea4e48c-2dd4-4dbd-84c1-75df65d17826@github.com>

On Fri, 30 Jun 2023 00:22:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The spec of `ClassLoader::getClassLoadingLock` is unclear that this method is intended for parallel-capable class loader implementations to provide an alternate implementation.   For non-parallel-capable class loaders, this method should return this `ClassLoader` object.   The javadoc uses "the default implementation" which could be interpreted that non-parallel-capable class loaders can also override this implementation, which is not the intent.  See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Looks good to me.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14720#pullrequestreview-1506312151

From dholmes at openjdk.org  Fri Jun 30 01:24:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:24:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
 <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
Message-ID: <ufj18ITz-S_VgkscmrxacxLtfQB-4I5hpgs8c61kOmA=.15f34364-70ac-4279-8669-f01e109b8411@github.com>

On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My changes look like this in the diff output
> ```
>  }
> -
> ```

Thanks for showing  this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636

From liach at openjdk.org  Fri Jun 30 02:28:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 02:28:54 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries
In-Reply-To: <HMq24IZVFST-KXVfVWvs0WcK5j_WAXM0SvZkdwZL5s4=.6ab8d797-3e68-426c-9a3a-4c7f281f1c48@github.com>
References: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
 <ndv_sZQLyovjkHrqKuDgMR8-jtjHaJO7vQmeudnl4Kw=.cb4a6810-bbcf-46f9-9ae6-017dc541d293@github.com>
 <HMq24IZVFST-KXVfVWvs0WcK5j_WAXM0SvZkdwZL5s4=.6ab8d797-3e68-426c-9a3a-4c7f281f1c48@github.com>
Message-ID: <V7LRuVBWxEl6ZUkjHv5ad_QIELIJwsqI-rk3W9KTgF4=.812dc4e1-0c45-430c-82cf-aa0053fa00d8@github.com>

On Thu, 29 Jun 2023 13:26:00 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/constantpool/InvokeDynamicEntry.java line 46:
>> 
>>> 44:     default MethodTypeDesc typeSymbol() {
>>> 45:         return Util.methodTypeSymbol(nameAndType());
>>> 46:     }
>> 
>> Similar comment as with CondyEntry -- reduce usage of Util::methodTypeSymbol in this class
>
> (Would like to do the same in various ::count methods, but unfortunately MemberRefEntry is too general; would have to rejigger the various XxxRefEntry types.)

Which `count` methods are you referring to, Brian?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14706#discussion_r1247343141

From liach at openjdk.org  Fri Jun 30 02:40:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 02:40:54 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v3]
In-Reply-To: <-Qm0w4W1IQ1-wVX5WkR7UrXkh9rLm8rM8yhPXpQMt6s=.0d5bfe89-993f-44b2-94bd-c3d1eaa376ee@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <-Qm0w4W1IQ1-wVX5WkR7UrXkh9rLm8rM8yhPXpQMt6s=.0d5bfe89-993f-44b2-94bd-c3d1eaa376ee@github.com>
Message-ID: <bqdqYk_Rf1kOV-aMSyGQ2oOcFLT3Q3JEtztOTsZA4u4=.77904240-c1cf-4168-8627-8ca13811d3ba@github.com>

On Fri, 30 Jun 2023 01:03:30 GMT, ??? <duke at openjdk.org> wrote:

>> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
>> 
>> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
>> 
>> # Benchmark Result
>> 
>> 
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
>> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
>> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 01 3355d211)
>> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
>> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
>> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 02 62b499d6)
>> +Integers.toStringBig       500  avgt   15  5.971 ? 0.014  us/op (+14.06%)
>> +Integers.toStringSmall     500  avgt   15  4.346 ? 0.016  us/op (+10.30%)
>> +Integers.toStringTiny      500  avgt   15  3.671 ? 0.019  us/op (+2.20%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
>> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
>> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 01 3355d211)
>> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
>> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
>> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units  (PR Update 02 62b499d6)
>> +Integers.toStringBig       500  avgt   15  5.493 ? 0.007  us/op (+23.10%)
>> +Integers.toStringSmall     500  avgt   15  3.714 ? 0.006  us/op (+20.65%)
>> +Integers.toStringTiny      500  avgt   15  2.786 ? 0.015  us/op (-0.89...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve based on getChars

Changes requested by liach (Author).

src/java.base/share/classes/java/lang/Integer.java line 552:

> 550:             i = q;
> 551:             charPos -= 2;
> 552:             Unsafe.getUnsafe().putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, DigitPacks[r]);

Suggestion:

            Unsafe.getUnsafe().putShortUnaligned(buf, Unsafe.ARRAY_BYTE_BASE_OFFSET + charPos, DigitPacks[r], false);

You should explicitly specify the endianness, which is platform dependent.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1506384387
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1247350891

From liach at openjdk.org  Fri Jun 30 02:42:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 02:42:08 GMT
Subject: RFR: 8311084: Add typeSymbol() API for applicable constant pool
 entries [v2]
In-Reply-To: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
References: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
Message-ID: <u7IeW6T8Rt8l9bNsUz5hIJ7skKos01JMDZPSCFuWF1Y=.e20f3877-d02a-413c-aed1-e0c2af14b573@github.com>

> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
> 
> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
> 
> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Use typeSymbol in asSymbol

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14706/files
  - new: https://git.openjdk.org/jdk/pull/14706/files/d2701993..3ae616ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14706&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14706/head:pull/14706

PR: https://git.openjdk.org/jdk/pull/14706

From dholmes at openjdk.org  Fri Jun 30 02:56:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 02:56:00 GMT
Subject: RFR: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
References: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
Message-ID: <nUynT4GDEClSgNQbNDLI9nkQ4Fk9DmIZ5-g6o00ipEo=.8751d1de-5f9c-44e7-9a2f-1df6438864ca@github.com>

On Thu, 29 Jun 2023 20:14:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

And ironically no one noticed the typo in the JBS issue title.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14717#issuecomment-1614042157

From jlaskey at openjdk.org  Fri Jun 30 03:20:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 30 Jun 2023 03:20:08 GMT
Subject: RFR: JDK-8311115: Type in
 java.lang.reflect.AccessFlag.METHOD_PARAMETER
In-Reply-To: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
References: <-qLRcGUn8Qys057_gaLqKCX3LOqMv7055yqiTfORdVo=.9dfa15c6-f842-4ab1-8e46-a9d715b52a98@github.com>
Message-ID: <9CsBdUz3MRccZvMq6fdS0PL_IJSDpLwsEur_dZSmNpg=.0df31063-d9cb-4152-99df-fcc674d19799@github.com>

On Thu, 29 Jun 2023 20:14:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Typo fix; running a spell check over the comments and strings in the file, didn't notice any other problems.

I'd like to blame it on a spellchecker but it's more likely two left thumbs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14717#issuecomment-1614058237

From duke at openjdk.org  Fri Jun 30 04:56:35 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 04:56:35 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v4]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <YHSq4gXI1j3Z5QFv-akvXACJxsm3iWwQZShVlNOtHfI=.40940797-37df-47e0-b549-917e2a7257ad@github.com>

> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
> 
> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
> 
> # Benchmark Result
> 
> 
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.Integers.toString*"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 01 3355d211)
> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 02 62b499d6)
> +Integers.toStringBig       500  avgt   15  5.971 ? 0.014  us/op (+14.06%)
> +Integers.toStringSmall     500  avgt   15  4.346 ? 0.016  us/op (+10.30%)
> +Integers.toStringTiny      500  avgt   15  3.671 ? 0.019  us/op (+2.20%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 01 3355d211)
> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units  (PR Update 02 62b499d6)
> +Integers.toStringBig       500  avgt   15  5.493 ? 0.007  us/op (+23.10%)
> +Integers.toStringSmall     500  avgt   15  3.714 ? 0.006  us/op (+20.65%)
> +Integers.toStringTiny      500  avgt   15  2.786 ? 0.015  us/op (-0.89%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * ...

??? has updated the pull request incrementally with one additional commit since the last revision:

  explicitly specify the endianness

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/62b499d6..484acc69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=02-03

  Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From liach at openjdk.org  Fri Jun 30 05:16:10 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 05:16:10 GMT
Subject: RFR: 8307149: MethodHandles.arrayConstructor can be cached
In-Reply-To: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>
References: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>
Message-ID: <M3GWbTbM-_eVDTD274Bs1k2A3qT1IeOKUItkIyPote4=.6d5e76e5-86e5-49a4-8daf-10831db7d33a@github.com>

On Thu, 4 May 2023 23:29:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch migrates `MethodHandles::arrayConstructor`, added in Java 9 as a hotfix to the incorrect constructor found on arrays via Lookup, to share the array access caching features. The result is that calling `MethodHandles.arrayConstructor` to create method handles is much faster.
> 
> Oracle JDK 20:
> 
> Benchmark                                             Mode  Cnt   Score   Error  Units
> MethodHandlesArrayConstructor.createWithAnewarray     avgt   15   2.739 ? 0.058  ns/op
> MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15   3.313 ? 0.041  ns/op
> MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  61.874 ? 0.397  ns/op
> 
> 
> This patch:
> 
> Benchmark                                             Mode  Cnt  Score   Error  Units
> MethodHandlesArrayConstructor.createWithAnewarray     avgt   15  3.067 ? 0.026  ns/op
> MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15  3.699 ? 0.042  ns/op
> MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  1.447 ? 0.004  ns/op

keep-alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13819#issuecomment-1614138348

From duke at openjdk.org  Fri Jun 30 06:26:53 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 06:26:53 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v5]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <D2o4PP8Ne6Y1Tfj9rMVaslRa3RyKFwVgHHrTzglBG6Y=.a77bad91-93a1-42cd-ba10-f595f2928d09@github.com>

> Speed up Integer.toString with a precomputed cache array of length 1000, use division by 1000, so that each iteration can calculate three digits.  
> 
> this optimization can also be used in StringBuilder#appent(int) and Long#toString.
> 
> # Benchmark Result
> 
> 
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.Integers.toString*"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.811 ? 0.016  us/op
> -Integers.toStringSmall     500  avgt   15  4.794 ? 0.011  us/op
> -Integers.toStringTiny      500  avgt   15  3.752 ? 0.065  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 01 3355d211)
> +Integers.toStringBig       500  avgt   15  5.148 ? 0.044  us/op (+32.30%)
> +Integers.toStringSmall     500  avgt   15  3.820 ? 0.016  us/op (+25.48%)
> +Integers.toStringTiny      500  avgt   15  3.426 ? 0.010  us/op (+9.51%)
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 02 62b499d6)
> +Integers.toStringBig       500  avgt   15  5.971 ? 0.014  us/op (+14.06%)
> +Integers.toStringSmall     500  avgt   15  4.346 ? 0.016  us/op (+10.30%)
> +Integers.toStringTiny      500  avgt   15  3.671 ? 0.019  us/op (+2.20%)
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.762 ? 0.018  us/op
> -Integers.toStringSmall     500  avgt   15  4.481 ? 0.004  us/op
> -Integers.toStringTiny      500  avgt   15  2.761 ? 0.012  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 01 3355d211)
> +Integers.toStringBig       500  avgt   15  4.901 ? 0.005  us/op (+37.97%)
> +Integers.toStringSmall     500  avgt   15  3.515 ? 0.204  us/op (+27.48%)
> +Integers.toStringTiny      500  avgt   15  2.698 ? 0.190  us/op (+2.33%)
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units  (PR Update 02 62b499d6)
> +Integers.toStringBig       500  avgt   15  5.493 ? 0.007  us/op (+23.10%)
> +Integers.toStringSmall     500  avgt   15  3.714 ? 0.006  us/op (+20.65%)
> +Integers.toStringTiny      500  avgt   15  2.786 ? 0.015  us/op (-0.89%)
> 
> 
> 
> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
> * ...

??? has updated the pull request incrementally with one additional commit since the last revision:

  optimization for :
  Integer#toString
  Long#toString
  StringBuilder#append(int)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/484acc69..f4aa1989

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=03-04

  Stats: 111 lines in 3 files changed: 61 ins; 29 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From mli at openjdk.org  Fri Jun 30 06:39:07 2023
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 30 Jun 2023 06:39:07 GMT
Subject: RFR: 8311122: Fix typos in java.base
In-Reply-To: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
References: <muca-H-s7LxbjH1JGEnlpK0bm9cPSdCLOIoONx4Xmyw=.6d7eefd6-c86e-478d-9444-a861f54a5d59@github.com>
Message-ID: <mQZ2t6TPSXIvQKLAnNZ7ZNdYaiBTXwNlIe59ki3J8R4=.26f5fb52-5205-4bfe-a44d-c6c73af6087b@github.com>

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this IDE-assisted typo hunt, which I plan to backport to jdk21.

Marked as reviewed by mli (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14718#pullrequestreview-1506596503

From jlu at openjdk.org  Fri Jun 30 07:40:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:40:01 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v4]
In-Reply-To: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
 <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
Message-ID: <7qATYdYxzCqo0JpV8_YJv25vsM3ZaQ9eHZFhhu3b6sA=.78d55a95-1420-4d85-aeb8-a16ee4f34f3b@github.com>

On Thu, 29 Jun 2023 23:24:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unusued JUnit imports from ValidateISO4217.java
>
> test/jdk/java/util/Currency/ValidateISO4217.java line 82:
> 
>> 80:     // Codes derived from ISO4217 golden-data file
>> 81:     private static final List<Arguments> ISO4217Codes = new ArrayList<Arguments>();
>> 82:     // Additional codes not from the ISO4217 golden-data file
> 
> Are these from the golden file?

Unless I am misinterpreting the question, `additionalCodes` is built from the `extraCodes` array, which contains data that is not found in tablea1.txt(golden file)

> test/jdk/java/util/Currency/ValidateISO4217.java line 96:
> 
>> 94:         setUpISO4217Codes();
>> 95:         setUpAdditionalCodes();
>> 96:         finishTestCurrencies();
> 
> The method name `finish` is kind of confusing. I'd explicitly describe what the method does, i.e, setup `other` currencies.

Renamed it to your suggestion

> test/jdk/java/util/Currency/ValidateISO4217.java line 192:
> 
>> 190:                 /* Defined neither in ISO 4217 nor ISO 3166 list */
>> 191:                 {"XK", "EUR", "978", "2"},      // Kosovo
>> 192:         };
> 
> I'd prefer this array to be placed as static in the class, not within the method.

Fixed, as well as for `otherCodes`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247539421
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247540723
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247540191

From jlu at openjdk.org  Fri Jun 30 07:43:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:43:58 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v4]
In-Reply-To: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
 <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
Message-ID: <TBqm2x3szEGY2wveCjdCAFn7DqqIeTCUwZitXGPH--U=.c8530a36-ab5f-4d46-a873-29ec41b3284b@github.com>

On Thu, 29 Jun 2023 22:38:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unusued JUnit imports from ValidateISO4217.java
>
> test/jdk/java/util/Currency/CurrencyNameProviderTest.java line 43:
> 
>> 41: import static org.junit.jupiter.api.Assertions.assertThrows;
>> 42: 
>> 43: public class CurrencyNameProviderTest {
> 
> Since this is not a generic CurrencyNameProvider test, but specific to the default impl of CNP.getDisplayName(), the class name could be more specific.

I have renamed the file to be more descriptive, but if acronyms are not preferred in file names, I can rename it.

> test/jdk/java/util/Currency/CurrencyTest.java line 241:
> 
>> 239:                 Arguments.of("JOD", 3), Arguments.of("KWD", 3),
>> 240:                 Arguments.of("LYD", 3), Arguments.of("OMR", 3),
>> 241:                 Arguments.of("TND", 3), Arguments.of("TRL", 0), // Turkish Lira
> 
> The turkish lira comment should apply to both TRL and TRY

Yes good point, I have clarified the comment

> test/jdk/java/util/Currency/CurrencyTest.java line 321:
> 
>> 319:         Currency currency2 = Currency.getInstance(currencyCode);
>> 320:         assertEquals(currency1, currency2, "Didn't get same instance for same currency code");
>> 321:         assertEquals(currency1.getCurrencyCode(), currencyCode, "Currency code changed");
> 
> Error message more like "wrong currency code", than "changed"

Updated the err msg

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247544121
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247544370
PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247544313

From jlu at openjdk.org  Fri Jun 30 07:50:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:50:50 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v5]
In-Reply-To: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
Message-ID: <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>

> Please review this PR which refactors Currency tests to use JUnit.
> 
> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
> 
> - Tests are no longer dependent on each other (order of execution does not matter)
> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
> 
> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Further clarification regarding minor undefined currencies
 - Review: Rename MinorUndefinedCodes.java to NoMinorUnitCurrenciesTest.java
 - Review: Update ValidateISO4217.java
 - Review: Rename CurrencyNameProviderTest to be more specific
 - Review: CurrencyTest updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/10d54167..ba3d2e5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=03-04

  Stats: 196 lines in 5 files changed: 96 ins; 92 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

PR: https://git.openjdk.org/jdk/pull/14682

From jlu at openjdk.org  Fri Jun 30 07:50:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 07:50:53 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v4]
In-Reply-To: <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <HWQ_nP5vtkJ-4S8bU0zumRssot6dp27zoC_O8f_E538=.d33f8290-8df6-4e4f-a96b-2611070fb3d6@github.com>
 <rBwNQFpPE6ZziDUiCa2gur8JPHa5r7E-JomRmSG9P6s=.43f22326-c8cc-4c5c-963b-7dc798c68c17@github.com>
Message-ID: <-paG45Ag2Vp53ajYgHdCIch8XdlNMf1oUpQniPqY5Sg=.b4061ca8-da4d-4fbb-96f7-2283784d8317@github.com>

On Thu, 29 Jun 2023 23:07:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unusued JUnit imports from ValidateISO4217.java
>
> test/jdk/java/util/Currency/MinorUndefinedCodes.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 4512215 4818420 4819436 8310923
>> 27:  * @summary Test some minor undefined currencies.
> 
> It'd be more readable something like "currencies without minor units." The class name can also be renamed to something like NoMinorUnitCurrenciesTest

Adjusted the wording throughout the file according to your suggestions

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1247547152

From jlu at openjdk.org  Fri Jun 30 08:01:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 08:01:14 GMT
Subject: RFR: 8310818: Refactor more Locale tests to use JUnit
Message-ID: <miCH8Z8cB2-0N3Hmcd3Q-NlgCnbNGYmT4DT4mJSLOFM=.d080f14a-6453-4383-9eb5-26540df81d6b@github.com>

Please review this PR which refactors additional tests in Locale to use JUnit.

If a test was named bugNNNNNNN.java, it was renamed to something more descriptive.

Below is a list of all the changes

- Refactor and Rename Bug4175998Test.java as ISO639.java
- Refactor and Rename Bug8001562.java as JDK7LocaleServiceDiffs.java
- Refactor and Rename Bug8008577.java as ExpectedAdapterTypes.java
- Refactor Bug8025703.java
- Refactor and Rename Bug8026766.java as LRToString.java
- Refactor and Rename Bug8071929.java as ISO3166.java
- Refactor and Rename Bug8032842.java to PreserveTagCase.java

-------------

Commit messages:
 - Rename Bug8032842.java to PreserveTagCase.java
 - Refactor Bug8032842.java to use JUnit
 - Rename Bug8071929.java as ISO3166.java
 - Refactor Bug8071929.java to use JUnit
 - Rename Bug8026766.java as LRToString.java
 - Refactor Bug8026766.java to use JUnit
 - Merge branch 'master' into MoreLocaleToJUnit
 - Rename Bug4175998Test.java as ISO639.java
 - Refactor Bug4175998Test.java to use JUnit
 - Add comment on outdated status
 - ... and 5 more: https://git.openjdk.org/jdk/compare/7db2f087...f065726e

Changes: https://git.openjdk.org/jdk/pull/14721/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14721&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310818
  Stats: 1350 lines in 12 files changed: 696 ins; 625 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/14721.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14721/head:pull/14721

PR: https://git.openjdk.org/jdk/pull/14721

From mbaesken at openjdk.org  Fri Jun 30 08:19:08 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 08:19:08 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
Message-ID: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>

Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
This is usually just fine and no problem because G1 is the default anyway.
However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

-------------

Commit messages:
 - JDK-8311026

Changes: https://git.openjdk.org/jdk/pull/14722/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14722&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311026
  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14722/head:pull/14722

PR: https://git.openjdk.org/jdk/pull/14722

From sspitsyn at openjdk.org  Fri Jun 30 08:29:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 08:29:07 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <LGmN3wvMUvN2AbrxPjvxO7Cz1XEqohu3yTnGzlCYIw0=.e73fc551-8bba-4705-bd91-cba2c1c4b478@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1506747461

From rgiulietti at openjdk.org  Fri Jun 30 08:34:01 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 30 Jun 2023 08:34:01 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
Message-ID: <4uRnV_Kb5Amn1lPhPLUikeJwoCMJFGZkpLJsAlGncAI=.d43b18a3-210b-455d-bc4c-1a7bfb43a089@github.com>

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Double-checked locking should rely on local variable to avoid racy reads from volatile field.

True. I was mislead because the return statement does not appear in the changeset (the line is textually the same, although it has a different semantics: `keySet` now refers to a local), so I didn't count for it.

In the end, this PR is not about fixing a race, as the title seems to suggest (the original code is correct), but to avoid a volatile read, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1614317093

From dfuchs at openjdk.org  Fri Jun 30 09:13:57 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jun 2023 09:13:57 GMT
Subject: RFR: 8310987: Missing @since tag(s) in
 java/util/logging/ErrorManager.java
Message-ID: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>

Please find here a trivial doc fix to add a missing `@since 1.4` to the java.util.logging.ErrorManager class.

-------------

Commit messages:
 - 8310987

Changes: https://git.openjdk.org/jdk/pull/14725/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14725&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310987
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14725/head:pull/14725

PR: https://git.openjdk.org/jdk/pull/14725

From asotona at openjdk.org  Fri Jun 30 09:57:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Jun 2023 09:57:26 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v7]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <agnWMhYDLijFGdeEO-Ez_eOcHz64220vPlozmqcOZlk=.b9691db0-ad82-4aad-9cc9-b5b3c3c8521a@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/adf79feb..28ee5f35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=05-06

  Stats: 176 lines in 5 files changed: 162 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From mbaesken at openjdk.org  Fri Jun 30 10:02:01 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:01 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <Ykg6Amp7406I2u7bTQig2FG2o_g4ebNwgmWCgPOR_Ow=.2394846a-4734-4faf-8d38-77f05d98b95b@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment in src/java.sql/share/classes/java/sql/DriverManager.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/5d52b4cb..6665f60b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

PR: https://git.openjdk.org/jdk/pull/14593

From mbaesken at openjdk.org  Fri Jun 30 10:02:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
 <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
Message-ID: <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>

On Wed, 28 Jun 2023 13:22:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>>> 
>>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
>> 
>> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.
>
> Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

Hi Alan, I adjusted the comment in DriverManager.java  .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1247686721

From lancea at openjdk.org  Fri Jun 30 10:17:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Jun 2023 10:17:53 GMT
Subject: RFR: 8310987: Missing @since tag(s) in
 java/util/logging/ErrorManager.java
In-Reply-To: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>
References: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>
Message-ID: <gvhtxZWFdkFxbZ3F7dcIK0vp2Td9gLrdi_07OrTJjtg=.3b877083-8500-4553-b4fc-e51c1d57ef38@github.com>

On Fri, 30 Jun 2023 09:06:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a trivial doc fix to add a missing `@since 1.4` to the java.util.logging.ErrorManager class.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14725#pullrequestreview-1506929529

From stsypanov at openjdk.org  Fri Jun 30 10:27:55 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 30 Jun 2023 10:27:55 GMT
Subject: RFR: 8311030: ResourceBundle.handleKeySet() is racy
In-Reply-To: <4uRnV_Kb5Amn1lPhPLUikeJwoCMJFGZkpLJsAlGncAI=.d43b18a3-210b-455d-bc4c-1a7bfb43a089@github.com>
References: <hjFmpRP_bXmUpU_ptit7fUBZTm8Pmk9vHvateqZKmXM=.14839f1e-3bb2-48b7-852c-8ffa5d68f6f6@github.com>
 <4uRnV_Kb5Amn1lPhPLUikeJwoCMJFGZkpLJsAlGncAI=.d43b18a3-210b-455d-bc4c-1a7bfb43a089@github.com>
Message-ID: <twvqnxD71-3aSBZEiggLyWXEsMHaOdAx8zfvEPKeY8s=.965caa69-5f20-4608-9580-f42860b86980@github.com>

On Fri, 30 Jun 2023 08:30:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> In the end, this PR is not about fixing a race, as the title seems to suggest (the original code is correct), but to avoid a volatile read, right?

Yeah, probably I was wrong in my conclusion. Should I rename the ticket?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14692#issuecomment-1614456400

From duke at openjdk.org  Fri Jun 30 10:46:17 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 10:46:17 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v6]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <AG681MPamoS5w-Gq1_2OySkeRFuwheAywBnEb3SLZSY=.b0926fde-f9d8-4141-98e6-c04c2ab0c288@github.com>

> Optimization for:
> 
> Integer.toString
> Long.toString
> StringBuilder#append(int)
> 
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.Integers.toString*" 
> make test TEST="micro:java.lang.Longs.toString*" 
> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt*"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
> 
> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
> 
> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
> 
> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
> 
> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
> 
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
> 
> -Benchmark            (size)  Mode  Cnt   Score   Error  Units (baseline)
> -Longs.toStringBig       500  avgt   15  10.087 ? 0.016  us/op
> -Longs.toStringSmall     500  avgt   15   4.231 ? 0.068  us/op
> 
> -Benchmark                           Mode  Cnt     Score    Error...

??? has updated the pull request incrementally with one additional commit since the last revision:

  format code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/f4aa1989..d1edd3ee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=04-05

  Stats: 17 lines in 1 file changed: 12 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From duke at openjdk.org  Fri Jun 30 10:46:19 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 10:46:19 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v5]
In-Reply-To: <D2o4PP8Ne6Y1Tfj9rMVaslRa3RyKFwVgHHrTzglBG6Y=.a77bad91-93a1-42cd-ba10-f595f2928d09@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <D2o4PP8Ne6Y1Tfj9rMVaslRa3RyKFwVgHHrTzglBG6Y=.a77bad91-93a1-42cd-ba10-f595f2928d09@github.com>
Message-ID: <TUTluf8-gXvM4HXvRXtRvuLQknIWjl3d7d-AvGQg_rM=.d7017fc1-1c55-471f-8bdd-1a629703643b@github.com>

On Fri, 30 Jun 2023 06:26:53 GMT, ??? <duke at openjdk.org> wrote:

>> Optimization for:
>> 
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>> 
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*" 
>> make test TEST="micro:java.lang.Longs.toString*" 
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt*"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
>> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
>> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
>> 
>> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
>> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
>> 
>> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
>> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
>> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
>> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
>> 
>> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
>> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
>> 
>> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
>> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
>> 
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
>> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
>> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
>> 
>> -Benchmark            (size)  Mode  Cnt   Score   Error  Units (baseline)
>> -Longs.toStringBig       500  avgt   15  10.087 ? 0.016  us/op
>> -Longs.toSt...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimization for :
>   Integer#toString
>   Long#toString
>   StringBuilder#append(int)

benchmark data is update, it's ready for review @rgiulietti

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1614472036

From duke at openjdk.org  Fri Jun 30 11:16:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 11:16:10 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v7]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <NXhLqFiD8ERoAIhAkNM8aDFEa00Smf4QiLanIv_gc2Q=.9e36e323-c65c-414d-a7e3-26a3d9331cda@github.com>

> Optimization for:
> 
> Integer.toString
> Long.toString
> StringBuilder#append(int)
> 
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.Integers.toString*" 
> make test TEST="micro:java.lang.Longs.toString*" 
> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt*"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
> 
> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
> 
> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
> 
> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
> 
> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
> 
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
> 
> -Benchmark            (size)  Mode  Cnt   Score   Error  Units (baseline)
> -Longs.toStringBig       500  avgt   15  10.087 ? 0.016  us/op
> -Longs.toStringSmall     500  avgt   15   4.231 ? 0.068  us/op
> 
> -Benchmark                           Mode  Cnt     Score    Error...

??? has updated the pull request incrementally with one additional commit since the last revision:

  format code & comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/d1edd3ee..846cb22b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=05-06

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From tschatzl at openjdk.org  Fri Jun 30 11:30:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 30 Jun 2023 11:30:58 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <9qV2eIvGliad_OWjWBPLTlVRQAItZH7CW4ocxWNiBKY=.c5d60000-9f25-4130-a8f8-7a40a6c57a03@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1507020443

From mbaesken at openjdk.org  Fri Jun 30 11:37:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:37:10 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/6665f60b..9b2232a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

PR: https://git.openjdk.org/jdk/pull/14593

From mbaesken at openjdk.org  Fri Jun 30 11:38:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:38:06 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <DNdVwxC4sLBdysLVmCB1qX4tpWS3RaZAOAP8wki5Imk=.da3eaecf-2ddb-439b-928a-0f2076caa9af@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Hi Thomas and Serguei, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14722#issuecomment-1614525324

From mbaesken at openjdk.org  Fri Jun 30 11:38:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:38:06 GMT
Subject: Integrated: JDK-8311026: Some G1 specific tests do not set
 -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <QSDcoza58IO1fabVgd7FPockuvk3EdR7Zie6h81ec1s=.cc8cc36f-d10e-4b88-bd1f-6c3f6c66e704@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

This pull request has now been integrated.

Changeset: a7d168b5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7d168b522bb05345a40ae1fb18942ba663d3182
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

8311026: Some G1 specific tests do not set -XX:+UseG1GC

Reviewed-by: sspitsyn, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/14722

From briangoetz at openjdk.org  Fri Jun 30 12:24:54 2023
From: briangoetz at openjdk.org (Brian Goetz)
Date: Fri, 30 Jun 2023 12:24:54 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type) [v3]
In-Reply-To: <7ubzbHS_BqvgHxklY3aRqbDUlntOcUNlRDALOKHXwcU=.bbdb193a-e9e3-4047-84c0-9659915e3b69@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
 <7ubzbHS_BqvgHxklY3aRqbDUlntOcUNlRDALOKHXwcU=.bbdb193a-e9e3-4047-84c0-9659915e3b69@github.com>
Message-ID: <GzOoe1ySwpvm1-GmHRvz-YXWcc7M7AmC-6awE06xnQk=.e7d2a1b7-543b-4a28-8272-28b28686205f@github.com>

On Fri, 30 Jun 2023 00:51:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
>> 
>> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix line ending, update corpus test

Marked as reviewed by briangoetz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14705#pullrequestreview-1507092206

From mbaesken at openjdk.org  Fri Jun 30 12:42:53 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 12:42:53 GMT
Subject: [jdk21] RFR: 8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
Message-ID: <lIBG-SnwaigKmGPTr0olt-v0RWKnirL-TA5yubgu2BM=.6075f4e2-6f9a-4fc8-8d42-d41fb9d9602f@github.com>

8310380: Handle problems in core-related tests on macOS when codesign tool does not work

-------------

Commit messages:
 - Backport 39c104df44f17c1d65e35becd4272f73e2c6610c

Changes: https://git.openjdk.org/jdk21/pull/87/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=87&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310380
  Stats: 56 lines in 4 files changed: 37 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk21/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/87/head:pull/87

PR: https://git.openjdk.org/jdk21/pull/87

From liach at openjdk.org  Fri Jun 30 12:54:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 12:54:54 GMT
Subject: RFR: 8311085: Remove implementation detail writeTo from
 LocalVariable(Type) [v3]
In-Reply-To: <7ubzbHS_BqvgHxklY3aRqbDUlntOcUNlRDALOKHXwcU=.bbdb193a-e9e3-4047-84c0-9659915e3b69@github.com>
References: <hhBayhCuF2xJo2qZ7OkMY26xdqYiDGaUQRjM2xqKjGs=.5ace6fd4-d423-4225-a34e-e62c0d5ca6a2@github.com>
 <7ubzbHS_BqvgHxklY3aRqbDUlntOcUNlRDALOKHXwcU=.bbdb193a-e9e3-4047-84c0-9659915e3b69@github.com>
Message-ID: <YfguDFW6-8TCvmzI37eTZ-v7vAWJ4XZeQYO4Ad1GKhU=.6e13e52d-720a-4740-9846-d5f65748dbbd@github.com>

On Fri, 30 Jun 2023 00:51:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which should be implementation details.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html for context.
>> 
>> This patch moves the implementation to `DirectCodeBuilder`'s original use sites; the old `b.canWriteDirect` branch   is redundant, as `writeIndex`'s implementation already performs such an optimization.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix line ending, update corpus test

I will merge this one. Also during development, I found a few other issues:
1. CharacterRangeTable entry writing can be shared, and I wish to move them to this new `AttributeHelpers` as well.
2. CharacterRangeInfo has documentation errors: the ending pc is inclusive instead of exclusive, as seen in Classfile and javac implementations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14705#issuecomment-1614608291

From duke at openjdk.org  Fri Jun 30 12:56:56 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 30 Jun 2023 12:56:56 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v3]
In-Reply-To: <_Tpu8XvjPhvjVA165CRDGuI_rc167JJfpVmIDxnb5rI=.ff79d326-e9fd-4b76-9b15-4567e8f3b247@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <_Tpu8XvjPhvjVA165CRDGuI_rc167JJfpVmIDxnb5rI=.ff79d326-e9fd-4b76-9b15-4567e8f3b247@github.com>
Message-ID: <4ypW9zdICunqrdzAq6a6JgYp-rfRPCbOqDVSTat1LMs=.bcd6e8c5-0368-442f-905f-a9003b54fdc7@github.com>

On Thu, 29 Jun 2023 22:53:10 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Overhaul LTQ and SQ to use common blocking and matching mechanics

src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 115:

> 113:      * indicating whether to act as some form of offer, put, poll,
> 114:      * take, or transfer (each possibly with timeout), as described
> 115:      * bwlow.

@DougLea Small typo?s/bwlow/below

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1247831262

From dl at openjdk.org  Fri Jun 30 13:02:56 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 30 Jun 2023 13:02:56 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v3]
In-Reply-To: <4ypW9zdICunqrdzAq6a6JgYp-rfRPCbOqDVSTat1LMs=.bcd6e8c5-0368-442f-905f-a9003b54fdc7@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <_Tpu8XvjPhvjVA165CRDGuI_rc167JJfpVmIDxnb5rI=.ff79d326-e9fd-4b76-9b15-4567e8f3b247@github.com>
 <4ypW9zdICunqrdzAq6a6JgYp-rfRPCbOqDVSTat1LMs=.bcd6e8c5-0368-442f-905f-a9003b54fdc7@github.com>
Message-ID: <sodxNJI2u6tda2SXOktkFcbkhaxhapsP8slws7HBqE0=.6951852a-556c-4a5b-82b9-ba44878b74d2@github.com>

On Fri, 30 Jun 2023 12:54:37 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Overhaul LTQ and SQ to use common blocking and matching mechanics
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 115:
> 
>> 113:      * indicating whether to act as some form of offer, put, poll,
>> 114:      * take, or transfer (each possibly with timeout), as described
>> 115:      * bwlow.
> 
> @DougLea Small typo?s/bwlow/below

Thanks. I'm in the midst of a cleanup pass that better explains changes, and fixes a test bug, and hopefully improves some code clarity

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1247836747

From asotona at openjdk.org  Fri Jun 30 13:17:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 30 Jun 2023 13:17:26 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v8]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <EC4fgvIj5RbHdRs7dWE-dNsh4IKxulMBgrZrsu3UctU=.30d64530-f510-4b31-a766-881c568e6567@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added DydnamicConstantPoolEntry::bootstrapMethodIndex
  fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11411/files
  - new: https://git.openjdk.org/jdk/pull/11411/files/28ee5f35..834de482

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=06-07

  Stats: 14 lines in 3 files changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From liach at openjdk.org  Fri Jun 30 13:18:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 13:18:11 GMT
Subject: RFR: 8311172: Classfile.PREVIEW_MINOR_VERSION doesn't match that read
 from class files
Message-ID: <L_EN0XDnpbMvBe2jijx1WID-983acfSY0uY7muNEdAY=.00445838-19c2-4fe2-b8d1-10e7dc00f1fb@github.com>

`Classfile.PREVIEW_MINOR_VERSION`, currently -1, is correct when passed to `ClassBuilder::withVersion`, but is incorrect when compared to `ClassModel::minorVersion`, which only sets the bits of 2 lowest bytes to 1 (65536). Discovered when trying to replace an asserted preview minor version with this constant in `PreviewHiddenClass` test porting in #13009, which is currently failing.

Requesting a review from @asotona.

-------------

Commit messages:
 - Include bug ID
 - Fix preview minor version not equal to that obtained from ClassModel

Changes: https://git.openjdk.org/jdk/pull/14731/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14731&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311172
  Stats: 65 lines in 2 files changed: 64 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14731.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14731/head:pull/14731

PR: https://git.openjdk.org/jdk/pull/14731

From duke at openjdk.org  Fri Jun 30 13:27:11 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 13:27:11 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v8]
In-Reply-To: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
Message-ID: <SDqmZ6Z39MoWNRWnre18AMhvv8tvjfoStMy8DIay-Uc=.5a7eae71-9985-4c5e-a91a-7484a8f61477@github.com>

> Optimization for:
> Integer.toString
> Long.toString
> StringBuilder#append(int)
> 
> # Benchmark Result
> 
> 
> sh make/devkit/createJMHBundle.sh
> bash configure --with-jmh=build/jmh/jars
> make test TEST="micro:java.lang.Integers.toString*" 
> make test TEST="micro:java.lang.Longs.toString*" 
> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8"
> 
> 
> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
> * cpu : intel xeon sapphire rapids (x64)
> 
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
> 
> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
> 
> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
> 
> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
> 
> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
> 
> 
> 
> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
> * cpu : amd epc genoa (x64)
> 
> ``` diff
> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
> 
> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
> +Integers.toStringBig       500  avgt   15  5.036 ? 0.005  us/op (+34.09%)
> +Integers.toStringSmall     500  avgt   15  3.491 ? 0.025  us/op (+28.04%)
> +Integers.toStringTiny      5...

??? has updated the pull request incrementally with one additional commit since the last revision:

  simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14699/files
  - new: https://git.openjdk.org/jdk/pull/14699/files/846cb22b..dd13911a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14699&range=06-07

  Stats: 18 lines in 2 files changed: 4 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14699.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14699/head:pull/14699

PR: https://git.openjdk.org/jdk/pull/14699

From liach at openjdk.org  Fri Jun 30 14:50:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 14:50:59 GMT
Subject: RFR: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl
Message-ID: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>

As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.

Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

-------------

Commit messages:
 - Convert asByteBuffer to an internal API

Changes: https://git.openjdk.org/jdk/pull/14736/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311175
  Stats: 9 lines in 4 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14736/head:pull/14736

PR: https://git.openjdk.org/jdk/pull/14736

From dcubed at openjdk.org  Fri Jun 30 15:21:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 15:21:10 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Ending the file with a blank line? I would not have expected that at all.
I expect a single EOL at the end of the file; from a visual POV, the last
line of non-blank text ends with an EOL. No more, no less.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396

From iris at openjdk.org  Fri Jun 30 15:33:55 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 30 Jun 2023 15:33:55 GMT
Subject: RFR: 8310987: Missing @since tag(s) in
 java/util/logging/ErrorManager.java
In-Reply-To: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>
References: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>
Message-ID: <USJeYfE2yqtvyC-1w_M0FwBKMIEonGQS-bEDomwHugM=.2efcbd5a-421d-448b-a594-9bf1d46cd509@github.com>

On Fri, 30 Jun 2023 09:06:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a trivial doc fix to add a missing `@since 1.4` to the java.util.logging.ErrorManager class.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14725#pullrequestreview-1507420123

From javalists at cbfiddle.com  Fri Jun 30 15:42:53 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 30 Jun 2023 08:42:53 -0700
Subject: jpackage code signing identity
In-Reply-To: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>
References: <BE613D22-AC19-46BF-AE99-4A864781B7C8@cbfiddle.com>
Message-ID: <2AB1D2AA-F158-4BD6-9A8A-8122A833313A@cbfiddle.com>

I would still like to hear from someone on the jpackage team about this issue...

> On Jun 25, 2023, at 8:21 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> I?m having trouble using the code signing feature of jpackage for macOS.
> 
> The problem appears to be here:
> 
> result = MacBaseInstallerBundler.findKey(
>                             "Developer ID Application: ", user, keychain);
>                     }
> 
>      boolean useAsIs = teamName.startsWith(keyPrefix)
>                 || teamName.startsWith("Developer ID")
>                 || teamName.startsWith("3rd Party Mac");
> 
>         String key = (useAsIs) ? teamName : (keyPrefix + teamName);
> 
> 
> 
> My certificate has a different prefix ?Apple Development: ? in the keychain.
> I don?t think I made this up, so I don?t think I should try to change it.
> 
> Why is jpackage being so restrictive in its lookup of the signing key?
> Why doesn?t it just pass the string to codesign, which has its own rules for interpreting signing identities (see below)?
> 
> I typically use the 10 character alphanumeric key that is part of the name when I use codesign directly.
> 
> The identity is first considered as the full name of a keychain identity preference. If such a preference exists, it directly names the identity used. Otherwise, the identity is located by searching all keychains for a certificate whose subject common name (only) contains the identity string given. If there are multiple matches, the operation fails and no signing is performed; however, an exact match is preferred over a partial match. These comparisons are case sensitive. Multiple instances of the exactly same certificate in multiple keychains are tolerated as harmless.
> If identity consists of exactly forty hexadecimal digits, it is instead interpreted as the SHA-1 hash of the certificate part of the desired identity. In this case, the identity's subject name is not considered.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230630/aae0e288/attachment.htm>

From dfuchs at openjdk.org  Fri Jun 30 16:10:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 30 Jun 2023 16:10:08 GMT
Subject: Integrated: 8310987: Missing @since tag(s) in
 java/util/logging/ErrorManager.java
In-Reply-To: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>
References: <xbwoJRGxwa6RX2-iRxIk45dyl-a2hdfgXuXqkkPCXf8=.855f36e7-5548-4367-b0e7-8e70f30ed701@github.com>
Message-ID: <OZSde9unTJ40xwPWdm9Vee-ZsUiaYe49xjE5VHoUY3U=.8096cc0b-ee21-4962-97d1-419348e12d89@github.com>

On Fri, 30 Jun 2023 09:06:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a trivial doc fix to add a missing `@since 1.4` to the java.util.logging.ErrorManager class.

This pull request has now been integrated.

Changeset: e8ff74c7
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8ff74c7e84ec2440a51fee1b4c45e87332807a0
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8310987: Missing @since tag(s) in java/util/logging/ErrorManager.java

Reviewed-by: lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/14725

From naoto at openjdk.org  Fri Jun 30 16:27:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Jun 2023 16:27:56 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v5]
In-Reply-To: <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>
Message-ID: <tjJnXGZZThGFPWMIsUrNaZbb4ZUyUQAEXvtClfJdBqM=.1a7775cc-2b85-4af0-a857-761a3c9dc0e1@github.com>

On Fri, 30 Jun 2023 07:50:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors Currency tests to use JUnit.
>> 
>> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
>> 
>> - Tests are no longer dependent on each other (order of execution does not matter)
>> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
>> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
>> 
>> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Further clarification regarding minor undefined currencies
>  - Review: Rename MinorUndefinedCodes.java to NoMinorUnitCurrenciesTest.java
>  - Review: Update ValidateISO4217.java
>  - Review: Rename CurrencyNameProviderTest to be more specific
>  - Review: CurrencyTest updates

test/jdk/java/util/Currency/CurrencyTest.java line 243:

> 241:                 // Old and New Turkish Lira
> 242:                 Arguments.of("TRL", 0), Arguments.of("TRY", 2),
> 243:                 Arguments.of("TND", 3)

Probably `TND` moving upward before the comment would be clearer, like:

                Arguments.of("LYD", 3), Arguments.of("OMR", 3),
                Arguments.of("TND", 3),

                // Old and New Turkish Lira
                Arguments.of("TRL", 0), Arguments.of("TRY", 2)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1248059699

From jlu at openjdk.org  Fri Jun 30 16:49:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 16:49:22 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v6]
In-Reply-To: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
Message-ID: <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>

> Please review this PR which refactors Currency tests to use JUnit.
> 
> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
> 
> - Tests are no longer dependent on each other (order of execution does not matter)
> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
> 
> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: Adjust data provider regarding Turkish Lira

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14682/files
  - new: https://git.openjdk.org/jdk/pull/14682/files/ba3d2e5d..0ada95ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14682&range=04-05

  Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14682/head:pull/14682

PR: https://git.openjdk.org/jdk/pull/14682

From jlu at openjdk.org  Fri Jun 30 16:49:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 Jun 2023 16:49:22 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v5]
In-Reply-To: <tjJnXGZZThGFPWMIsUrNaZbb4ZUyUQAEXvtClfJdBqM=.1a7775cc-2b85-4af0-a857-761a3c9dc0e1@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <UqOz1g9rUo_Oju1onM43XnqrFbHC20VfC4lvB2rG5jg=.835ae9bd-6ff2-41d2-84bf-b19ac249279b@github.com>
 <tjJnXGZZThGFPWMIsUrNaZbb4ZUyUQAEXvtClfJdBqM=.1a7775cc-2b85-4af0-a857-761a3c9dc0e1@github.com>
Message-ID: <cQvVUIwoOIU3GT4nXGzE3NaP0n15J-KJfx0MI-DzRCk=.b7e5db2c-c776-46f0-9d00-240512dd6c2b@github.com>

On Fri, 30 Jun 2023 16:22:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Further clarification regarding minor undefined currencies
>>  - Review: Rename MinorUndefinedCodes.java to NoMinorUnitCurrenciesTest.java
>>  - Review: Update ValidateISO4217.java
>>  - Review: Rename CurrencyNameProviderTest to be more specific
>>  - Review: CurrencyTest updates
>
> test/jdk/java/util/Currency/CurrencyTest.java line 243:
> 
>> 241:                 // Old and New Turkish Lira
>> 242:                 Arguments.of("TRL", 0), Arguments.of("TRY", 2),
>> 243:                 Arguments.of("TND", 3)
> 
> Probably `TND` moving upward before the comment would be clearer, like:
> 
>                 Arguments.of("LYD", 3), Arguments.of("OMR", 3),
>                 Arguments.of("TND", 3),
> 
>                 // Old and New Turkish Lira
>                 Arguments.of("TRL", 0), Arguments.of("TRY", 2)

Adjusted `TND` upwards

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14682#discussion_r1248079845

From naoto at openjdk.org  Fri Jun 30 16:54:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 Jun 2023 16:54:57 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v6]
In-Reply-To: <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
Message-ID: <pJ2Q3h6pQuW1C5IMJqJCxJ-TMHEoef97nZJIEe2shsk=.937aebc2-23fa-4f37-9d48-6507b1d97fd3@github.com>

On Fri, 30 Jun 2023 16:49:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors Currency tests to use JUnit.
>> 
>> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
>> 
>> - Tests are no longer dependent on each other (order of execution does not matter)
>> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
>> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
>> 
>> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Adjust data provider regarding Turkish Lira

LGTM. Thanks for the refactoring

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14682#pullrequestreview-1507553074

From lancea at openjdk.org  Fri Jun 30 17:13:55 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 30 Jun 2023 17:13:55 GMT
Subject: RFR: 8310923: Refactor Currency tests to use JUnit [v6]
In-Reply-To: <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
References: <xpHU_E-4xHtXsWCrAn8jvMGCgEbBR_1RpxO_8-jgDAs=.5a55f933-d26d-4b5d-a687-6682178c42d6@github.com>
 <NHsvdbrqLFoBSCLVF9MnM_xu29mJZLx4mxyK9QqXBCs=.335abb34-439a-41f2-bde8-ca4025055a66@github.com>
Message-ID: <f3LMF0nU_RqVmIIDItYPUNL0elTbj8bEWoebZjpFvoI=.523f5038-5ad4-4d39-a366-b4fe58ccd432@github.com>

On Fri, 30 Jun 2023 16:49:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors Currency tests to use JUnit.
>> 
>> The most significant change occurs in `ValidateISO4217.java`. Other changes to this file excluding the JUnit refactoring include
>> 
>> - Tests are no longer dependent on each other (order of execution does not matter)
>> - Testing does not occur at the same time as data generation (The data is fully generated before any tests are executed)
>> - Various cleanup (dead-code, clarifying comments, more descriptive method and var names)
>> 
>> `Bug4512215.java` now renamed to `MinorUndefinedCodes` was updated to remove redundant testing, and the file changed to focus on testing minor undefined currency codes instead.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Adjust data provider regarding Turkish Lira

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14682#pullrequestreview-1507578660

From cjplummer at openjdk.org  Fri Jun 30 17:48:58 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 Jun 2023 17:48:58 GMT
Subject: [jdk21] RFR: 8310380: Handle problems in core-related tests on
 macOS when codesign tool does not work
In-Reply-To: <lIBG-SnwaigKmGPTr0olt-v0RWKnirL-TA5yubgu2BM=.6075f4e2-6f9a-4fc8-8d42-d41fb9d9602f@github.com>
References: <lIBG-SnwaigKmGPTr0olt-v0RWKnirL-TA5yubgu2BM=.6075f4e2-6f9a-4fc8-8d42-d41fb9d9602f@github.com>
Message-ID: <7AuiE6DnZFzTUjtP3IyLiYZsrpKjQHBpfaBpsckI-eo=.aca11b77-6690-462e-b227-82cb90896cd1@github.com>

On Fri, 30 Jun 2023 12:35:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8310380: Handle problems in core-related tests on macOS when codesign tool does not work

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/87#pullrequestreview-1507621309

From mchung at openjdk.org  Fri Jun 30 17:50:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Jun 2023 17:50:57 GMT
Subject: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may
 be shared [v2]
In-Reply-To: <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
References: <Xg_3M5zOSJ1jkh8AautlA8g-26ju7SrI1AEebgwiCbo=.a3f225e2-2807-4ff2-b727-b695c3d07de1@github.com>
 <w8y-x_u0M6ZYanFXvIkiMhfEsQ76P0M1Fc_4zq8lZIw=.ecce0329-f356-422a-8571-a1ac1d954ec9@github.com>
Message-ID: <oo8ioWDux3g2ISV5aUMFzBzJJs5ediM8vvVQW_Qy3m4=.89108686-498a-4f70-9f71-019539e0b979@github.com>

On Thu, 29 Jun 2023 18:24:33 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent caching scheme for Carrier objects. The technique used is generally useful for a variety of caching schemes and is being moved to be shared in other parts of the jdk. The MethodType interning case is one example.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove warning tied to String Templates

MethodType's `ConcurrentWeakInternSet` uses `NativeReferenceQueue` which uses native monitors (that was added for virtual threads).   This change uses the reference queue using j.u.c locks.   Has you confirmed that this is not an issue?     Or `ReferencedKeySet` can take a parameter to specify using the native reference queue?

In `ReferencedKey::equals` method, can use `Reference::refersTo` instead of `Objects.equals`.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 899:

> 897:             return equals(mt);
> 898:         }
> 899:         if (x instanceof ConcurrentWeakInternSet.WeakEntry<?> e

The comment above about `WeakEntry` should also be removed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14684#pullrequestreview-1507601740
PR Review Comment: https://git.openjdk.org/jdk/pull/14684#discussion_r1248115440

From mchung at openjdk.org  Fri Jun 30 18:12:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Jun 2023 18:12:18 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock
 for non-parallel capable loader [v3]
In-Reply-To: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
References: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
Message-ID: <Y8-h7qKbxinuBO4dET4dwbZGTwRa0RKgRFN2Qq6tb6Y=.cf454cfe-c10a-4bcc-b4f2-3d95634b8d82@github.com>

> The spec of `ClassLoader::getClassLoadingLock` is unclear that this method is intended for parallel-capable class loader implementations to provide an alternate implementation.   For non-parallel-capable class loaders, this method should return this `ClassLoader` object.   The javadoc uses "the default implementation" which could be interpreted that non-parallel-capable class loaders can also override this implementation, which is not the intent.  See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  make it implSpec per CSR review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14720/files
  - new: https://git.openjdk.org/jdk/pull/14720/files/e9607f4a..2969ea34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14720&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14720&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14720/head:pull/14720

PR: https://git.openjdk.org/jdk/pull/14720

From darcy at openjdk.org  Fri Jun 30 19:13:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Jun 2023 19:13:53 GMT
Subject: RFR: 8254566: Clarify the spec of ClassLoader::getClassLoadingLock
 for non-parallel capable loader [v3]
In-Reply-To: <Y8-h7qKbxinuBO4dET4dwbZGTwRa0RKgRFN2Qq6tb6Y=.cf454cfe-c10a-4bcc-b4f2-3d95634b8d82@github.com>
References: <azEPjWXGKVzYLXba2jo1nSH6eT2yL8nV0EN_yf7cRtk=.be6ba43e-73bb-45e7-8b2c-3a4f86be2fb7@github.com>
 <Y8-h7qKbxinuBO4dET4dwbZGTwRa0RKgRFN2Qq6tb6Y=.cf454cfe-c10a-4bcc-b4f2-3d95634b8d82@github.com>
Message-ID: <xVAtctXse3RSWQgmxK7iKRufdLn_78y6pWmM-KhSUak=.1c78127a-205d-4318-8b53-22825dbceff7@github.com>

On Fri, 30 Jun 2023 18:12:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The spec of `ClassLoader::getClassLoadingLock` is unclear that this method is intended for parallel-capable class loader implementations to provide an alternate implementation.   For non-parallel-capable class loaders, this method should return this `ClassLoader` object.   The javadoc uses "the default implementation" which could be interpreted that non-parallel-capable class loaders can also override this implementation, which is not the intent.  See https://openjdk.org/groups/core-libs/ClassLoaderProposal.html.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make it implSpec per CSR review feedback

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14720#pullrequestreview-1507765781

From dl at openjdk.org  Fri Jun 30 19:33:01 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 30 Jun 2023 19:33:01 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v4]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <q-LHBfSpYcszzPvSRTHhlGdlH2ZuzAndffbbkJMvjOU=.689beb68-e00d-453d-884e-18dd41a8c699@github.com>

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

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 four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8301341
 - Overhaul LTQ and SQ to use common blocking and matching mechanics
 - Merge branch 'openjdk:master' into JDK-8301341
 - Use Thread.isVirtual to distinguish spin vs immediate block cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/67a145a0..71b9c8bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=02-03

  Stats: 565 lines in 23 files changed: 471 ins; 57 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/14317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14317/head:pull/14317

PR: https://git.openjdk.org/jdk/pull/14317

From dl at openjdk.org  Fri Jun 30 19:38:19 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 30 Jun 2023 19:38:19 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v5]
In-Reply-To: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
Message-ID: <7Imcm_Lg2tLsQs1UdndLA6xKrfRBSTRThh3LcULgpzY=.245e0de8-1035-4778-851d-12bd3d43559f@github.com>

> This now uses Thread.isVirtual to distinguish spin vs immediate block cases, enabling re-introduction of spin control from the previous version, removing anomalies like this one.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Fix inverted test assert; improve internal documentation; simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14317/files
  - new: https://git.openjdk.org/jdk/pull/14317/files/71b9c8bf..2f591a0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14317&range=03-04

  Stats: 144 lines in 3 files changed: 46 ins; 44 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/14317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14317/head:pull/14317

PR: https://git.openjdk.org/jdk/pull/14317

From dl at openjdk.org  Fri Jun 30 19:38:20 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 30 Jun 2023 19:38:20 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v3]
In-Reply-To: <sodxNJI2u6tda2SXOktkFcbkhaxhapsP8slws7HBqE0=.6951852a-556c-4a5b-82b9-ba44878b74d2@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <_Tpu8XvjPhvjVA165CRDGuI_rc167JJfpVmIDxnb5rI=.ff79d326-e9fd-4b76-9b15-4567e8f3b247@github.com>
 <4ypW9zdICunqrdzAq6a6JgYp-rfRPCbOqDVSTat1LMs=.bcd6e8c5-0368-442f-905f-a9003b54fdc7@github.com>
 <sodxNJI2u6tda2SXOktkFcbkhaxhapsP8slws7HBqE0=.6951852a-556c-4a5b-82b9-ba44878b74d2@github.com>
Message-ID: <aMjQZVBO-WmNlTb8P_BBC2omyNTCYWBxTFcZxrp-nUY=.6eb5603e-c683-4034-81c2-a829e1859e60@github.com>

On Fri, 30 Jun 2023 13:00:27 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java line 115:
>> 
>>> 113:      * indicating whether to act as some form of offer, put, poll,
>>> 114:      * take, or transfer (each possibly with timeout), as described
>>> 115:      * bwlow.
>> 
>> @DougLea Small typo?s/bwlow/below
>
> Thanks. I'm in the midst of a cleanup pass that better explains changes, and fixes a test bug, and hopefully improves some code clarity

... which I just did, so hopefully easier to read through

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14317#discussion_r1248222376

From darcy at openjdk.org  Fri Jun 30 21:06:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Jun 2023 21:06:23 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
Message-ID: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>

Going over some old issues and found this RFE, posting without any tests or a CSR first to get some feedback on the overall API.

-------------

Commit messages:
 - JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types

Changes: https://git.openjdk.org/jdk/pull/14743/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6361826
  Stats: 37 lines in 1 file changed: 37 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14743/head:pull/14743

PR: https://git.openjdk.org/jdk/pull/14743

From darcy at openjdk.org  Fri Jun 30 21:06:23 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Jun 2023 21:06:23 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <TzMQwqu_aJChDiNXtfm1FWI1Kuq6utkQCXCdVYAAO9w=.dea1b36e-8612-4140-8b3f-b243b85ce0ae@github.com>

On Fri, 30 Jun 2023 20:57:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Going over some old issues and found this RFE, posting without any tests or a CSR first to get some feedback on the overall API.

Not present in the PR as written, but it would be possible to introduce a sealed interface PrimitiveType that the wrapper classes implemented so that the return type of forPrimitiveName could be Class<? extends PrimitiveType> rather than Class<?>.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1615192869

From duke at openjdk.org  Fri Jun 30 21:15:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 30 Jun 2023 21:15:27 GMT
Subject: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]
In-Reply-To: <khRV0W3WP67ls17pUpB3xH5oihM16kzV45W1r0wsqUA=.a96b4ba7-f98a-4bc0-b855-733ea14c91ec@github.com>
References: <-5jK4GL6WHgJXAA5a2-q2wnB41XUgNqT98FFm1T1_mU=.e7844739-b911-48e8-b29e-f9a85c4490fb@github.com>
 <1JFLx0ljHgVHmjPbs3KmEK09uAyOFuwGntKCP5IRSUw=.3f948a63-cb46-4cb1-89c0-37758ff2fd46@github.com>
 <khRV0W3WP67ls17pUpB3xH5oihM16kzV45W1r0wsqUA=.a96b4ba7-f98a-4bc0-b855-733ea14c91ec@github.com>
Message-ID: <HDTz51ZPGpQuVQCfn6g40idvmPbG44WqRp4HDVN3UVM=.df608b19-f8a1-465a-9603-95d47337c7c4@github.com>

On Thu, 29 Jun 2023 13:45:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix comments typo
>>  - Update full name
>
> src/java.base/share/classes/java/util/HexDigits.java line 108:
> 
>> 106:      * Combine two hex shorts into one int based on big endian
>> 107:      */
>> 108:     static int digit(int b0, int b1) {
> 
> The method name `digit` is not very informative.
> As it is package private it should be more descriptive and describe the parameters and result.
> Perhaps `packDigits` or `encodeAndPackHexDigits`.

can you create a new issue and i continue improving?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14578#discussion_r1248288730

From darcy at openjdk.org  Fri Jun 30 21:21:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 30 Jun 2023 21:21:55 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <C01jlPvEPtEAQT4fCtqUPDcQSuH2N6PsZYEHbBlhdsg=.f4871193-6df3-4df2-b12f-b7d6a6e094db@github.com>

On Fri, 30 Jun 2023 20:57:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Going over some old issues and found this RFE, posting without any tests or a CSR first to get some feedback on the overall API.

Besides whether or not the method itself is worth adding, I think the main design question if on a name that is not a primitive type the method should return null or throw an exception. The existing forName method have both policies. It seems to me more of a semantic error when using this particular method to give it a non-primitive name so I coded it to throw an exception, but I'd be willing to consider returning null instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1615204830

From mchung at openjdk.org  Fri Jun 30 21:34:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Jun 2023 21:34:27 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v19]
In-Reply-To: <ZbsMg67GdEn7H-M9MumzGijPaD9htHOiNG31prqSNLI=.79eb7851-f7b7-482c-a5fa-b81440be4210@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <ZbsMg67GdEn7H-M9MumzGijPaD9htHOiNG31prqSNLI=.79eb7851-f7b7-482c-a5fa-b81440be4210@github.com>
Message-ID: <21DGKNCTUJdtCO93tw7Kz97_-ox9hzxVfl8NepLEroo=.e2419104-57cf-441d-b2eb-287341dd57d8@github.com>

On Thu, 29 Jun 2023 03:16:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Code cleanup, thanks mandy!
>  - Merge branch 'master' of https://github.com/openjdk/jdk into explore/mhp-iface
>  - 1. Change WRAPPER_TYPES to WeakHashMap to accurately determine if the given class is
>       the proxy class
>    
>    Discussion:
>    2. I dropped ProxyClassInfo and use Lookup just to see the simplication.
>       If wrapperInstanceTarget and wrapperInstanceType are frequently called, it makes
>       sense to cache the method handles.
>    
>    3. Should it use SoftReference or WeakReference?  It depends if asInterfaceInstance
>       will be used heavily.
>    
>    3. I also dropped SamInfo and getStats as it can be inlined in the caller, which
>       I think it's clearer to see what it does in place.
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/6f58ab2b...340b0751

This looks quite good.  I have some comments below.  Also pushed some of my suggestion to my [mh-proxies](https://github.com/mlchung/jdk/tree/mh-proxies) branch.

I'd like to have a test to verify that  `isWrapperInstance` and other `wrapperXXX` methods determine a random object whose class happens to have the same fields as the wrapper class expects but not a wrapper instance.

I will review BasicTest in details next.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 226:

> 224:          * The hidden classes defined for I is defined in a dynamic module M
> 225:          * which has access to the types referenced by the members of I including
> 226:          * the parameter types, return type and exception types.

This comment can be moved to where it creates the dynamic module.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 241:

> 239:     }
> 240: 
> 241:     private record LocalMethodInfo(MethodTypeDesc desc, List<ClassDesc> thrown, String fieldName) {}

Perhaps a simpler name `MethodInfo`

Suggestion:

    private record MethodInfo(MethodTypeDesc desc, List<ClassDesc> thrown, String fieldName) {}

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 247:

> 245: 
> 246:     private static final Set<Class<?>> WRAPPER_TYPES = Collections.newSetFromMap(new WeakHashMap<>());
> 247:     private static final ClassValue<SoftReference<Lookup>> PROXY_LOOKUPS = new ClassValue<>() {

Let's use weak references for this implementation so that the hidden classes can be unloaded when it becomes weakly reachable.  We can reevaluate this when we get more feedback on this usage.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 265:

> 263:                     continue;
> 264: 
> 265:                 String mname = m.getName();

Better documentation, more comments, would be helpful.   Some suggestions below.

Suggestion:

                // ensure it's SAM interface
                String mname = m.getName();

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 284:

> 282:                             Stream.concat(DEFAULT_RETHROWS.stream(),
> 283:                                     Arrays.stream(thrown).map(MethodHandleProxies::desc)).distinct().toList();
> 284:                     methods.add(new LocalMethodInfo(mtDesc, exceptionTypeDescs, fieldName));

Suggestion:

                var exceptionTypeDescs =
                     thrown.length == 0 ? DEFAULT_RETHROWS
                                        : Stream.concat(DEFAULT_RETHROWS.stream(),
                                                        Arrays.stream(thrown).map(MethodHandleProxies::desc))
                                                .distinct().toList();
                methods.add(new MethodInfo(desc(mt), exceptionTypeDescs, fieldName));

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 297:

> 295: 
> 296:             var loader = intfc.getClassLoader();
> 297:             Module targetModule = newDynamicModule(loader, referencedTypes);

Suggestion:

            // create a dynamic module for each proxy class, which needs access
            // to the types referenced by the members of the interface including
            // the parameter types, return type and exception types
            var loader = intfc.getClassLoader();
            Module targetModule = newDynamicModule(loader, referencedTypes);

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 306:

> 304:             ClassDesc proxyDesc = ClassDesc.of(cn);
> 305:             byte[] template = createTemplate(loader, proxyDesc, desc(intfc), uniqueName, methods);
> 306:             var definer = new Lookup(intfc).makeHiddenClassDefiner(cn, template, Set.of(), DUMPER);

Suggestion:

            // define the dynamic module to the class loader of the interface
            var definer = new Lookup(intfc).makeHiddenClassDefiner(cn, template, Set.of(), DUMPER);

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 336:

> 334:     private static final ClassDesc CD_IllegalAccessException = desc(IllegalAccessException.class);
> 335:     private static final MethodTypeDesc MTD_void_Throwable = MethodTypeDesc.of(CD_void, CD_Throwable);
> 336:     private static final MethodType MT_void_Lookup_MethodHandle_MethodHandle = methodType(void.class, Lookup.class, MethodHandle.class, MethodHandle.class);

Several of these MethodType declarations are long lines that can be wrapped.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 347:

> 345:     private static final MethodTypeDesc MTD_void_String = MethodTypeDesc.of(CD_void, CD_String);
> 346:     private static final String ORIGINAL_TARGET_NAME = "originalTarget";
> 347:     private static final String ORIGINAL_TYPE_NAME = "originalType";

Can drop "original" prefix?

Suggestion:

    private static final String TARGET_NAME = "target";
    private static final String TYPE_NAME = "interfaceType";

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 367:

> 365:             clb.withInterfaceSymbols(ifaceDesc);
> 366: 
> 367:             // individual handle fields

Suggestion:

            // static and instance fields

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 381:

> 379:             });
> 380: 
> 381:             // <init>(Lookup, MethodHandle originalHandle, MethodHandle implHandle)

Suggestion:

            // <init>(Lookup, MethodHandle target, MethodHandle callerBoundTarget)

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 386:

> 384:                 cob.invokespecial(CD_Object, INIT_NAME, MTD_void);
> 385: 
> 386:                 // WrapperInstance.ensureOriginalLookup

Suggestion:

                // call ensureOriginalLookup to verify the given Lookup has access

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 391:

> 389: 
> 390:                 // keep original target
> 391:                 // this.originalTarget = originalHandle;

Suggestion:

                // this.target = target;

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 396:

> 394:                 cob.putfield(proxyDesc, ORIGINAL_TARGET_NAME, CD_MethodHandle);
> 395: 
> 396:                 // convert individual handles

Suggestion:

                // adjust the callerBoundTarget to the method type for each method

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 398:

> 396:                 // convert individual handles
> 397:                 for (var mi : methods) {
> 398:                     // this.handleField = implHandle.asType(xxType);

Suggestion:

                    // this.m<i> = callerBoundTarget.asType(xxType);

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 410:

> 408:             });
> 409: 
> 410:             clb.withMethodBody(ENSURE_ORIGINAL_LOOKUP, MTD_void_Lookup, ACC_PRIVATE | ACC_STATIC, cob -> {

Suggestion:

+            // void ensureOriginalLookup(Lookup) checks if the given Lookup has ORIGINAL
+            // access to this class, i.e. the lookup class is this class; otherwise,
+            // IllegalAccessException is thrown
            clb.withMethodBody(ENSURE_ORIGINAL_LOOKUP, MTD_void_Lookup, ACC_PRIVATE | ACC_STATIC, cob -> {

test/jdk/java/lang/invoke/MethodHandleProxies/ProxyForMethodHandleTest.java line 34:

> 32: import org.junit.jupiter.api.Test;
> 33: 
> 34: /*

Add `@bug` tag

test/jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java line 37:

> 35:     public static void main(String... args) {
> 36:         var originalMh = MethodHandles.zero(void.class);
> 37:         Object o = MethodHandleProxies.asInterfaceInstance(Untrusted.class, originalMh);

Is it better to define an interface in this test?   It seems that this test has nothing to do with Untrusted.  It may confuse readers.

test/jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java line 42:

> 40:         assert originalMh == untrustedTarget : "Got " + untrustedTarget;
> 41: 
> 42:         var runnableTarget = MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, originalMh));

please break this long line.  Perhaps adding a local variable may make it easy to read too.

test/jdk/java/lang/invoke/MethodHandleProxies/WithSecurityManagerTest.java line 42:

> 40:         assert originalMh == untrustedTarget : "Got " + untrustedTarget;
> 41: 
> 42:         var runnableTarget = MethodHandleProxies.wrapperInstanceTarget(MethodHandleProxies.asInterfaceInstance(Runnable.class, originalMh));

Just to be completed, also add test cases for `isWrapperInstance` and `wrapperInstanceType`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13197#pullrequestreview-1507889870
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248283212
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248281976
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248281584
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248285455
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248284374
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248285933
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248286077
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248287026
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248287738
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248289389
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248289527
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248289943
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248290172
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248290731
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248290809
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248289730
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248292045
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248294487
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248292958
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1248295035

From mchung at openjdk.org  Fri Jun 30 21:45:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 30 Jun 2023 21:45:14 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v19]
In-Reply-To: <ZbsMg67GdEn7H-M9MumzGijPaD9htHOiNG31prqSNLI=.79eb7851-f7b7-482c-a5fa-b81440be4210@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <ZbsMg67GdEn7H-M9MumzGijPaD9htHOiNG31prqSNLI=.79eb7851-f7b7-482c-a5fa-b81440be4210@github.com>
Message-ID: <AQ6CLmKEHMvL7-LsXBe5_RN-T2RgfJM17q5SPkzIaoY=.59b05f5b-0f9c-4ca2-bcfa-86e0cd00000a@github.com>

On Thu, 29 Jun 2023 03:16:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> Benchmark for revision 17:
>> 
>> Benchmark                                                          Mode  Cnt      Score       Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.503 ?     0.021  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.269 ?     0.005  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.806 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     17.332 ?     0.210  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.296 ?     1.371  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt    5      0.419 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt    5      0.421 ?     0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt    5      1.731 ?     0.018  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt    5      0.418 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt    5      0.263 ?     0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt    5      0.262 ?     0.002  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt    5      0.267 ?     0.019  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt    5      0.266 ?     0.013  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt    5     18.057 ?     0.182 ...
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Code cleanup, thanks mandy!
>  - Merge branch 'master' of https://github.com/openjdk/jdk into explore/mhp-iface
>  - 1. Change WRAPPER_TYPES to WeakHashMap to accurately determine if the given class is
>       the proxy class
>    
>    Discussion:
>    2. I dropped ProxyClassInfo and use Lookup just to see the simplication.
>       If wrapperInstanceTarget and wrapperInstanceType are frequently called, it makes
>       sense to cache the method handles.
>    
>    3. Should it use SoftReference or WeakReference?  It depends if asInterfaceInstance
>       will be used heavily.
>    
>    3. I also dropped SamInfo and getStats as it can be inlined in the caller, which
>       I think it's clearer to see what it does in place.
>  - SecurityManager fixed, minimize changes
>  - Merge branch 'master' into explore/mhp-iface
>  - Some changes per Mandy's review. SecurityManager test fails in this patch
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - Merge branch 'master' into explore/mhp-iface
>  - stage, needs to fix is mh proxy instance check
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/6f58ab2b...340b0751

Also we should have a test to verify the proxy class is unloaded and a new proxy class is re-generated when `asInterfaceInstance` is called again on the same interface.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1615220474

From liach at openjdk.org  Fri Jun 30 23:41:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 23:41:09 GMT
Subject: Integrated: 8309819: Clarify API note in Class::getName and
 MethodType::toMethodDescriptorString
In-Reply-To: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
References: <fkbvYmmduQ7v_2gmlw7KM4LlcI7umyBg-X6jJgKr67o=.562487bf-c7be-471a-9491-3789097a2eaf@github.com>
Message-ID: <5XBbr9er1SfJtnuqNL-93wTRP8lyxDzCr0RVLvGJQnQ=.1899c716-0fc6-4f18-ab25-63e199963ed2@github.com>

On Mon, 12 Jun 2023 07:58:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> The API specification for descriptorString not being a strict inverse of Class::forName and MethodType::fromDescriptorString are not entirely correct.
> 
> 1. Class::descriptorString was never an inverse of Class::forName, which takes a binary name instead. The note about different class loaders is moved to getName, as ClassDesc requires an explicit lookup for resolution already.
> 2. MethodType::toMethodDescriptorString ends with a meaningless sentence: "fromMethodDescriptorString, because the latter requires a suitable class loader argument.", and the "Note:" section can be replaced with an `@apiNote`.
> 3. Both of these didn't mention hidden classes (or other non-nominally-describable classes) as a reason that prevents the inversion operation, in addition to distinct class loaders. Added valid method type descriptor/binary name as a prerequisite for the distinct class loader explanation.
> 
> A few user-defined anchor links are replaced with updated javadoc link tag format as well. The explicit html-style links in `@see` tags are unchanged in order to retain the non-code output.
> 
> The rendered specifications:
> https://cr.openjdk.org/~liach/8309819/09/java.base/java/lang/Class.html
> https://cr.openjdk.org/~liach/8309819/09/java.base/java/lang/invoke/MethodType.html

This pull request has now been integrated.

Changeset: 8c8e9d91
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c8e9d911d388f6ee621ed4d322efc56a9876708
Stats:     47 lines in 2 files changed: 10 ins; 10 del; 27 mod

8309819: Clarify API note in Class::getName and MethodType::toMethodDescriptorString

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14411

From liach at openjdk.org  Fri Jun 30 23:49:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 30 Jun 2023 23:49:53 GMT
Subject: RFR: JDK-6361826: (reflect) provide method for mapping strings to
 class object for primitive types
In-Reply-To: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
References: <O3Ehco8RimCxf0T2YzOaMObuinsBnsosJyJ-br9D7VQ=.eaaf1e7a-81c2-4bb2-bc34-ac58b061143a@github.com>
Message-ID: <ayBNl-W-zwTAW7KXuU8GuwW9ykspvl5EBVRSA3SitpA=.652918b0-d719-4741-9033-955ca7bd7a74@github.com>

On Fri, 30 Jun 2023 20:57:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Going over some old issues and found this RFE, posting without any tests or a CSR first to get some feedback on the overall API.

The main downside of throwing an exception is that exception stack trace filling is very costly. If this API is used to process unsanitized strings like users inputs, throwing might impose performance costs for handling bad inputs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14743#issuecomment-1615280806